使用winsock开发的应用服务器不稳定，不定时会崩溃解决办法
使用winsock开发的应用服务器不稳定，不定时会崩溃
我的PB是PB12.1.6639，使用winsock技术开发了应用服务器和客户端程序，所有客户端登陆时必须连接应用服务器，同时建立两者间的通讯通道，现在在客户正式环境中，隔两三天应用服务器就崩溃，且无详细的出错信息，90%的崩溃都是出现在早上上班或中午上班登陆高峰值，因为不定时且没具体出错提示，不知怎么去排查，有无办法可以在崩溃前捕获到出错原因？在哪里加try catch不知有无用，现在连在做什么事情时崩溃也不判别不了。
------解决方案--------------------
加日志，把服务器上的执行增加一个log文件记录下来，再崩溃的时候就比较好分析了
------解决方案--------------------
大方向上，2楼的建议，我觉得是对的。
就现有的方案进行修改的话:
(我只能说思路,你这个贴的分数,换成万,再改成RMB,在市场上都不一定买得到健壮的解决方案)
//我们假定你应用服务器的工作量不是很大,
//比如同时在线的只有一两百部客户机,(超过这个数量级的,我没有实际用PB做过)
//每次计算和传输的时间是可以接受的,
//比如只是简单的应答,(基本上,什么事都可以转换成下面的情况,如果是一个巨大的对话,你可以改成"某某跟大家说，我在哪张表插入了一条数据，主键是XX",各个客户端自己去查。)
//如 某某跟某某说"XX"
//或 某某跟大家说"XX"
//或 某某跟某个工作组说"XX"
//如果存在大数据包的情况,比如"某某跟大家分享一个视频",就必须使用方案B(当然也可以改成"某某FTP了一个大文件,大家去哪里下载",就可以把压力转到FTP或HTTP服务器上)
--------------------
方案A,
在你现有的功能上DEBUG.
这个比较难调,倒不是因为PB不擅长做这件事,
而是因为,PB程序员很少做这件事,导致没有太多现成的例子,健壮的就更少了.
(仅就这件事而言,不论哪种语言,基本上都是调用WINDOWS底层的协议来做,所以在我们上述假定的条件限制下,不存在PB不擅长而VC或C或DEPHI擅长的情况,除非很特别的情况,要不然很少为小系统专门去发明一个车轮的)
//你所觉得的困难，作为VC或C程序员的时候，我也遭遇过,绝不会比PB好调.
经验而言,大概率出问题的机会在,客户端被"强行结束"或网络中断,也就是连接已经没有了,服务器还往那里推数据.
一两次可能没问题,但长期的积累下,就会导致各种你DEBUG不出来的错误.
DEBUG的方向是,找一部电脑做客户端,不断连接你的服务器,不断强制关闭或物理上拔网线再不断连接(两种都试),看看你服务器是怎么崩溃的.
--------------------
方案B,(这个要比方案A健壮很多)
整个框架重新做(多花不了你一个星期的时间)
1.各个客户机都起一个SOCKET监听器(从你的角度,相当于每个客户都有一个服务器在自己机上).
2.这个监听器定时(比如5分钟)去数据库UPDATE一下,说"某某IP在线".(这个专业的术语叫心跳)
3.发消息时,需要发消息的机，自己在数据库中查一下，保持心跳的IP，自己分别向他们发消息.
4.所有收发消息，不保持连接，发完收完各自断开.
5.这个监听器自己定时重启.(内存越界之类的错误就基本不用管了).
6.不要问我，你的机上，有多个不同程序要接收消息怎么做。自己连自己机上的监听器就行了(SOCKET或DDE都可以,还有别的方案，就不举了)
这样，任何一部机的监听器崩溃,都只是自己的事。(其实，因为上述第4点的存在,你几乎不用怎么DEBUG,它都很难崩溃)
你要是想做得好一点，就在每部机上运行一个小程序(当然要自己写)，监视你的监听器,如果它没有响应或崩溃了,就再运行一次监听器.
--------------------
例外,使用方案B,
极小情况下，你可能还需要另外一个知识,"网络穿透"(BAIDU或GOOGLE一下),这个恐怕真的没有人用PB做过。至少我没见过。
我的PB是PB12.1.6639，使用winsock技术开发了应用服务器和客户端程序，所有客户端登陆时必须连接应用服务器，同时建立两者间的通讯通道，现在在客户正式环境中，隔两三天应用服务器就崩溃，且无详细的出错信息，90%的崩溃都是出现在早上上班或中午上班登陆高峰值，因为不定时且没具体出错提示，不知怎么去排查，有无办法可以在崩溃前捕获到出错原因？在哪里加try catch不知有无用，现在连在做什么事情时崩溃也不判别不了。
------解决方案--------------------
加日志，把服务器上的执行增加一个log文件记录下来，再崩溃的时候就比较好分析了
------解决方案--------------------
大方向上，2楼的建议，我觉得是对的。
就现有的方案进行修改的话:
(我只能说思路,你这个贴的分数,换成万,再改成RMB,在市场上都不一定买得到健壮的解决方案)
//我们假定你应用服务器的工作量不是很大,
//比如同时在线的只有一两百部客户机,(超过这个数量级的,我没有实际用PB做过)
//每次计算和传输的时间是可以接受的,
//比如只是简单的应答,(基本上,什么事都可以转换成下面的情况,如果是一个巨大的对话,你可以改成"某某跟大家说，我在哪张表插入了一条数据，主键是XX",各个客户端自己去查。)
//如 某某跟某某说"XX"
//或 某某跟大家说"XX"
//或 某某跟某个工作组说"XX"
//如果存在大数据包的情况,比如"某某跟大家分享一个视频",就必须使用方案B(当然也可以改成"某某FTP了一个大文件,大家去哪里下载",就可以把压力转到FTP或HTTP服务器上)
--------------------
方案A,
在你现有的功能上DEBUG.
这个比较难调,倒不是因为PB不擅长做这件事,
而是因为,PB程序员很少做这件事,导致没有太多现成的例子,健壮的就更少了.
(仅就这件事而言,不论哪种语言,基本上都是调用WINDOWS底层的协议来做,所以在我们上述假定的条件限制下,不存在PB不擅长而VC或C或DEPHI擅长的情况,除非很特别的情况,要不然很少为小系统专门去发明一个车轮的)
//你所觉得的困难，作为VC或C程序员的时候，我也遭遇过,绝不会比PB好调.
经验而言,大概率出问题的机会在,客户端被"强行结束"或网络中断,也就是连接已经没有了,服务器还往那里推数据.
一两次可能没问题,但长期的积累下,就会导致各种你DEBUG不出来的错误.
DEBUG的方向是,找一部电脑做客户端,不断连接你的服务器,不断强制关闭或物理上拔网线再不断连接(两种都试),看看你服务器是怎么崩溃的.
--------------------
方案B,(这个要比方案A健壮很多)
整个框架重新做(多花不了你一个星期的时间)
1.各个客户机都起一个SOCKET监听器(从你的角度,相当于每个客户都有一个服务器在自己机上).
2.这个监听器定时(比如5分钟)去数据库UPDATE一下,说"某某IP在线".(这个专业的术语叫心跳)
3.发消息时,需要发消息的机，自己在数据库中查一下，保持心跳的IP，自己分别向他们发消息.
4.所有收发消息，不保持连接，发完收完各自断开.
5.这个监听器自己定时重启.(内存越界之类的错误就基本不用管了).
6.不要问我，你的机上，有多个不同程序要接收消息怎么做。自己连自己机上的监听器就行了(SOCKET或DDE都可以,还有别的方案，就不举了)
这样，任何一部机的监听器崩溃,都只是自己的事。(其实，因为上述第4点的存在,你几乎不用怎么DEBUG,它都很难崩溃)
你要是想做得好一点，就在每部机上运行一个小程序(当然要自己写)，监视你的监听器,如果它没有响应或崩溃了,就再运行一次监听器.
--------------------
例外,使用方案B,
极小情况下，你可能还需要另外一个知识,"网络穿透"(BAIDU或GOOGLE一下),这个恐怕真的没有人用PB做过。至少我没见过。