非阻塞模式下调用send()和recv()的问题? 在Non-Blocking模式下,使用send()和recv()来发送和接收数据。当返回错误代码为WSAEWOULDBLCOCK。这时我是否应该继续调用send()和recv()?会不会导致数据被发送两次,或者接收到了错误的数据?能否解释一下原理。 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 应该是RECV()返回 的错误吧,多调用几次直到收到数据为止即可原因 是因为你用非阻塞调用RECV如果没数据就直接返回了最好使用事件模式啦,就不用不停调用RECV了 send失败数据是不会被发送出去的,可以再调用send,recv也是 或许是我看书还不够,很多地方还不明白,再来向大家详细谈谈我的迷惑吧:按照我的理解,在非阻塞模式下,调用send()和recv()函数,函数都可以立即返回。这个时候数据不一定已经发送成功或者接收成功,可能操作还在底下进行,所以会返回WSAEWOULDBLOCK错误。这时有其它事情可做的话,我就去做其它事情。完成额外的事情后,我想知道先前的调用是否成功完成,这时我是否应该再调用一遍send()或recv()函数或者用其它的什么方法?我试过非阻塞模式下的connect()函数,在另一端调用accept()时,第一次调用的时候返回WSAEWOULDBLOCK错误,而第二次调用时就会返回WSAEISCONN。这说明第一次调用之后已经连接成功。说明WSAEWOULDBLOCK错误返回的时候操作仍在继续。所以我觉得send()或recv()函数也一样。返回WSAEWOULDBLOCK错误而底下仍在继续。另外关于send()函数它返回的长度是实际发送的长度还是只是写到缓冲区等待发送的长度?返回错误时是实际发送错误还是写缓冲区时的错误?有没有可能写缓冲区没错而等到实际发送时却出现错误,这时函数怎么返回和处理的?希望有人能够给我指点一二! 楼上几位误人子弟-____________________-#WSAEWOULDBLCOCK是non-block模式必然会出现的错误意思是网络阻塞了,这个时候不应该recv/send应该等待下一次的FD_READ或者FD_WRITE事件到达再进行recv/send基本流程就是这样non-block不同于block模式的地方在于,当网络阻塞的时候所有i/o调用会立刻返回一个WSAEWOULDBLCOCK这时候你可以做一切其他事务直到下一个event被触发还有,需要注意的是,一定要判断好已经send出去的字节数,收到FD_WRITE之后要继续从上次未完成的地方发送 一般情况下,send返回的是送给缓冲区的字节数。但是这些字节在经过底层处理后一般都会发送到对方,因此不必多虑特殊情况下,可以通过关闭socket的write buffer来迫使send不将数据送给缓冲区总之,当返回WSAEWOULDBLCOCK的时候,你需要等待下一个event才能继续进行I/O处理 WSAEWOULDBLCOCK是non-block模式必然会出现的错误意思是网络阻塞了,这个时候不应该recv/send应该等待下一次的FD_READ或者FD_WRITE事件到达再进行recv/sendto fantiyu(fantiyu):你还没说呢?再次进行调用时应该写和收的内容时什么?重复上一次的吗?还是可以换新的了。 比如要发送2000字节调用send发送了1000,然后得到了WSAWHOULDBLOCK那么下一次FD_WRITE就应该发送剩下的1000字节 用select()来判断你的套解字是否有数据可读/可写,完成端口模型能更好的处里此类问题,因为它本身就是一个纯异步的结构。 TMD,老板不允许上班时间上网了。现在揭帖。 寻找个控件类…… 如何让VIEW类中的Ondraw函数 只执行一次 如何让窗口获得焦点。 抓狂啊!调试时,BCG源文件跟进去了,但是却得不到源文件中的变量的值 CString类型作为输出参数的问题 C程序改写成VC vc中如何编写dll的version! 关于BCGControlBar的问题 这是什么? 菜鸟问题:请问可不可以在SDI程序的文档窗口中一直显示一个对话框,再在这个对话框上显示一些按纽、进展条等常用控件?如何做?或者,在D 一个有意思的问题? 大送分:关于COM的菜鸟级问题
原因 是因为你用非阻塞调用RECV如果没数据就直接返回了最好使用事件模式啦,就不用不停调用RECV了
按照我的理解,在非阻塞模式下,调用send()和recv()函数,函数都可以立即返回。这个时候数据不一定已经发送成功或者接收成功,可能操作还在底下进行,所以会返回WSAEWOULDBLOCK错误。这时有其它事情可做的话,我就去做其它事情。完成额外的事情后,我想知道先前的调用是否成功完成,这时我是否应该再调用一遍send()或recv()函数或者用其它的什么方法?我试过非阻塞模式下的connect()函数,在另一端调用accept()时,第一次调用的时候返回WSAEWOULDBLOCK错误,而第二次调用时就会返回WSAEISCONN。这说明第一次调用之后已经连接成功。说明WSAEWOULDBLOCK错误返回的时候操作仍在继续。所以我觉得send()或recv()函数也一样。返回WSAEWOULDBLOCK错误而底下仍在继续。另外关于send()函数它返回的长度是实际发送的长度还是只是写到缓冲区等待发送的长度?返回错误时是实际发送错误还是写缓冲区时的错误?有没有可能写缓冲区没错而等到实际发送时却出现错误,这时函数怎么返回和处理的?希望有人能够给我指点一二!
WSAEWOULDBLCOCK是non-block模式必然会出现的错误
意思是网络阻塞了,这个时候不应该recv/send
应该等待下一次的FD_READ或者FD_WRITE事件到达再进行recv/send基本流程就是这样non-block不同于block模式的地方在于,当网络阻塞的时候所有i/o调用会立刻返回一个WSAEWOULDBLCOCK
这时候你可以做一切其他事务直到下一个event被触发还有,需要注意的是,一定要判断好已经send出去的字节数,收到FD_WRITE之后要继续从上次未完成的地方发送
意思是网络阻塞了,这个时候不应该recv/send
应该等待下一次的FD_READ或者FD_WRITE事件到达再进行recv/send
to fantiyu(fantiyu):
你还没说呢?再次进行调用时应该写和收的内容时什么?重复上一次的吗?还是可以换新的了。
调用send发送了1000,然后得到了WSAWHOULDBLOCK那么下一次FD_WRITE就应该发送剩下的1000字节
完成端口模型能更好的处里此类问题,因为它本身就是
一个纯异步的结构。