.net NET中消息框架方法的优缺点
我正在研究我所知道的两种不同TCP消息帧方法的优缺点.net NET中消息框架方法的优缺点,.net,sockets,.net,Sockets,我正在研究我所知道的两种不同TCP消息帧方法的优缺点 Delimited：TCP流通过使用分隔符字节分解为非固定长度的消息。发送数据时，例程必须检查消息数据中的分隔符，并将其转义，以确保消息帧的安全传输。当接收数据时，例程必须读取流，寻找分隔符字节，以将帧分解为消息 例如：用户[用户名]\n密码[密码]\n 长度前缀：TCP流通过使用4个字节的前缀来表示消息的长度，被分解成预定大小的消息。当接收数据时，例程将首先读取前缀以确定消息帧的长度。发送数据时，例程必须在传输前将长度前缀前置到消息 例如：
因此，我将注意力集中在可伸缩性和性能效率上。我发现自己需要运行基准测试，看看哪种方法可以在不涉及任何消息处理的情况下获得最大的效率吞吐量
我现在的想法是，无论如何我都不是专家 在接收例程期间，带分隔符的消息帧效率较低，因为流中的每个字节都需要检查消息帧分隔符。长度前缀消息帧将始终读取前缀字节，消息帧流的其余部分将直接进入缓冲区而不进行处理，直到接收到整个消息帧 其中，作为长度前缀的消息帧在发送例程期间的效率将较低，因为消息前缀将在消息本身之前发送
我认为其他因素可能包括：
- 大量的小消息帧将导致以长度前缀结构传输更多的数据包
- 使用长度前缀结构可以更有效地处理大量较大的消息帧，因为没有读取每个字节以检查分隔符
任何关于这个话题的光都会很棒。我发现很难找到关于TCP消息帧结构之间差异的好资源。根据我的经验，首选长度前缀，消息的解析代码往往更容易编写 此外，对于消息分隔符，如果消息负载可能包含分隔符字符，则需要找出转义方案 我遇到了第三个方案，它不是有效载荷不可知论。它使用已知的格式定义不同的消息类型，消息的不同部分可以是固定长度，也可以是可变长度。（对于简单类型和变量为数组和字符串的情况已修复）。该结构预先在客户端和服务器之间共享。发送消息时，消息的前缀为消息类型编号。从消息类型号，接收部分可以推断如何解析消息。
这方面的一个例子是LysKOM信息系统的。
该协议有一个可用于生成解析器代码的正式规范。您正在尝试发明TCP/IP的另一部分IP。这是行不通的，它已经存在了，你不能直接影响它，也不需要任何帮助。TCP是一个流，试图将其分解成碎片会使其效率非常低。只有选项2是合格的。我说的是您必须实现的消息框架，以通过TCP流在数据包中传输数据。我不想发明任何东西。我试图讨论您选择实现的框架的优缺点。例如，像“USER[Username]\n”这样的分隔消息框：其中“\n”是分隔符，因此它是分隔消息框。我认为大多数协议使用分隔消息框是对的。例如FTP、HTTP、DCP、POP、SMTP、UPNP等？我知道，所列的一些具有切换机制，可能同时使用这两种机制。