谈谈你接触的通讯程序的模型

jiang1013nan

回复 40# maclaurin


    是的。对于处理UDP，目前我们没有好的处理方案对于通讯与业务分离的架构。在实际生产环境中，我们采用的是TCP的方式。

一介村夫

多线程模型就像人弹，有人要死，却拉上一大堆垫背的。

我再说一遍：多进程模型是用于每个进程干自己的事，互相不影响；多线程模型是用于所有线程协调干一件事，每个线程负责一个部分。

多线程模型中的线程，彼此的工作内容应该是不同的，同时又是互补的，大家完成的是同一件事的不同部分。基于这样的理解进行设计，就不存在“人弹”的可能性。

所以在一般通讯服务程序的场合，绝对应该使用多进程模型。

进程与线程，看着相似，实际的出发点和作用是不同的，所以不能乱用，要根据应用模型进行选择。再说得浅显点就是：在一个多线程模型中，任何两个线程都不应该使用同一个函数作为入口点！

jiang1013nan

回复 42# 一介村夫


嗯。有一定道理嗯。
但是也存在多个线程干一类事情，但是相互独立的事情。

duanjigang

第一：你们的通讯程序独立于应用程序吗？？？
独立，一个前置通讯网关对应多个应用服务器。

第二 ...
maclaurin 发表于 2011-01-10 22:00

    恩，大致明白了。有个问题喔，通讯程序相当于做成了一个独立的中间件了。这样的话，应用程序其实不必再关注通讯程序使用到的协议了吧？
如果你们的通讯已经独立于应用了，我想应该是这样吧？那么，这时是不是都应该用TCP来实现？为了可靠起见。谢谢

一介村夫

回复  一介村夫


嗯。有一定道理嗯。
但是也存在多个线程干一类事情，但是相互独立的事情。
jiang1013nan 发表于 2011-01-11 09:05

    一个进程崩溃，毁掉的是一大批事情，而不仅仅是出问题的那一个，这不合理。
而且在这种模型中，你无法中断一个已经出现问题的独立事情。

进程和线程在系统开销上的那点差别，远远小于你应用程序写得好与不好的差别，不同的人为同一个事情写程序，开销差别都很大，何必在乎进程和线程开销间的这一点差别呢？真在乎系统开销，就先认真写好自己的应用程序吧。

所以，一定要选择适合的模型做适合的事情。

duanjigang

多线程模型就像人弹，有人要死，却拉上一大堆垫背的。

我再说一遍：多进程模型是用于每个进程干自己的事 ...
一介村夫 发表于 2011-01-10 23:21

    阿村说的很精辟，应该是多年的经验感言！
但是有些人出于节省代码量的想法还是违背这些原则了，比如为了使用公共的全局变量，节省代码量，把通讯的server端和client端做成了两个线程。
呵呵，我就这么搞过
关于数据处理部分，现在完全做成了独立的进程，每个消息处理插件一个子进程，也是充分考虑到“人弹”这个因素了。
看样子通讯程序本身，还应该再分离出来。这样才合理。

duanjigang

当然：连接和数据发送在一个进程中用多线程，这是合理的。
但是连接和数据发送线程所属的进程和数据接收部分，应该独立开，是两个进程

swxlion

回复  duanjigang

在实际生产环境中达到了8K人左右额。
jiang1013nan 发表于 2011-01-10 20:51

    关于这个数据，是在怎么样的情况下获得的？
不知单台服务器是怎样的配置情况：操作系统、CPU位数、CPU个数x单个CPU核数、内存大小，网卡/网络带宽限制、非业务相关压力负载情况（比如在同一台机器上，是否有web服务器正在提供非被测业务的服务？）。每秒发包数、平均包大小。因为在我以前的性能测试经验中，这些对最终性能数据影响很大。如果没有全部说明的话，则对比性就不强了。

qianhulou

我一直都用的阻塞, 但是对于非阻塞 我个人认为和阻塞差不多.  对端主动关闭, RECV返回0, 对端异常关闭 非close() shutdown的 RECV返回-1, 如果没有数据来 RECV也返回-1, 根据errno来区分是哪中情况. 心跳包 是用来检测路由的, 比如A->switch->B , switch那里网线掉了, A和 B一般情况是检测不到的, 除非那个交换机有这个功能或者SOCKET设置了那个TCP自测的选项.如果A->B直连的话, 只要网线中间不断开, 有没有心跳包 效果一样....

ruifengzhangyi

有个问题想请教ls各位大拿
采用第一种模型
while（1）
{
accept()
pthread_create()
}
是否存在一些弊端，对于高并发的请求的情况下，服务器容易当掉，只能采取没有办法的办法在pthread_create()
后睡眠几微秒，可以一定程度的缓解。