Asankha What you are looking at is TCP platform-dependent behaviour. There is a 'backlog' queue of inbound connections that have been completed by the TCP stack but not yet accepted by the application via the accept() API. This is the queue whose length is specified in the 'C' listen() method (although the platform is free to adjust it either up or down, and generally does so). When the backlog queue fills, the behaviour for subsequent incoming connections is platform-dependent:
(a) Windows sends an RST (b) other platforms ignore the incoming connection, in the hope that the backlog will clear and the client will try again. An RST sent because the backlog queue is full is indistinguishable from an RST sent because there is nothing listening at that port, so in either case you should get 'connection refused' or possibly 'connection reset by peer'. Failure to reply at all is indistinguisable from a lost packet, so TCP should retry it a few times before timing out and giving a 'connection timeout'. Whether Windows is correct in sending an RST is debatable but it's been doing it for decades and it certainly isn't going to change. Tomcat and indeed Java have nothing to do with this behaviour, and expecting either to be modified to 'fix' it would be like keeping a dog and barking yourself. EJP --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
