On Mon, 17 Aug 2009, Jonas Maebe wrote:
On 17 Aug 2009, at 17:43, Michael Van Canneyt wrote:
The reason for this - which has been given often - was the atypical
window size of the router in front of the server: Some ISP's routers or
network configuration could not cope with this atypical window size.
To nitpick: it's not the window size, but the maximum segment size :)
And for the people interested in the details: the problems are that router in
front of server
a) blocks incoming ICMP packets that are necessary for automatic MTU
detection. As a result, the server cannot detect problems in case a network
connection down the line requires a smaller TCP segment size.
b) set the TCP maximum segment size of all *incoming* packets to 1472. This
means that setting the MTU on your computer to a low value (which would then
also be used by the server when replying) won't help, since the server always
sees an MTU of 1472 bytes.
c) sets the "don't fragment" flag on outgoing IP packets. This means that
even if the server is configured to not add the "don't fragment" flag to
packets so they can be fragmented by other routers when sending them over a
connection with a smaller MTU, the end result won't change since by the time
the packets arrive at those routers, they'll again have a DF flag set.
In the end, what did work was to enable TCP MTU detection on the server.
I don't know what kind of router is being used, but I would advise everyone
to stay away from it as far as possible. The number of ways in which that
thing tries to prevent connectivity with low-MTU endpoints is really
astounding.
It's a very common CISCO router :-)
The problem is not really the router itself, but the instructions we got from
the ISP on how to configure it :(
(totally braindead instructions in my opinion, but arguing didn't really help)
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
