Strange socket problem
-
Hi, I have a very strange problem concerning the sockets I use in my applications. I have written a Server application which accepts client connections. Therefore I have created a listen socket. In the OnAccept event of that listen socket I accept the incoming connection by creating a new socket and calling its accept member. Nothing strange here and everything works well. I'm also using ado to connect to a SQL database to write log-ins and the like. But in a single customer case the SQL server is placed on a different PC. This normally doesn't give me much trouble, but sometimes under heavy network load the database-connection to this PC is lost. In that case I close the connection and create a new one. To simulate this I have setup a test PC with SQL on and I remove this PC from the network, not my development PC. After the reconnect the PC, the connection is restored and the database can be used again But now for the strange part. In some cases, 1 out of 5-6 test, I can't accept any new clients. Using the netstat command i can see that the port is still open. It even accept new incoming request (upto 5) but I never get in the OnAccept function so I can't accept new Clients. How come that even though the TPC-IP protocol of the machine sees the new incoming request I don't get notified any more. Any help on this matter will be highly appreciated.
codito ergo sum
-
Hi, I have a very strange problem concerning the sockets I use in my applications. I have written a Server application which accepts client connections. Therefore I have created a listen socket. In the OnAccept event of that listen socket I accept the incoming connection by creating a new socket and calling its accept member. Nothing strange here and everything works well. I'm also using ado to connect to a SQL database to write log-ins and the like. But in a single customer case the SQL server is placed on a different PC. This normally doesn't give me much trouble, but sometimes under heavy network load the database-connection to this PC is lost. In that case I close the connection and create a new one. To simulate this I have setup a test PC with SQL on and I remove this PC from the network, not my development PC. After the reconnect the PC, the connection is restored and the database can be used again But now for the strange part. In some cases, 1 out of 5-6 test, I can't accept any new clients. Using the netstat command i can see that the port is still open. It even accept new incoming request (upto 5) but I never get in the OnAccept function so I can't accept new Clients. How come that even though the TPC-IP protocol of the machine sees the new incoming request I don't get notified any more. Any help on this matter will be highly appreciated.
codito ergo sum
BadKarma wrote:
I accept the incoming connection by creating a new socket and calling its accept member......In some cases, 1 out of 5-6 test, I can't accept any new clients
You call
Accept()on the listening socket instance and provides a reference to the new socket as argument, right? If not, that's what you should do. I don't know what happens if you do it the other way around. A listening socket has a queue with pending connection requests. If I remember correctly the size of the queue is configurable by hacking registry values, but I think the default value is 5 and that's what puzzles me since you say that it's 1 out of 5-6 attempts that fails. Are we dealing with multithreading issues here as well?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
BadKarma wrote:
I accept the incoming connection by creating a new socket and calling its accept member......In some cases, 1 out of 5-6 test, I can't accept any new clients
You call
Accept()on the listening socket instance and provides a reference to the new socket as argument, right? If not, that's what you should do. I don't know what happens if you do it the other way around. A listening socket has a queue with pending connection requests. If I remember correctly the size of the queue is configurable by hacking registry values, but I think the default value is 5 and that's what puzzles me since you say that it's 1 out of 5-6 attempts that fails. Are we dealing with multithreading issues here as well?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownThanks for the response.
Roger Stoltz wrote:
You call Accept() on the listening socket instance and provides a reference to the new socket as argument, right?
Yes, I do it like you mentioned.
CClientSocket* pNewSocket = new CClientSocket(this); if(!pNewSocket) { // // Error trying to create a client socket // WriteError(ecNotEnoughMemory, "cannot_create_new_socket", "AcceptNewClient"); return; } if(m_pListenSocket->Accept(*pNewSocket)) { ... }This code is called when I fall in the OnAccept from the Listen socket. The problem is that i don't fall in the function anymore. But if I check the Socket is still (with other tools) listening and even puts incoming request in the pending queue. And indeed after 5 clients trying to connect (they hang) the sixth client gets a connection refused. Could it be that the message handling pump is 'broken'. And if so can i check for it in order to make a new listensocket? Yes it's a multithreaded application (about 13 threads)
codito ergo sum
-
Thanks for the response.
Roger Stoltz wrote:
You call Accept() on the listening socket instance and provides a reference to the new socket as argument, right?
Yes, I do it like you mentioned.
CClientSocket* pNewSocket = new CClientSocket(this); if(!pNewSocket) { // // Error trying to create a client socket // WriteError(ecNotEnoughMemory, "cannot_create_new_socket", "AcceptNewClient"); return; } if(m_pListenSocket->Accept(*pNewSocket)) { ... }This code is called when I fall in the OnAccept from the Listen socket. The problem is that i don't fall in the function anymore. But if I check the Socket is still (with other tools) listening and even puts incoming request in the pending queue. And indeed after 5 clients trying to connect (they hang) the sixth client gets a connection refused. Could it be that the message handling pump is 'broken'. And if so can i check for it in order to make a new listensocket? Yes it's a multithreaded application (about 13 threads)
codito ergo sum
BadKarma wrote:
Roger Stoltz wrote:
You call Accept() on the listening socket instance and provides a reference to the new socket as argument, right?
Yes, I do it like you mentioned.
Ok. Just wanted to make sure since it could be interpreted the other way around.
BadKarma wrote:
Could it be that the message handling pump is 'broken'.
What do you mean by "broken"? Every thread that creates a socket has to be a UI-thread, i.e. it has got to have a message pump. This means you must have a
CWinThreadderivative where the socket is a member of the class. If you create sockets in worker threads that don't have message pumps, Chaos and Mayhem will follow. ;)
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
BadKarma wrote:
Roger Stoltz wrote:
You call Accept() on the listening socket instance and provides a reference to the new socket as argument, right?
Yes, I do it like you mentioned.
Ok. Just wanted to make sure since it could be interpreted the other way around.
BadKarma wrote:
Could it be that the message handling pump is 'broken'.
What do you mean by "broken"? Every thread that creates a socket has to be a UI-thread, i.e. it has got to have a message pump. This means you must have a
CWinThreadderivative where the socket is a member of the class. If you create sockets in worker threads that don't have message pumps, Chaos and Mayhem will follow. ;)
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknownRoger Stoltz wrote:
What do you mean by "broken"? Every thread that creates a socket has to be a UI-thread, i.e. it has got to have a message pump. This means you must have a CWinThread derivative where the socket is a member of the class. If you create sockets in worker threads that don't have message pumps, Chaos and Mayhem will follow.
Yep I have a CWinThread derived class CConnectionManager which creates a CListenSocket object. CListenSocket has override the OnAccept function to accept an incoming Client. But doesn't the listen socket creates a dummy window so it can receive the message sent. Otherwise how would one make a difference between message for the thread and those for the listen socket. I have checked and the thread message pump is still working. So maybe the Handle to identify the listen socket has gotten invalid. Is there a way to check if the listen socket can still receive mesagges. I have another CWinthread derivative that also manages a Listen socken on another port and this keeps on working, sometimes :sigh:. Sometimes all listen sockets keep on working, other times its only the Client Listen socket which fails, yet another time its the ohter listen socket which fails. And if i'm very lucky (NOT) both the listen sockets are being kidnapped by somekind of Gremlin. AArrgh !! :mad: I'm getting crazy with this issue. I mean the network of another pc fails. Resulting in a database connection loss. But my listen socket go down :omg:
codito ergo sum
-
Roger Stoltz wrote:
What do you mean by "broken"? Every thread that creates a socket has to be a UI-thread, i.e. it has got to have a message pump. This means you must have a CWinThread derivative where the socket is a member of the class. If you create sockets in worker threads that don't have message pumps, Chaos and Mayhem will follow.
Yep I have a CWinThread derived class CConnectionManager which creates a CListenSocket object. CListenSocket has override the OnAccept function to accept an incoming Client. But doesn't the listen socket creates a dummy window so it can receive the message sent. Otherwise how would one make a difference between message for the thread and those for the listen socket. I have checked and the thread message pump is still working. So maybe the Handle to identify the listen socket has gotten invalid. Is there a way to check if the listen socket can still receive mesagges. I have another CWinthread derivative that also manages a Listen socken on another port and this keeps on working, sometimes :sigh:. Sometimes all listen sockets keep on working, other times its only the Client Listen socket which fails, yet another time its the ohter listen socket which fails. And if i'm very lucky (NOT) both the listen sockets are being kidnapped by somekind of Gremlin. AArrgh !! :mad: I'm getting crazy with this issue. I mean the network of another pc fails. Resulting in a database connection loss. But my listen socket go down :omg:
codito ergo sum
Hmm, at least you haven't made the most common mistakes. ;) More seriously though... When I find myself in situations like yours, I try to revert to basics. What happens if you create a mockup with only one thread...? See if you find anything in this article[^] that might help you.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown -
Roger Stoltz wrote:
What do you mean by "broken"? Every thread that creates a socket has to be a UI-thread, i.e. it has got to have a message pump. This means you must have a CWinThread derivative where the socket is a member of the class. If you create sockets in worker threads that don't have message pumps, Chaos and Mayhem will follow.
Yep I have a CWinThread derived class CConnectionManager which creates a CListenSocket object. CListenSocket has override the OnAccept function to accept an incoming Client. But doesn't the listen socket creates a dummy window so it can receive the message sent. Otherwise how would one make a difference between message for the thread and those for the listen socket. I have checked and the thread message pump is still working. So maybe the Handle to identify the listen socket has gotten invalid. Is there a way to check if the listen socket can still receive mesagges. I have another CWinthread derivative that also manages a Listen socken on another port and this keeps on working, sometimes :sigh:. Sometimes all listen sockets keep on working, other times its only the Client Listen socket which fails, yet another time its the ohter listen socket which fails. And if i'm very lucky (NOT) both the listen sockets are being kidnapped by somekind of Gremlin. AArrgh !! :mad: I'm getting crazy with this issue. I mean the network of another pc fails. Resulting in a database connection loss. But my listen socket go down :omg:
codito ergo sum