[Python-ideas] TCP Fast Open protocol

[Ronald Oussoren]

On 11 Jan, 2013, at 9:50, Jim Jewett <jimjjewett at gmail.com> wrote:

> 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.

It must be explictly requested by the server because the behavior might change,
in particular the lwn.net page about this feature mentions that duplicate SYN
messages are not detected, and if I parse that page correctly that might mean
that the servers gets two or more requests when the connection is unreliable (or
slow) and retransmission happens. That is fine for static webpages, but not if
the client request has side effects (e.g. the server starts updates a database).

BTW. This (linux-only) feature is very new, it would IMHO be useful to use this
in real life with a package on PyPI that monkeypatches the stdlib before adding
the feature to the stdlib.   It is currently not clear if the option will be usefull in the long
run.

Ronald