homepage

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