这种方式，要么对tcp client的收发进行大改，要么是传输头部加一个标识，服务端要配套把标识传回来。
为了可推广性，建议服务端提供头部定义形式，主攻TCP客户端真正易用，现在的封装只是技术易用，离业务开发还差段距离，每个人拿着都还要再实现一套自己的，为什么你不弄一个标准的形式，只要方便好用，说不定都会用你的标准形式了。

同步等待接收这种形式会破坏整个库的设计原则，如果用户在事件循环线程中同步等待，会导致后面所有的串行任务阻塞，这样做很危险，会导致其他异步接口都无法使用，这样相当于引导用户去做错误的事情。
开发者应该按照一定的使用原则来使用某个框架，比如说android系统强制规定不得在后台线程执行刷新UI控件的操作、UI线程不得操作网络相关接口，这些操作都是强制性禁止的。
ZLToolKit也有强制性的要求，比如说不得在事件循环线程执行耗时的操作，这个是无法兼容的，必须遵循这一规则。
而同步等待接口很可能让用户破坏这一规则，所以为了避免错误的引导用户，暂时不考虑同步等待这样的接口。
其实处处无阻塞、处处回调的编程方式，习惯了还好，不是那么不适应的，ZLMediaKit作为基于ZLToolKit的协议库，已经实现了很多类型的TCP客户端，代码可读性也并不是那么差。
现在C++11对异步编程支持还是挺友好的，不像libuv那样不太好理解

(1). response syncCall(request, timeout); //同步阻塞请求，等待timeout时间
这个接口是send和recv的高级包装，目的是更易用，跟在事件循环中执行耗时操作是两码事啊。

其实我觉得一个优秀的网络框架，应该杜绝在事件循环中做阻塞式操作，也应该杜绝跨线程操作这个socekt相关的对象，在底层判断操作的对象io的是否是绑定的事件循环线程，如果发现不是就抛异常。要强制性的要求开发者养成一个对象一个线程的开发模型，就像Android的UI模型一样。