是否有必要传达（或预期）Python Socket TCP Buff大小

Question

我正在为我工作的办公室开发内部电话系统软件。我们很乐意使用Twilio来管理我们的电话树-但希望创建一种更好的方法来监视来电并转接呼叫者与我们其中一个人的通话。我们处于混合（Windows和Mac）环境中，因此我选择与Python一起运行，以编写此应用程序的桌面部分。我（大部分情况下）仍处于该项目的“笔与纸”阶段。我有一些Python / TKinter经验，还有一些TCP Socket经验（使用CakePHP，而不是Python），并且对如何管理服务器（向Twilio发出命令）和客户端应用程序之间的数据包传输有一些疑问。客户端应用程序将向用户显示呼叫队列中的呼叫者数量，并允许用户接受其电话上的呼叫，以及将呼叫者发送回队列（或另一个座席）。这是我考虑过的两种方法：方法1客户端（Python）应用程序侦听来自我们VPS的TCP连接。这将是最内存密集型的，但看了这个帖子上的buff，尺寸，特别是关于：“如果您有一个协议，其中确切知道传入的数据包长度，则最好只“最多”读取您要处理的数据包所需的内容，否则可能会吞噬下一个数据包那会很烦人。”对于应用程序开发人员来说，这可能是更好的选择，但对于基础网络堆栈而言，这可能效率很低。首先，它占用了可用于其他网络I / O的套接字缓冲区空间。其次，您制作的每个recv（）都意味着进入系统调用/内核空间，因此转换会降低性能。总是最好通过尽可能少的系统调用从内核空间和用户空间中获取尽可能多的数据，然后在此处进行消息解析。这增加了应用程序代码和消息处理的复杂性，但可能是最有效的。我真的很矛盾-吃下一包东西吗？我怎样才能预测抛光效果的大小？方法2我可以让应用程序每秒钟查询一次“联盟状态” n。但这似乎是浪费。正确的答案是什么。有什么我想念的吗？

Answer 1

您阅读过的有关缓冲区大小的文章讨论了低级细节，这些细节仅会对性能产生微小影响。它通常不是您应该关心的东西，即使您只知道要使用的协议是“ tcp”，就更不用说了。首先，您需要设计基于TCP的协议。我的意思是，您需要以某种方式设置消息的格式。

因此，关于您要询问的“吃下一个数据包”的问题-您忽略了以下事实：该帖子所讨论的协议（通过TCP）包括数据包长度作为流的一部分，或者每个数据包都有一个固定/可预测的大小。这些“数据包”只是您的应用程序要处理的信息单元，您不应将tcp缓冲区大小视为问题的一部分。

如果您吃得太多，就会发生“吃下一个小包”，而您所阅读的部分内容属于下一个小包-如果您决定忽略那多余的一部分，那么您就吃掉它。不过，没有什么可以阻止您将其保存以备后用。缓冲区大小可以是任意值，只要您始终在代码中的某个时刻处理每个接收到的字节即可。

关于“方法2”，如果我正确阅读它，将进行轮询，这是一个好主意，如果您无法执行其他任何操作（HTTP服务器的常见情况）

我对这个问题的建议是，不要重塑另一个协议来传递消息并使用它，例如zeromq，它是一个可移植的消息队列库，实际上只是一个使用精心设计的TCP协议的套接字库。