C# Socket通信问题，请高手指教。

现在做一个连续通信程序，我为服务器，别人向我发送一个请求链接，也就是为我建立一个通信链路，我通过这个链路连续不断的向其发送数据，现在发送间隔为一分钟。现在问题是断线的次数太多。只要链路不通。客户端就主动向服务器发送请求建立链路。想请教高手，怎样才能在这个链路上持续不断的发送数据？还有出现这种断线的原因可能是那些或者给提供一些思路，不胜感激！！！

38 个解决方案

#1

将超时拉长或者建立TCP连接

#2

设置超时长一些，或者定时发少量数据，不要让连接空闲间隔太长

#3

你用的tcp吧。我觉得是不是可以建立tcp连接后开始发信息，之后每隔一定时间发送空包。这样的目的是保留住这个tcp连接。我以前试过增加socket的延时时间，但貌似不是很管用还是会断开。你可以每隔10秒发空包，每隔一分钟发实际要发的包。当然还是会有可能会断开，那样就重新connect了。

#4

引用 1 楼 wsxqaz 的回复:

将超时拉长或者建立TCP连接

我没有设置时间超时，这个链接是客户端建立的，发现断了，客户端主动连接我！现在测试了十几天，断线此时大概1000多次。

#5

引用 1 楼 wsxqaz 的回复:

将超时拉长或者建立TCP连接

引用 3 楼 wangyue4 的回复:

你用的tcp吧。我觉得是不是可以建立tcp连接后开始发信息，之后每隔一定时间发送空包。这样的目的是保留住这个tcp连接。我以前试过增加socket的延时时间，但貌似不是很管用还是会断开。你可以每隔10秒发空包，每隔一分钟发实际要发的包。当然还是会有可能会断开，那样就重新connect了。

这种方法可以尝试下，这个事防止没有的时候被系统释放掉吗？

#6

期待高手出现…………

#7

tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。
如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

#8

如果数据包不是太大，连续不断发送的我还真就推荐udp通信，无状态省很多事
udp不通或者阻断的，一般tcp同样也不行，所以...
可以适当的在udp包中添加验证字。

#9

引用 7 楼 wangyue4 的回复:

tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。
如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

规定是客户端给发链路维持，服务器无权连接客户端。我试验下使用心跳包！

#10

引用 7 楼 wangyue4 的回复:

tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。
如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

实际上正相反，如果是只有十几个客户端的小玩意，但是客户端像灌水一样不停地与服务器顺序通讯，此时或许长连接更好一点。

如果有非常多客户端，并且客户端各个半分钟、几分钟才突然发起十几个并行连接，这时候短连接最好。

长连接代码，适合在课堂上做练习。

#11

不要让连接空闲间隔太长，可定时发少量数据

#12

引用 10 楼 sp1234 的回复:

引用 7 楼 wangyue4 的回复:tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

实际上正相反，如果是只有十几个客户端的小玩意，但是客户端像灌水一样不停地与服务器顺序通讯，此时或许长连接更好一点。

如果有非常多客户端，并且客户端各个半分钟、几分钟才突然发起十几个并行连接，这时候短连接最好。

长连接代码，适合在课堂上做练习。

客户端很少，就几个，而且如果连接不断开的话就客户端不会重复进行链接。功能很简单，主要是稳定，减少连接次数……所以长连接比较好，但是这个长连接怎样做才能更稳定呢？

#13

Socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true);

#14

TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。

#15

引用 13 楼 guoyichao 的回复:

Socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true);

是一种方法，我试验下……

#16

引用 14 楼 sgchen2000 的回复:

TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。

客户端应该没问题，因为好多服务器都向他发数据，其他的程序都很少断掉……我的断掉的多……

#17

good good study,day day up

#18

引用 14 楼 sgchen2000 的回复:

TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。

别的程序连接都正常，所以客户端是没有问题的

#19

学习~~~~~~~~~~~~~~~~~~~~~~~~~`

#20

引用 16 楼 hbbliyong 的回复:

引用 14 楼 sgchen2000 的回复:TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。
客户端应该没问题，因为好多服务器都向他发数据，其他的程序都很少断掉……我的断掉的多……

不表示它一定有问题，要看它怎样判断Socket断开，再跟你服务器端比较。比如我用c#写的都是判断接收到空信息就表示连接断开（目前为止我知道的最有效的方法），因此如果用空信息作为握手包就适得其反了。
原则上，首先你要知道是你的服务器主动断开，还是客户端主动断开，再查找断开的原因。

握手包只是用来处理网络异常断开的情况，Socket主动断开是可以检测出来的。

#21

该回复于2010-02-23 16:35:19被版主删除

#22

测试中，期待其他方法

#23

断线的原因是什么？是不是代码中循环的问题？
用长连接。

#24

引用 23 楼 walkghost 的回复:

断线的原因是什么？是不是代码中循环的问题？
用长连接。

何为长连接？

#25

厉害啊,学习了.

#26

测试中，已经一天了还没有断掉，采用楼上几位的方法……，期待其他方法………………

#27

利用心跳机制也就跟上面有人说的差不多。
定时的客户端向服务器请求，判断是否连接，长时间不用，socket肯定断掉。

#28

如果可以，你还是把代码监听代码发上来看看，
10楼的看法是正确的，主要看你的客户端个数是否很多？发送包的频率有多高？

请问，你的连接断开原因有找到吗？

   正常断开，程序控制的断开？
   网络中断？
   异常断开？

建议你还是使用长连接吧，用多线程实现，即客户端一旦与服务器建立连接，可以连续的不间断的发送数据包，
同时建议你建立一个客户端与服务器端数据包的确认回发机制，即服务器端没收到一次数据，回发确认。

#29

服务器端每收到一次数据，回发确认。

#30

引用 29 楼 wuzhicheng5 的回复:

服务器端每收到一次数据，回发确认。

呵呵，我们只负责服务端的开发，客户端改不了，也不能改！所以没有确认！不知道是什么原因断开，测不了，客户端收不到数据或者检测连接已经中断就重新建立连接，我是服务端，只能按照客户端的方式走！
快两天了，目前一次断开还没有……

#31

引用 27 楼 kenshinggg 的回复:

利用心跳机制也就跟上面有人说的差不多。
定时的客户端向服务器请求，判断是否连接，长时间不用，socket肯定断掉。

应该是心跳起作用了，现在还没断开！

#32

期待好的建议出现…………

#33

试一下设置socket的keepalive为true 。。。

#34

引用 33 楼 xinsiyu2008 的回复:

试一下设置socket的keepalive为true 。。。

恩，设置过了

#35

自己顶起……………………

#36

在顶一下啊…………

#37

我倒楼主说的是这个问题啊我在你空间留言你没看到？
你们的服务器也是一两台，但客户端可能分部在全国各地？
一般来说这样是没有完美的解决方案的
我的项目，开始遇到和你一样的问题
开始用KEEPALIVE做，测试1个月后，发现效果不理想
后来自己做心跳包
把整个通信架构都改过来了用的是非阻塞模式
心跳包发送的时间动态变化，网络越不稳定，时间越短
3个月运行下来，基本可行

#38

xiexie

#1

将超时拉长或者建立TCP连接

#2

设置超时长一些，或者定时发少量数据，不要让连接空闲间隔太长

#3

#4

引用 1 楼 wsxqaz 的回复:

将超时拉长或者建立TCP连接

我没有设置时间超时，这个链接是客户端建立的，发现断了，客户端主动连接我！现在测试了十几天，断线此时大概1000多次。

#5

引用 1 楼 wsxqaz 的回复:

将超时拉长或者建立TCP连接

引用 3 楼 wangyue4 的回复:

你用的tcp吧。我觉得是不是可以建立tcp连接后开始发信息，之后每隔一定时间发送空包。这样的目的是保留住这个tcp连接。我以前试过增加socket的延时时间，但貌似不是很管用还是会断开。你可以每隔10秒发空包，每隔一分钟发实际要发的包。当然还是会有可能会断开，那样就重新connect了。

这种方法可以尝试下，这个事防止没有的时候被系统释放掉吗？

#6

期待高手出现…………

#7

#8

#9

引用 7 楼 wangyue4 的回复:

tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。
如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

规定是客户端给发链路维持，服务器无权连接客户端。我试验下使用心跳包！

#10

引用 7 楼 wangyue4 的回复:

tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。
如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

#11

不要让连接空闲间隔太长，可定时发少量数据

#12

引用 10 楼 sp1234 的回复:

引用 7 楼 wangyue4 的回复:tcp连接长时间不用有时就会断的，我以前遇到过，所以要每隔较短时间发送维持连接的空包。如果连接服务的客户端数量不多的话是不是可以用一次就联一次，完事就close了，下次再用再联

实际上正相反，如果是只有十几个客户端的小玩意，但是客户端像灌水一样不停地与服务器顺序通讯，此时或许长连接更好一点。

如果有非常多客户端，并且客户端各个半分钟、几分钟才突然发起十几个并行连接，这时候短连接最好。

长连接代码，适合在课堂上做练习。

#13

Socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true);

#14

TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。

#15

引用 13 楼 guoyichao 的回复:

Socket.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.KeepAlive, true);

是一种方法，我试验下……

#16

引用 14 楼 sgchen2000 的回复:

TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。

客户端应该没问题，因为好多服务器都向他发数据，其他的程序都很少断掉……我的断掉的多……

#17

good good study,day day up

#18

引用 14 楼 sgchen2000 的回复:

TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。

别的程序连接都正常，所以客户端是没有问题的

#19

学习~~~~~~~~~~~~~~~~~~~~~~~~~`

#20

引用 16 楼 hbbliyong 的回复:

引用 14 楼 sgchen2000 的回复:TCP连接一般不会无缘无故断开的，应该从客户端上查找原因，因为是它认为断开了。
客户端应该没问题，因为好多服务器都向他发数据，其他的程序都很少断掉……我的断掉的多……

#21

该回复于2010-02-23 16:35:19被版主删除

#22

测试中，期待其他方法

#23

断线的原因是什么？是不是代码中循环的问题？
用长连接。

#24

引用 23 楼 walkghost 的回复:

断线的原因是什么？是不是代码中循环的问题？
用长连接。

何为长连接？

#25

厉害啊,学习了.

#26

测试中，已经一天了还没有断掉，采用楼上几位的方法……，期待其他方法………………

#27

利用心跳机制也就跟上面有人说的差不多。
定时的客户端向服务器请求，判断是否连接，长时间不用，socket肯定断掉。

#28

#29

服务器端每收到一次数据，回发确认。

#30

引用 29 楼 wuzhicheng5 的回复:

服务器端每收到一次数据，回发确认。

#31

引用 27 楼 kenshinggg 的回复:

利用心跳机制也就跟上面有人说的差不多。
定时的客户端向服务器请求，判断是否连接，长时间不用，socket肯定断掉。

应该是心跳起作用了，现在还没断开！

#32

期待好的建议出现…………

#33

试一下设置socket的keepalive为true 。。。

#34

引用 33 楼 xinsiyu2008 的回复:

试一下设置socket的keepalive为true 。。。

恩，设置过了

#35

自己顶起……………………

#36

在顶一下啊…………

#37

#38

xiexie

C# Socket通信问题，请高手指教。

38 个解决方案

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#26

#27

#28

#29

#30

#31

#32

#33

#34

#35

#36

#37

#38

#1

#2

#3

#4

#5

#6

#7

#8

#9

#10

#11

#12

#13

#14

#15

#16

#17

#18

#19

#20

#21

#22

#23

#24

#25

#26

#27

#28

#29

#30

#31

#32

#33

#34

#35

#36

#37

#38

相关文章