关于DELPHI7中TcpServer控件在某种条件下会停止监听的问题(100分)

  • 主题发起人 主题发起人 xiaoxinxx168
  • 开始时间 开始时间
X

xiaoxinxx168

Unregistered / Unconfirmed
GUEST, unregistred user!
当一个tcpserver处于监听状态的时候,会有哪些因素能导致他停止监听?我的程序偶尔会在某种情况下就不再响应客户端了,具体表现为:
TcpClient.Connect 的结果为 false。
但是这种情况发生的几率很小,而且我做过测试,把一个tcpserver程序运行一个小时之后再连接,结果还是可以连接。
 
未受理的连接请求队列太小,Indy里有个常量:
IdListenQueueDefault = 15;
这个15包括两部分:
1.收到Client的syn,发送了自己的syn,ack但还未收到client的ack的连接
2.收到了Client的ack连接但应用层还没有调用accept的连接
以上两个环节哪一个出问题或者是真的并发的connect过多都会导致连接失败。
对于1,著名的syn flood就是用的这招。
对于2,服务器过忙,listen线程没有执行机会就会发生。
不过出了这问题也不怕(syn flood攻击除外),你只要再次调用connect可能就又能连接上了。
 
谢谢楼上的回答:
1、我是用TTCPSERVER和TTCPCLIENT这套控件,不是用INDY公司的那套控件;
2、只要出现一次TcpClient.Connect的结果为 false,除非重新启动程序,否则怎样都连接不上。
 
是不是indy原理是一样的,只是队列长度不一定是15。
偶先去看看TTCPServer的实现,看看能不能看出点端倪。
 
呵呵,不看不知道,一看吓一跳。
首先,TTCPServer的队列长度仅仅为5。
其次,为了照顾CLX Application,他竟然使用的大名鼎鼎的select模型,效率自然是好不到哪里去了。
 
有没有解决办法?
 
你试试到多少并发连接时出现这种情况,如果是第10个或第11个的话,偶可能已经找到原因了。
 
我刚才做了一个测试,四台机器用TTCPCLIENT同时以每秒一次的速度给服务器程序的TTCPSERVER发包,发了5分钟都没问题,而且也没丢包。
所以这种现象是很偶然的,但是也肯定会出现。
你说一下你认为是什么原因呢?
 
不是说发包的频率,而是要客户端保持连接。
再说,一秒一次也是个很低很低的频率了。
 
还有一个情况,客户端的程序有个事件好像点击了10次就会出问题了,可能就是你说的那种情况。
 
“不是说发包的频率,而是要客户端保持连接。”
你是只同时有多少个TTCPCLIENT与TTCPSERVER相连吗?
 
后退
顶部