18,356
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
UDX协议 2003-12-04
- 打赏
- 举报
andy_lau (天行键，君子当自强不息！)
回家看《网络编程》
避免在同一时刻向很多客户发问大量数据 是最有郊的方法.
回家看《网络编程》
避免在同一时刻向很多客户发问大量数据 是最有郊的方法.
warton 2003-12-04
- 打赏
- 举报
在使用TCP连接时，服务器必须十分小心地控制好，防止网络带宽过载超过一定的时间，否则将需要重发大量的包或造成大量连接中断。
---这种情况好像比较正常哦!
http://www.cesdn.net/document/show.asp?id=155
---这种情况好像比较正常哦!
http://www.cesdn.net/document/show.asp?id=155
ISunwu 2003-12-04
- 打赏
- 举报
不明白楼上所谓的代码稳定是什么意思。
FlyYang 2003-12-04
- 打赏
- 举报
上面几位说的只是性能问题，不能代表用什么方法就能避免自动中断
不管是用什么方法
只要代码稳定，不会出现自动中断的问题
要仔细检查你的代码
---------
++C++
---------
不管是用什么方法
只要代码稳定，不会出现自动中断的问题
要仔细检查你的代码
---------
++C++
---------
warton 2003-12-04
- 打赏
- 举报
避免在同一时刻向很多客户发问大量数据。
流量控制也是保证可靠性的一个重要措施，若无流控，可能会因接收缓冲区溢出而丢失大量数据，导致许多重传，造成网络拥塞恶性循环。TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。
流量控制也是保证可靠性的一个重要措施，若无流控，可能会因接收缓冲区溢出而丢失大量数据，导致许多重传，造成网络拥塞恶性循环。TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。
fbmsf 2003-12-04
- 打赏
- 举报
合理的代码是不会出问题的，
当然这需要不断的提高代码的质量，
当然这需要不断的提高代码的质量，
ISunwu 2003-12-04
- 打赏
- 举报
这样子虽然能保证传送正确，但花的代价太大。因为TCP本身已经保证了数据传送的正确性。
所以，这样会大大降低你的效率。因此，不推荐这么做。
如果你使用的是WINDOWS Socket API的话，可以使用select。
如果使用CAsyncSocket的话，那就更方便了。在OnSend中发送就可以了。
所以，这样会大大降低你的效率。因此，不推荐这么做。
如果你使用的是WINDOWS Socket API的话，可以使用select。
如果使用CAsyncSocket的话，那就更方便了。在OnSend中发送就可以了。
andy_lau 2003-12-04
- 打赏
- 举报
我在程序中采用应答方法，也就是服务器端必须等待客户端返回处理正确的信息后才发送第二条信息
wangweixing2000 2003-12-04
- 打赏
- 举报
gz
ISunwu 2003-12-04
- 打赏
- 举报
发送和接收应该协调好，不能发送方拼命的发，接收方处理如果来不及就会导致网络阻塞甚至崩溃。
建议：
1、不要将和网络传送无关的代码放在网络传送线程中；
2、使用完成端口，由系统在后台处理I／O；
3、始终检查发送和接收的返回值，并给出相应的处理，不要放过任何一个可能的错误处理。
建议：
1、不要将和网络传送无关的代码放在网络传送线程中；
2、使用完成端口，由系统在后台处理I／O；
3、始终检查发送和接收的返回值，并给出相应的处理，不要放过任何一个可能的错误处理。
Semigod 2003-12-04
- 打赏
- 举报
我以前也遇到过这种问题，通过试验发现，通过修改服务器端代码，使其更合理更高效就可避免这种问题。
例如： 发送一个大文件的内容时，使用 TransmitFile 比使用send 更可靠
例如： 发送一个大文件的内容时，使用 TransmitFile 比使用send 更可靠
