Hi,
This is a follow up on my posts in the same thread, mostly made in March 2015). After further extensive testing I have found the following bugs/issues (in addition to the ones mentioned in my previous posts) and have the following solutions: 1. After the TWSockets multithreaded server is created and has entered the wsListening state, it will stay in this state until it closed. However, if it has not actually had any connections, then even when it has been closed, it will stay in the wsListening state. The solution to this in your ServerClose function is to DisconnectAll, CloseDelayed, and then wait (Sleep) until either the state becomes wsClosed or the ClientCount is zero. By this point there should be no connections, but if there were many lots of connections then whilst closing the existing connections (8000), new ones may have been established. To combat this I re-issue a DisconnectAll and then Free then server. It's a messy solution to shutting down a multithreaded server, and there is potential for error conditions to creep in, but it does work for me. 2. In my server implementation, I have and atomic counter to keep track of the number of active sessions. When a client was authenticated (my own validation of initial data received on the connection) I would call InterlockedIncrement to update the session counter. Then when the client disconnected (and had authenticated) I then called OnClientDisconnect. My OnClientDisconnect also tidied up my own classes objects (and freed associated memory). This worked perfectly for 10's of millions of connect/disconnect cycles. But occasionally, with all clients disconnected, I noticed my session counter would suddenly read a positive value ie. 57 and that over time, it would increment in chunks. In my application, memory resources were also not being freed. After further investigation I found that in fact OnClientDisconnect does not actually get called for small blocks of disconnections, and that this happens only very occasionally, but randomly. My guess on what is happening is that the disconnect event is trying to fire after the client has been freed. In summary, do not use OnClientDisconnect to do anything you need to have done i.e. freeing memory, updating counters - instead use the OnClientDetach event to tidy up. Note to Angus: In one of your responses you mentioned that you had an unpredictable but very slow memory leak in one of your apps using the ICS multithreaded server - I suspect that this is the issue. Regards, Tim -- 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
