[Python-ideas] TCP Fast Open protocol

Fri Jan 11 18:50:25 CET 2013

On 1/11/13, Federico Reghenzani <federico.dev at reghe.net> wrote:
> On Fri, Jan 11, 2013 at 3:45 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> Yes, the protocol has been designed for situations where there are multiple
> requests such as HTTP or FTP. Probably only in these cases default
> 'True' option is appropriate.

What is the harm of using it in other situations? If the answer were truly
just "4 bytes per host", then it might still be a good tradeoff.
>> To be active, the feature must be compiled into the socket code of both
>> server and client machines AND must be explicitly requested by both
>> client and server applications.

This, however, is a problem.
Based on (most of) the rest of your descriptions, it sounds like a
seamless drop-in replacement; it should be an implementation detail
that applications never ever notice, like having a security patch
applied to the operating system when python isn't even running.
But if that were true, an explicit request would be overly cautious,
unless this were truly still so experimental that production servers
(and, thus, the python distribution in a default build) should not yet
use it.
Also note that if it isn't available on Windows (and probably even
on Windows XP without additional dependencies), Python can't
yet rely on it.
Below, you also say that it is not appropriate for servers unless
syn+data is idempotent -- but I don't know even what that means
without looking it up, let alone whether it is true of my app -- so it
sounds like a bug magnet.
> The server know the client connection type by the first packet that it
> sends: if the first packet coming by client is a SYN+TFO cookie the server
> proceed to generate cookie and continue with a FastOpen connection, if the
> first packet is a SYN, the server proceed with normal 3-handshake
> connection. In any case these operations are transparent both to Python
> that application because they're made by kernel.

So how is this a python issue at all? Because of the explicit request?
Because of the need to keep something idempotent?
I see no harm in letting open accept and pass through additional optional
arguments, or in a generic way to query the kernel for its extensions, but
if you need something specific to this particular extension, then please
do it as an external package first.
>> On the client side, .connect and at least the first .send must be
>> combined
>> into either .sendto or .sendmsg (which?, still to be decided,
>> apparently;-)
>> with a new MSG_FASTOPEN argument. So programs need a non-trivial rewrite.

Application programs, or just the plumbing in the httplib?
-jJ