Arno Garrels wrote: > Arno Garrels wrote: >> Hi, >> >> I should have tested more carefully, sorry for that. >> After some stress tests with the webserver for MacOS >> I hit a bug today that I do not understand. >> Once in some state Accept() returns a socket handle >> with a port number that doesn't match the port number of >> the connecting socket. > > As a result the response is sent to the nirvana and the > browser waits for a response infinitly. Obviously that > socket handle is valid somehow but nobody is listing at > its other end.
Additionally, when it happens netstat shows some sockets in CLOSE_WAIT state which indicates clearly that the server hasn't called Close() on these sockets. But how is that possible? All client objects are freed (ClientCount = 0) so AFAICT Close() _must have been actually called on any _accepted socket handle. Also the trouble _seems to start after the client starts reusing port numbers. Hours later: Actually in some cases read/accept events are not triggered, hence one neither is able to call Accept() nor Close() on such ghost sockets. OK, that all might be multi-threading issues.. So in order to get what's going on I tried to call accept() in the async thread that waits for kevents on the sockets immediately when the event triggered followed by a call to closesocket(), rather than posting a message to the TWSocket notify window, however even in this case I was able to produce a socket in CLOSE_WAIT state. Looks like _if a client closes a socket when the connection is still in the listen backlog queue no event fires :( -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
