Charles-François Natali added the comment: > Thanks for the patch. Perhaps our MSS value should be an upper bound of > common values? Apparently for a localhost connection TCP_MAXSEG gives 16384 > here (but I don't know if the http.client optimization is important for > localhost connections).
According to http://en.wikipedia.org/wiki/Maximum_transmission_unit, the MTU (from which the MSS is derived) for a wireless NIC is around 8000, and you can have jumbo frames on Ethernet up to 9000, so a value of 2K might be too small (since the goal is to avoid sending a payload less than MSS with its own send() syscall). So I think a value like 16K should be OK (the downside to using a large value is the extra copying, but OTOH it will incur less copying than now). Note that the ideal fix for this would be scatter-gather I/O with sendmsg(): both the header and the payload could be sent in the same segment, without any extra copying. But I'm not sure it's worth it here. A note on the comment: """ 722 # TCP Maximum Segment Size (MSS) is a TCP stack parameter. There 723 # is no simple and efficient platform independent mechanism for 724 # determining the MSS, so instead a reasonable estimate is chosen. """ The MSS is not really a TCP stack parameter (i.e. it's not fixed by the host like socket buffers, etc): it's usually negociated between the hosts (and with path MTU discovery or IPv6 it depends on the path MTU). That's why it's hard to guess ahead of time. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16833> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
