Re: [twsocket] Major bug in first ICS FireMonkey / MacOS beta (fixed)
Hi, Just checked in a fix: IPv6 MacOS - Bugfix in main event loop. Accept events were lost when a connection request still pending in the listen backlog queue was closed by the peer. Fixed by use of level triggered events and disable/enable the filter as required (similar as read events as well). Available via svn, URL: svn://svn.overbyte.be/ics/branches/icsipv6 Both user and password ics Currently FireMonkey and MacOS is only available for Delphi (partly). The following Delphi demos in folder PlatformDemos however should work and are ready for testing: IcsCliDemo IcsTcpSrvIPv6 IcsConSmtp IcsMailSnd IcsHttpTst IcsWebServ IcsFtpTst IcsFtpServ IcsThreadTimerDemo -- 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
Re: [twsocket] Major bug in first ICS FireMonkey / MacOS beta
Arno Garrels wrote: state. Looks like _if a client closes a socket when the connection is still in the listen backlog queue no event fires :( Problem/reason found :) When kqueue fires an accept-event its Data member contains the number of connect requests waiting in the listen backlog queue. Ignoring this number and trusting on subsequent events will fire even if a client closes a connection request that is still not accepted was the issue (lost events as described in my previous messages). I did a brief test. When I send as many FD_ACCEPT messages as there are pending requests in the listen backlog queue to the server the calls to accept() very often fail with (WSA)EWOULDBLOCK, however no events are lost and it seems to work reliably. But that were a waste of resourses, something more efficent has to be found. Any idea? -- 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
Re: [twsocket] Major bug in first ICS FireMonkey / MacOS beta
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
Re: [twsocket] Major bug in first ICS FireMonkey / MacOS beta
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. -- 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
