Lightwight socket IO wrapper

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:

> On Mon, Sep 21, 2015 at 2:39 PM, Marko Rauhamaa <marko at pacujo.net> wrote:
>> Chris Angelico <rosuav at gmail.com>:
>>
>>> 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
degradation.

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


Marko