Re: [twsocket] RES: issues with wndcontrol's message dispatch mechanism
Hi Arno and others, I have a simple one-click app which shows some aspect of the problem (unexpected drop, unexpected data, etc) at near 100% reproduction change. Should I put it on the mailing list or should I sent it directly? Merijn On 1-6-2013 02:31, Merijn Bosma wrote: Hi Eric and Arno, Thanks for the quick responses, I hadn't read your other thread yet Eric, but it most certainly is the same issue. I'll try your solution asap and it sounds like the best way to solve this. Will get back on this thread when I know if this helped! Merijn On 31-5-2013 23:32, Eric Fleming Bonilha wrote: Merijin, Apparently you have the very same problem as I do... Try this fix to ICS library and see if the problem still persists (These changes fixed my issue): Inside routine "procedure TCustomWSocket.InternalClose(bShut : Boolean; Error: Word)" I have added the following line: WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); Just after if FState = wsClosed then Exit; In my findings, even after closing the socket, winsock still sends messages to the registered handle (Registered by ASyncSelect), so, here I´m telling winsock to unregister all messages (As soon as socket is closed) The source should be like: if FState = wsClosed then Exit; WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); This is from TCustomWSocket.InternalClose Try adding this line and see if the problem persists (Just for testing), if it fixes it will give more hints for Arno and François, because that was how I fixed my issue (Check on the newsgroup my message entitled: "Shared handles problem". My issue is even worse because I use ICS shared handle system everywhere that I need messaging, because ICS shared handle approach uses way less system resources! Best Regards Eric -Mensagem original- De: TWSocket [mailto:twsocket-boun...@lists.elists.org] Em nome de Merijn Bosma Enviada em: sexta-feira, 31 de maio de 2013 12:46 Para: twsoc...@elists.org Assunto: [twsocket] issues with wndcontrol's message dispatch mechanism Hi all, I think I've encountered an issue in the message dispatch system which is used by wndcontrol. What I'm doing is creating and destroying some sockets: - socket 1 registers message 1043 as FMsg_WM_ASYNCSELECT (OverbyteICSWSocket:5696). - this socket is free'd - we start a server - a client connects, so a new socket is instantiated (socket 2), which registers it's FMsgRelease message (OverbyteICSWndControl:562), and also gets 1043 for that message - now it seems we get a WM_ASYNCSELECT for socket 1 (which was already destroyed), which is now interpreted as WM_RELEASE for socket 2, so socket 2 is destroyed silently. We can reproduce quite reliably with the following setup - create any server (TWSocketServer.Create();), no need to listen, just instantiate - create 5 sockets - connect these sockets to 5 random ip's - wait a few seconds - destroy the 5 sockets - start tcp server - let a client connect. The client will connect, and after approx 15 seconds it will drop, caused by the server dropping the socket due to above mentioned wrong interpreted WM_ASYNCSELECT We have reproduced this with both latest V7 and latest V8. If I'm not mistaken and this is really the case, _and_ it's not possible to stop the WM_ASYNCSELECT from being send to us after the socket is destroyed, this seems to be quite a nasty problem to solve, since TIcsWndHandler cannot distinguish if a received message was meant for socket 1 (which is already destroyed) or for socket 2 (which reuses the particular message id). An option could be to not recycle the message id's as soon as they are available, but do a sort of circular buffer on them, hoping certiain messages will not be received until they are really used again, this doesn't feel like a proper solution though and in that case the problem could pop up again when more sockets are used. Arno, (I think you came up with the message dispatch approach), I'm curious to your thoughts and hope you (or we) can think of a good way to tackle the problem. tia, Merijn Bosma -- 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 -- 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] RES: issues with wndcontrol's message dispatch mechanism
Hi Eric and Arno, Thanks for the quick responses, I hadn't read your other thread yet Eric, but it most certainly is the same issue. I'll try your solution asap and it sounds like the best way to solve this. Will get back on this thread when I know if this helped! Merijn On 31-5-2013 23:32, Eric Fleming Bonilha wrote: Merijin, Apparently you have the very same problem as I do... Try this fix to ICS library and see if the problem still persists (These changes fixed my issue): Inside routine "procedure TCustomWSocket.InternalClose(bShut : Boolean; Error: Word)" I have added the following line: WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); Just after if FState = wsClosed then Exit; In my findings, even after closing the socket, winsock still sends messages to the registered handle (Registered by ASyncSelect), so, here I´m telling winsock to unregister all messages (As soon as socket is closed) The source should be like: if FState = wsClosed then Exit; WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); This is from TCustomWSocket.InternalClose Try adding this line and see if the problem persists (Just for testing), if it fixes it will give more hints for Arno and François, because that was how I fixed my issue (Check on the newsgroup my message entitled: "Shared handles problem". My issue is even worse because I use ICS shared handle system everywhere that I need messaging, because ICS shared handle approach uses way less system resources! Best Regards Eric -Mensagem original- De: TWSocket [mailto:twsocket-boun...@lists.elists.org] Em nome de Merijn Bosma Enviada em: sexta-feira, 31 de maio de 2013 12:46 Para: twsoc...@elists.org Assunto: [twsocket] issues with wndcontrol's message dispatch mechanism Hi all, I think I've encountered an issue in the message dispatch system which is used by wndcontrol. What I'm doing is creating and destroying some sockets: - socket 1 registers message 1043 as FMsg_WM_ASYNCSELECT (OverbyteICSWSocket:5696). - this socket is free'd - we start a server - a client connects, so a new socket is instantiated (socket 2), which registers it's FMsgRelease message (OverbyteICSWndControl:562), and also gets 1043 for that message - now it seems we get a WM_ASYNCSELECT for socket 1 (which was already destroyed), which is now interpreted as WM_RELEASE for socket 2, so socket 2 is destroyed silently. We can reproduce quite reliably with the following setup - create any server (TWSocketServer.Create();), no need to listen, just instantiate - create 5 sockets - connect these sockets to 5 random ip's - wait a few seconds - destroy the 5 sockets - start tcp server - let a client connect. The client will connect, and after approx 15 seconds it will drop, caused by the server dropping the socket due to above mentioned wrong interpreted WM_ASYNCSELECT We have reproduced this with both latest V7 and latest V8. If I'm not mistaken and this is really the case, _and_ it's not possible to stop the WM_ASYNCSELECT from being send to us after the socket is destroyed, this seems to be quite a nasty problem to solve, since TIcsWndHandler cannot distinguish if a received message was meant for socket 1 (which is already destroyed) or for socket 2 (which reuses the particular message id). An option could be to not recycle the message id's as soon as they are available, but do a sort of circular buffer on them, hoping certiain messages will not be received until they are really used again, this doesn't feel like a proper solution though and in that case the problem could pop up again when more sockets are used. Arno, (I think you came up with the message dispatch approach), I'm curious to your thoughts and hope you (or we) can think of a good way to tackle the problem. tia, Merijn Bosma -- 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 -- 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
[twsocket] RES: issues with wndcontrol's message dispatch mechanism
Merijin, Apparently you have the very same problem as I do... Try this fix to ICS library and see if the problem still persists (These changes fixed my issue): Inside routine "procedure TCustomWSocket.InternalClose(bShut : Boolean; Error: Word)" I have added the following line: WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); Just after if FState = wsClosed then Exit; In my findings, even after closing the socket, winsock still sends messages to the registered handle (Registered by ASyncSelect), so, here I´m telling winsock to unregister all messages (As soon as socket is closed) The source should be like: if FState = wsClosed then Exit; WSocket_Synchronized_WSAASyncSelect(FHSocket, Handle, 0, 0); This is from TCustomWSocket.InternalClose Try adding this line and see if the problem persists (Just for testing), if it fixes it will give more hints for Arno and François, because that was how I fixed my issue (Check on the newsgroup my message entitled: "Shared handles problem". My issue is even worse because I use ICS shared handle system everywhere that I need messaging, because ICS shared handle approach uses way less system resources! Best Regards Eric -Mensagem original- De: TWSocket [mailto:twsocket-boun...@lists.elists.org] Em nome de Merijn Bosma Enviada em: sexta-feira, 31 de maio de 2013 12:46 Para: twsoc...@elists.org Assunto: [twsocket] issues with wndcontrol's message dispatch mechanism Hi all, I think I've encountered an issue in the message dispatch system which is used by wndcontrol. What I'm doing is creating and destroying some sockets: - socket 1 registers message 1043 as FMsg_WM_ASYNCSELECT (OverbyteICSWSocket:5696). - this socket is free'd - we start a server - a client connects, so a new socket is instantiated (socket 2), which registers it's FMsgRelease message (OverbyteICSWndControl:562), and also gets 1043 for that message - now it seems we get a WM_ASYNCSELECT for socket 1 (which was already destroyed), which is now interpreted as WM_RELEASE for socket 2, so socket 2 is destroyed silently. We can reproduce quite reliably with the following setup - create any server (TWSocketServer.Create();), no need to listen, just instantiate - create 5 sockets - connect these sockets to 5 random ip's - wait a few seconds - destroy the 5 sockets - start tcp server - let a client connect. The client will connect, and after approx 15 seconds it will drop, caused by the server dropping the socket due to above mentioned wrong interpreted WM_ASYNCSELECT We have reproduced this with both latest V7 and latest V8. If I'm not mistaken and this is really the case, _and_ it's not possible to stop the WM_ASYNCSELECT from being send to us after the socket is destroyed, this seems to be quite a nasty problem to solve, since TIcsWndHandler cannot distinguish if a received message was meant for socket 1 (which is already destroyed) or for socket 2 (which reuses the particular message id). An option could be to not recycle the message id's as soon as they are available, but do a sort of circular buffer on them, hoping certiain messages will not be received until they are really used again, this doesn't feel like a proper solution though and in that case the problem could pop up again when more sockets are used. Arno, (I think you came up with the message dispatch approach), I'm curious to your thoughts and hope you (or we) can think of a good way to tackle the problem. tia, Merijn Bosma -- 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 -- 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
