关于服务器套接字编程模型的问题[关闭]

听起来你有几个问题。我会尽力回答我所看到的。

1。我应该如何在网络服务器中处理线程?

我将仔细看看您在服务器生成的工作线程上所做的工作。为每个请求生成一个新的线程不是一个好主意……但是如果并行请求的数量很小,并且在每个线程上执行的任务都在快速运行,则可能不会有任何伤害。

如果您真的想以正确的方式进行操作,那么您可以拥有一个可配置/动态线程池,当工作线程变为空闲时,该池将回收工作线程。这样就可以设置最大线程池大小。然后,您的服务器将工作到池大小……然后发出进一步的请求,等待工作线程可用。

2。如何格式化数据包中的数据?

除非你正在开发一个全新的协议……这不是你真正需要担心的事情。除非您正在处理流媒体(或其他可接受数据包丢失/损坏的应用程序),否则您可能不会对此应用程序使用UDP。TCP/IP可能是您的最佳选择……这将决定您的包设计。

三。我使用哪种格式进行序列化?

通过网络序列化数据的方式取决于什么类型的应用程序将使用您的服务。二进制序列化通常更快,并且会产生少量需要通过网络传输的数据。使用二进制序列化的缺点是,一种语言中的二进制序列化可能无法在另一种语言中工作。因此,连接到您的服务器的客户机很可能必须用您所使用的语言编写。

XML序列化是另一个选项。它将花费更长的时间,并且有更多的数据要通过网络传输。使用XML序列化之类的东西的好处是,您不会被限制为可以连接到服务器并使用您的服务的客户机类型。

你必须选择最适合你需要的。

…利用不同的选项,找出最适合你的方案。希望你能找到比我在这里提到的任何东西都更快、更可靠的东西。

就服务器设计而言,我想说您是对的:虽然每个套接字一个线程是一种简单而容易的方法,但这并不是一种可行的方法,因为它无法像其他服务器设计模式那样进行扩展。

我个人喜欢通信线程/工作线程的方法,在这种方法中,一个动态数量的工作线程池处理由生产线程生成的所有工作。

在这个模型中,池中有许多线程在等待将从另一组处理网络I/O的线程生成的任务。

我发现 UNIX Network Programming 作者:RichardStevens,这类网络编程方法的惊人来源。而且,尽管它的名字,它在Windows环境中也将非常有用。

关于数据包的布局(在我看来,您应该为此发布一个不同的问题,因为这是一个完全不同的问题),在选择文本与二进制方法时存在权衡。

文本(即XML)可能更容易解析和记录,一般来说更简单,而二进制协议在处理速度和网络数据包大小方面会给您带来更好的性能,但是您必须处理更复杂的问题,如字的结束符和类似的东西。

希望它有帮助。

虽然前面的答案提供了很好的方向,只是为了完整性,但我想指出,线程并不是对优秀的socket服务器性能的绝对要求。一些例子是 here .还有许多可扩展性的方法-线程池、预分叉进程、服务器池等。

1) 最后,是否有任何易于使用的库,它通常是支持可移植性(例如在Windows机器上开发和在Linux设备上部署),而不是Boost ASIO。

这个 ACE 图书馆是另一种选择。它非常成熟(从90年代初开始就有了),而且部署广泛。关于它与 Boost ASIO 在上可用 Riverace 网站 here .请记住,ACE必须支持大量遗留平台,因此它不能像Boost ASIO那样使用现代C++特性。

2) 假设我想在C++中构建一个服务器,它将处理成千上万个独立的和/或Web应用程序的输入,那么我该如何设计我的服务器呢?到目前为止,我通常为每个连接的用户创建一个新的和唯一的线程,但我怀疑这是一种方式。

有许多常用的方法,包括但不限于: 每个连接的螺纹 (你描述的方法)和 线程池 (贾斯汀描述的方法)。各有利弊。很多人都在权衡。一个好的起点可能是 Thread Pool Pattern 维基百科页面。

Dan Kegel的“ The C10K Problem “网页上也有许多关于提高可伸缩性的有用注释。

3) 此外,如何确定通过网络发送的数据包的布局;数据通常是以二进制或文本状态通过网络发送的?当您将数据发送到不同的媒体(如C++服务器到Flash应用程序)时,如何处理序列化对象?

我同意其他人的观点,即发送二进制数据通常是最有效的。这个 boost serialization 库可用于将数据封送为二进制形式(以及文本)。成熟的二进制格式包括 XDR 和 CDR . cdr是使用的格式 CORBA 例如。公司 ZeroC 定义 ICE 编码,这应该比CDR更有效。

有许多二进制格式可供选择。我的建议是,至少通过阅读这些二进制格式中的一些来避免重新设计轮子,这样你就不会碰到这些现有的二进制格式设计用来解决的相同缺陷。

也就是说,很多 middleware 已经为您的大多数需求提供了一个封闭的解决方案。例如, OpenSplice 和 OpenDDS 都是 OMG Data Distribution Service 标准。DDS注重数据的有效分发,例如通过 publish-subscribe model 而不是远程调用函数。我更熟悉OMG定义的技术,但我确信还有其他中间件实现可以满足您的需求。

您仍然需要一个套接字来处理每个客户机,但是这个想法是创建一个X套接字池(比如50个),然后,当您接近(比如90%)使用所有这些套接字时,创建另一个X套接字池。在某些时候,在客户机连接、发送数据和断开连接后,您的一些套接字将可用,您可以使用它们(此信息的Google套接字池)

数据的布局总是很困难的。如果您的所有客户机和服务器都将使用相同的硬件和操作系统,那么您可以以二进制格式发送数据,但其中有许多行程和陷阱(字节对齐在列表的顶部)。发送格式化的文本总是更容易,但在带宽和处理能力方面肯定更昂贵,因为在发送之前必须将格式从机器更改为文本,当然,还必须在接收器处再次更改。

回复:连载,对不起,我帮不了你,也帮不了图书馆(我嵌入得太深了,没法用太多)

关于服务器套接字和序列化(封送)。最重要的问题是增加sockets数目是选择中可读写状态。我不是关于fd_集合的限制。这是可以简单解决的。我是关于在处理评估的套接字中可用的数据时,信令时间的增长和未读套接字中的问题数据积累。因此,当处理器的角色受到限制时,解决方案甚至可能超出软件边界,需要多个处理器模型:一个读写,n个处理。在这种情况下,当select返回并发送到另一个处理单元时,所有可用的套接字数据都应该被读取。

对于传入的数据也是如此。

关于编组。粗略地说,二进制格式更可取,因为性能更好。顺便说一句,就Unicode而言,XML也有同样的问题。但是,…同志们,这不是简单地将长或整数值复制到套接字流中。但在这种情况下,即使是HTONS,HTONL也能提供帮助(它以nw格式发送/接收数据,OS负责数据转换)。但更安全的是,在表示头之后发送数据,其中显示了大多数/最低有效位的格式、字节顺序和IEEE数据类型。这行得通,我当时没有案子。

向大家致以亲切的问候,并取得巨大的成功。 西蒙康托