16 个解决方案
#1
UPD本来就是一个不太可靠的传输协议，TCP相当于打电话，听不到对方的声音，你会重拨，UPD相当于寄信，对方是不是收到信，你不知道，直到对方回信
#2
我把winsock关闭之后再打开，又可以接收数据了，过了会时间又接收不到。
#3
udp 会经常丢包 呵呵 这个很正常 协议决定的
#4
丢包没关系啊，问题是vb中的winsock控件有问题啊。接收数据一段时间后就接收不到数据了，但数据是一直在发的。当把winsock关闭之后再绑定端口又可以接收数据了。 这块的解决方案是什么？
#5
数据一直在发送？你把通道给阻塞了吧
#6
应该不会吧，我也是基于其他软件做的一个UDP消息监听而已，其他软件都正常的，虽然是C++写的，但人家很稳定呀，不会出现端口阻塞现象。 按照你的想法，我想了下可能性比较大，端口被阻塞了，那这个需要怎么解决呢？
#7
是否使用了timer发送数据？如果有加大定时时间值
#8
本程序没有发送数据，只是被动接收数据，timer在本程序中的作用是一旦没接收到数据，按超出规定时间报警。
#9
今天早上9点多运行，运行到现在，应该有7个小时了，都没有问题。但有时候很快就出现问题，这种运行中BUG就是不知道是控件的原因，还是我代码中的原因。
#10
一般是你代码的原因
#11
如果是代码的原因，那为什么运行接收不到数据的时间不对呢，有时候2个小时就接收不到数据了，有时候1天都正常的。
#12
怀疑运行过程中端口被堵塞超过超时时间或者是vb6中winsock控件不稳定或者是运行遭遇ARP、病毒攻击、网关控制等导致端口被*一定时间后超过超时时间winsock停止运行等。 但该怎么解决，大家有什么好的解决方案吗？
#13
思维习惯，首先怀疑微软的工程师是否笨蛋，然后才弱弱地问一声，我的代码是不是也会有问题。
它的控件少说已经有几百万个应用了吧？其他人都是笨蛋，程序会死也不知道？
#14
怎么说呢，我试过用最简单的winsock应用，就绑定端口，接收数据，然后开在那里运行，也会出现这样的问题。
#15
超时了吧，不能光收，隔段时间要发点东西过去
#16
应该就是这样，估计需要心跳检测。 我用了个全局变量控制超时。
#1
UPD本来就是一个不太可靠的传输协议，TCP相当于打电话，听不到对方的声音，你会重拨，UPD相当于寄信，对方是不是收到信，你不知道，直到对方回信
#2
我把winsock关闭之后再打开，又可以接收数据了，过了会时间又接收不到。
#3
udp 会经常丢包 呵呵 这个很正常 协议决定的
#4
丢包没关系啊，问题是vb中的winsock控件有问题啊。接收数据一段时间后就接收不到数据了，但数据是一直在发的。当把winsock关闭之后再绑定端口又可以接收数据了。 这块的解决方案是什么？
#5
数据一直在发送？你把通道给阻塞了吧
#6
应该不会吧，我也是基于其他软件做的一个UDP消息监听而已，其他软件都正常的，虽然是C++写的，但人家很稳定呀，不会出现端口阻塞现象。 按照你的想法，我想了下可能性比较大，端口被阻塞了，那这个需要怎么解决呢？
#7
是否使用了timer发送数据？如果有加大定时时间值
#8
本程序没有发送数据，只是被动接收数据，timer在本程序中的作用是一旦没接收到数据，按超出规定时间报警。
#9
今天早上9点多运行，运行到现在，应该有7个小时了，都没有问题。但有时候很快就出现问题，这种运行中BUG就是不知道是控件的原因，还是我代码中的原因。
#10
一般是你代码的原因
#11
如果是代码的原因，那为什么运行接收不到数据的时间不对呢，有时候2个小时就接收不到数据了，有时候1天都正常的。
#12
怀疑运行过程中端口被堵塞超过超时时间或者是vb6中winsock控件不稳定或者是运行遭遇ARP、病毒攻击、网关控制等导致端口被*一定时间后超过超时时间winsock停止运行等。 但该怎么解决，大家有什么好的解决方案吗？
#13
思维习惯，首先怀疑微软的工程师是否笨蛋，然后才弱弱地问一声，我的代码是不是也会有问题。
它的控件少说已经有几百万个应用了吧？其他人都是笨蛋，程序会死也不知道？
#14
怎么说呢，我试过用最简单的winsock应用，就绑定端口，接收数据，然后开在那里运行，也会出现这样的问题。
#15
超时了吧，不能光收，隔段时间要发点东西过去
#16
应该就是这样，估计需要心跳检测。 我用了个全局变量控制超时。