Lightwight socket IO wrapper

Marko Rauhamaa marko at
Mon Sep 21 08:56:44 CEST 2015

Chris Angelico <rosuav at>:

> On Mon, Sep 21, 2015 at 2:39 PM, Marko Rauhamaa <marko at> wrote:
>> Chris Angelico <rosuav at>:
>>> If you write a packet of data, then write another one, and another,
>>> and another, and another, without waiting for responses, Nagling
>>> should combine them automatically. [...]
>> Unfortunately, Nagle and delayed ACK, which are both defaults, don't go
>> well together (you get nasty 200-millisecond hickups).
> Only in the write-write-read scenario.

Which is the case you brought up. Ideally, application code should be
oblivious to the inner heuristics of the TCP implementation. IOW,
write-write-read is perfectly valid and shouldn't lead to performance

Unfortunately, the socket API doesn't provide a standard way for the
application to tell the kernel that it is done sending for now. Linux's
TCP_CORK+TCP_NODELAY is a nonstandard way but does the job quite nicely.

>> As for the topic, TCP doesn't need wrappers to abstract away the
>> difficult bits. That's a superficially good idea that leads to
>> trouble.
> Depends what you're doing - if you're working with a higher level
> protocol like HTTP, then abstracting away the difficult bits of TCP is
> part of abstracting away the difficult bits of HTTP, and something
> like 'requests' is superb.

Naturally, a higher-level protocol hides the lower-level protocol. It in
turn has intricacies of its own. Unfortunately, Python's stdlib HTTP
facilities are too naive (ie, blocking, incompatible with asyncio) to be


More information about the Python-list mailing list