1

我正在为我工​​作的办公室开发内部电话系统软件。我们很高兴使用 Twilio 来管理我们的电话树 - 但希望创建一种更好的方法来监控来电并在来电者与我们的一个人建立联系后转接来电。

我们处于混合(Windows 和 Mac)环境中,因此我选择使用 Python 运行来编写此应用程序的桌面部分。我(在大多数情况下)仍处于该项目的笔和纸阶段。我有一些 Python/TKinter 经验和一些 TCP Socket 经验(使用 CakePHP,而不是 Python),并且对如何管理我们的服务器(向 Twilio 发出命令)和客户端应用程序之间的数据包传输有一些疑问。

客户端应用程序将向用户显示呼叫队列中的呼叫者数量,并允许用户在他们的电话上接受呼叫,以及将呼叫者发送回队列(或另一个代理)。以下是我考虑过的两种方法:

方法一

客户端 (Python) 应用程序监听来自我们 VPS 的 TCP 连接。这将是最少的内存密集型,但是阅读了这篇关于 buff-sizes 的帖子,特别是

关于:“如果您有一个确切知道传入数据包长度的协议,显然最好只读取“最多”您正在处理的数据包所需的内容,否则您可能会吃掉下一个数据包那会很烦人。”

这对于应用程序开发人员可能更可取,但对于底层网络堆栈可能效率低下。首先,它占用了可用于额外网络 I/O 的套接字缓冲区空间。其次,您所做的每个 recv() 都意味着进入系统调用/内核空间,并且转换会降低性能。始终最好使用尽可能少的系统调用从内核空间获取尽可能多的数据并进入用户空间,并在那里进行消息解析。这增加了应用程序代码和消息处理的复杂性,但可能是最有效的。

我真的很矛盾——吃下一包是一回事吗?我怎样才能预测增益大小或我需要?

方法二

我可以让应用程序每秒钟查询一次“联合状态” n。但这似乎很浪费。

什么是正确答案。有什么我想念的吗?

4

1 回答 1

1

你读过的那个缓冲区大小的帖子谈到了低级细节,这些细节只会对性能产生很小的影响。这不是您通常应该关心的东西,如果您对要使用的协议的全部了解是“tcp”,则更不用说。首先,您需要设计一个基于 TCP 的协议。我的意思是你需要以某种方式格式化你的消息。

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

如果您只是接收太多并且您阅读的部分内容属于下一个数据包,则会发生“吃下一个数据包” - 如果您决定忽略那个额外的部分,那么您就吃掉它。不过,没有什么能阻止您将其保存以备后用。只要您始终在代码中的某个位置处理每个接收到的字节,缓冲区大小可以是任何值。

关于“方法 2”,如果我没看错,那就是轮询,如果你不能做任何其他事情,这只是一个好主意(HTTP 服务器的常见情况)

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

于 2013-06-10T03:54:54.543 回答