我正在为我工作的办公室使用内部电话系统软件。我们正在使用Twilio管理我们的电话树 - 但是一旦呼叫者与我们的一个人联系，我们想创建一种更好的方法来监控来电和转接呼叫。
我们处于混合（Windows和Mac）环境中，因此我选择使用Python运行来编写此应用程序的桌面部分。我（大部分时间）仍然处于这个项目的纸笔阶段。我有一些Python / TKinter经验，以及一些TCP Socket经验（使用CakePHP，而不是Python），并且有一些关于如何管理我们的服务器（向Twilio发出命令）和客户端应用程序之间的数据包传输的问题。 p>
客户端应用程序将向用户显示呼叫队列中的呼叫者数量，并允许用户接听其电话上的呼叫，以及将呼叫者发送回队列（或另一个代理）。以下是我考虑过这两种方式：
方法1
客户端（Python）应用程序侦听来自VPS的TCP连接。这将是内存密集度最低的，但在buff-sizes上读取this post，特别是
关于：“如果你有一个协议，其中传入的数据包长度是完全已知的，显然最好只读”最多“你正在处理的数据包需要什么，否则你可能会吃下一个数据包，这将是恼人的。“
这对于应用程序开发人员来说可能更合适，但对于底层网络堆栈来说可能效率低下。首先，它绑定了可用于其他网络I / O的套接字缓冲区空间。其次，你创建的每个recv（）意味着进入系统调用/内核空间，并且转换会有性能损失。最好是尽可能少的系统调用从内核空间中获取尽可能多的数据并进入用户空间，并在那里进行消息解析。这增加了应用程序代码和消息处理的复杂性，但可能是最有效的。
我真的很矛盾 - 正在吃下一个小包吗？我怎样才能预测buff的大小或我需要？
方法2
我可以每隔n秒对应用程序进行一次“联合状态”查询。但这似乎很浪费。
什么是正确的答案。有什么我想念的吗？
答案 0 :(得分：1)
你读过的那个缓冲区大小谈到了低级细节，只有很小的性能影响。这不是你通常应该关心的东西，如果你对你想要使用的协议知道的是它是“tcp”，那就更少了。首先，您需要通过TCP设计协议。而且我的意思是你需要以某种方式格式化你的消息。
所以，对于你问的“吃下一个数据包”的问题 - 你忽略了这个帖子谈论一个协议（通过TCP）这个事实，包括作为流的一部分的数据包长度，或每个数据包具有固定/可预测的大小。这些“数据包”只是应用程序要处理的信息单元，您不应将tcp缓冲区大小视为问题的一部分。
“吃下一个数据包”会发生，如果你只是回忆太多而你读到的部分内容属于下一个数据包 - 如果你决定忽略那个额外的部分，那么你就吃了它。但是，没有什么能阻止你以后保存它。只要您始终在代码中的某个点处理每个接收到的字节，缓冲区大小就可以是任何值。
关于“方法2”，如果我正确读取它将进行轮询，这只是一个好主意，如果你不能做任何其他事情（HTTP服务器的常见情况）
我对此问题的建议是不重新发送另一个协议来传递消息并使用，例如zeromq，这是一个可移植的消息队列库，它实际上只是一个使用设计良好的TCP协议的套接字库。 / p>