Is it necessary to communicate (or anticipate) Python Socket TCP Buff sizes

Question

I am working on internal phone system software for the office I work for. We are hapily using Twilio to manage our phone tree - but would like to create a better way to monitor incoming calls and forward calls once the caller has been connected with one of our guys.

We are in a mixed (Windows and Mac) environment, so I have elected to run with Python to write the desktop portion of this application. I am (for the most part) still in the Pen-and-Paper stage of this project. I have some Python/TKinter experience, and some TCP Socket experience (using CakePHP, not Python) and have a few questions about how to manage packet transfers between our server (which is issuing the commands to Twilio) and the client app.

The client application will display the number of callers in a call queue to the user, and allow the user to accept a call on their phone, as well as send a caller back to the queue (or to another agent). Here are two ways I have considered doing this:

Method 1

The client (Python) application listens for TCP connections from our VPS. This would be the least memory intensive, but having read this post on buff-sizes, specifically

In regards to: "if you have a protocol where the incoming packet length is exactly known, it is obviously preferrable to only read "at most" what is needed for the packet you are dealing with, otherwise you could potentially eat into the next packet and that would be irritating."

This may be preferable for the application developer, but is probably inefficient for the underlying network stack. First, it ties up socket buffer space that can be used for additional network I/Os. Second, each recv() you make means dipping into a system call/kernel space and there is a performance penalty for the transition. It is always preferable to get as much data as you can out of kernel space and into user space with as few system calls as possible and do your message parsing there. This adds more complexity to the application code and message handling but is probably the most efficient.

I am really conflicted - is eating the next packet a thing? How can I anticipate the buff size or do I need to?

Method 2

I could just have the application query for a "state of the union" every n seconds. But that seems wasteful.

What's the right answer. Is there something I am missing?

Answer 1

That buffer size post you've read talks about low-level details, which only have minor performance implications. It's not stuff you should normally care about, even less if you all you know about the protocol you want to use is that it's "tcp". First of all, you'll need to design a protocol over TCP. And by that I mean that you need to format your messages, somehow.

So, regarding the question you're asking about "eating the next packet" - you're ignoring the fact that the post talks about a protocol (over TCP) that includes packet length as part of the stream, or that every packet has a fixed/predictable size. These "packets" are just units of information that your application wants to process, and you shouldn't consider tcp buffer sizes as part of the problem.

"Eating the next packet" happens if you just recv too much and part of what you read belongs to the next packet - if you decide to ignore that extra part, then you eat it. Nothing stops you from saving it for later, though. The buffer size can be anything as long as you always process every received byte at some point in the code.

Regarding "method 2", if I'm reading it correctly that would be polling, which is only a good idea if you can't do anything else (a common situation with HTTP servers)

My recommendation for this issue is to not reinvent another protocol to pass messages and use, for instance zeromq, which is a portable message queue library that is really just a socket library using a nicely designed TCP protocol.