NetHost::Recv方法使用专集（基于mdk1.10）

为何将此方法特别弄一个专集，由于在通讯软件领域中，数据接收一直是一个比较有复杂的事情，处理的好很差，直接影响到程序效率。 本文就是为了介绍NetHost::Recv配合mdk这套引擎，如何方便的解决了传统通讯软件中在数据接收这一块上遇到的各类瓶颈 瓶颈1：等待数据的方式 循环sleep、阻塞recv、事件触发（例如select epoll） 他们的缺点     循环sleepcpu吃紧     阻塞recv占用业务线程     事件触发，不知道有多少可读数据，若是数据不完整，读出数据须要用户本身维护 NetHost的解决方案     NetHost有本身的接收缓冲，mdk引擎收到数据首先放入NetHost的接收缓冲，而后触发OnMsg。     由于底层已经在接收了，因此recv永不阻塞，数据不够直接返回，等下次数据到达时，OnMsg会再次被触发 瓶颈2：一个完整消息被分红屡次到达 来1次收1次，记录上次接收状态，用户本身拼包 缺点     用户得本身维护已接收的数据，至关于一个接收缓冲，这个缓冲必须随着链接的创建与断开建立与删除，维护代价昂贵 NetHost的解决方案     NetHost::Recv比传统的recv方法增长一个bClearCache参数，告诉Recv接收到数据后，是否将数据从接收缓冲删除     bClearCache为true时，与传统recv方法效果同样，好比到达数据123456789     recv 2 byte 收到12     recv 2 byte 收不到12了，收到34     bClearCache为false时，读出数据不被删除，下次还能够读到，好比仍是到达数据123456789     recv 2 byte 收到12     recv 2 byte 仍是会收到12     应用举例     好比好比报文格式：2byte内容长度+报文内容     到达数据0x00 0xff 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39     实际就是257byte的报文，报文内容255byte，实际达到“123456789”9byte     按照传统作法       1.Recv(msg, 2);0x00 0xff被读出       2.解析msg获得内容长度，假设为255       3.Recv(msg, 255);返回长度不够，123456789被读出       这时，直接return吧，数据就丢失了，用户得创建缓冲     NetHost::Recv的作法       1.Recv(msg, 2, false);0x00 0xff被读出,可是不从缓冲删除       2.解析msg获得内容长度，假设为255       3.Recv(msg, 257);报文长度2+255，返回长度不够，1个byte都不读取，0x00 0xff "123456789"依旧在缓冲中       用户能够直接return，等待下次OnMsg触发时再尝试读取       等到数据所有到达时第3.步骤就直接所有读出来，并从缓冲删除了，1次解决       用户不须要sleep,不须要阻塞，不须要维护缓冲 就是这样，有什么问题欢迎联系我