话梅超人及各位大神请进请进，你懂得···

Question

用MFC加API写的一个客户端接收程序，在ONreceive中添加了recv（）接收函数，紧接着有send（）发送函数。（以及大量容错处理）
但为什么OnRecive偶尔会无法收到通知呢？？
跟话梅超人的相似，想问一下具体是怎么处理的，Asyncselect是在ONReceive里面加的，还是在其他地方加的？是Asyncselect(FD_READ)?希望不吝赐教··详细说一下

Answer 1

你还是用winsock API去写吧，流程很清楚

Answer 2

Asyncselect(FD_READ)应该在创建Socket成功之后调用

Answer 3

直接 call 话梅超人来指点下不得了？

Answer 4

我不定时来 刚看到呵呵
Asyncselect(FD_READ)肯定要加到onRecive中的
但是我不清楚你的onRecive中无限循环是否在接收到包头指定的数据长度后就退出循环 使得onrecive能够完成执行？ 

Answer 5

PS:你所继承的MFC类是哪个？
你可以尝试把数据交互的周期加到足够大，使得再完成一次数据交互后 有几秒的空闲期 看看 还会不会有问题
然后逐渐缩小周期

Answer 6

支持我觉得 这个recv异步消息 可能收不全

Answer 7

我也在努力改成API的，不知道行不行

Answer 8

恩 恩 能用API就尽量用

Answer 9

我用的是CAsyncSocket类继承来的，接受数据少的时候没有问题，ONRECEIVE一切正常；但是接收数据量变为原来的2100倍（实际需要无法改动的）时，就会偶尔出现接受不到数据，同时对方也不发送数据了。这个现象估计就是你说的客户机不收数据，服务器就不发了吧？
那个for无限循环中的流程是这样的：先recv()接受数据（recv()的时候使用了select()使其非阻塞），然后容错判断，接着send（）函数发送数据（send没有使用select()，应该是阻塞的吧），等到发送完毕，然后进入下一次for循环。
不知道这样的流程对不对，有没有更好更稳定的接受发送流程，希望能参考一下！

Answer 10

recv()的时候使用了select()使其非阻塞???  你能确定你都recv全了么首先建议你 把send函数过程移出onRecive 最好放在别的线程里去执行第二你能确定你的send发送完全了么？ 因为有可能是你这边的send没有发送完全导致对方解析出错而没再给你发包过来 自然你的Onrecive就不会响应了

Answer 11

  使用了select（）所以加了FOR()无限循环，当套接字不可读时，直接进行下一次循环，这样一直读下去，直到变为可读状态，来确保recv（）接受数据完整性，应该没问题；send()函数是阻塞函数，如果发送不出去，那它应该不会返回吧，会一直等一直等，等到发送出去才会返回。所以只要FOR（）循环能继续，说明send（）应该发送成功。“把send函数过程移出onRecive 最好放在别的线程里去执行”有啥说法没？有啥隐患？我现用API重写了这部分一下，没用CAsyncSocket类，直接把整个FOR()循环写到了另起的线程里，不知道会不会有问题

Answer 12

你在OnRecive里无限循环 这个函数永远不退出？这可不对哦放到另外一个线程里 没啥问题

Answer 13

你在OnRecive里无限循环 这个函数永远不退出？这可不对哦放到另外一个线程里 没啥问题