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
Visit our website at

Reply via email to