Chris Angelico <ros...@gmail.com>: > On Mon, Sep 21, 2015 at 2:39 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: >> Chris Angelico <ros...@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 -- https://mail.python.org/mailman/listinfo/python-list
