Async Socket
-
Hi, I created a DLL that exports an API for a GUI to use. The GUI call the API and when the function returns, it expects to have some value set in the memory sent to the API, so far so good. The DLL itself implements the API by sending some information over CAsyncSocket. Here is my problem, When I send the data from the DLL to the client, I basically need to block until the client returns my packet back. I do that using a HANDLE set up as an event. When the client would return my call the OnReceive of the socket would get called and then I would set the event. However..... It seems like the blocking (WaitForSingleObject (event, INFINITE)) seems to prevent the listening socket from receiving the reply. Once the blocking is commented out, I get the reply from the client. The problem is that if I remove the blocking my API returns right away and the the GUI has nothing in the buffer :) I know this can be solved with some threading and callbacks and so on. BUT... the listen socket should be a thread of it's own and not be affected by the infinite wait of WaitForSingleObject . what am I missing ?
-
Hi, I created a DLL that exports an API for a GUI to use. The GUI call the API and when the function returns, it expects to have some value set in the memory sent to the API, so far so good. The DLL itself implements the API by sending some information over CAsyncSocket. Here is my problem, When I send the data from the DLL to the client, I basically need to block until the client returns my packet back. I do that using a HANDLE set up as an event. When the client would return my call the OnReceive of the socket would get called and then I would set the event. However..... It seems like the blocking (WaitForSingleObject (event, INFINITE)) seems to prevent the listening socket from receiving the reply. Once the blocking is commented out, I get the reply from the client. The problem is that if I remove the blocking my API returns right away and the the GUI has nothing in the buffer :) I know this can be solved with some threading and callbacks and so on. BUT... the listen socket should be a thread of it's own and not be affected by the infinite wait of WaitForSingleObject . what am I missing ?
Shay Harel wrote:
what am I missing ?
Almost everything. Your most direct solution would be to use blocking socket calls. Then later should you choose to migrate to a multi-threading solution to keep the UI responsive during socket I/O, I strongly suggest you do a lot of studying and research projects for multi-threading. You are a long way from grasping these concepts well enough to use it in a production application. I recommend Jeffery Richter and his Advanced Windows book for a study resource on threading.
led mike
-
Shay Harel wrote:
what am I missing ?
Almost everything. Your most direct solution would be to use blocking socket calls. Then later should you choose to migrate to a multi-threading solution to keep the UI responsive during socket I/O, I strongly suggest you do a lot of studying and research projects for multi-threading. You are a long way from grasping these concepts well enough to use it in a production application. I recommend Jeffery Richter and his Advanced Windows book for a study resource on threading.
led mike
Wow, All I asked for was a technical solution :) I have done many multithreading in my life, don't loose sleep over it. I was under the impression the listening socket would not be affected from the blocking, that's all. As for the expected blocking of the GUI, I am aware of that, but my traffic is always quick enough for the client to respond quick enough not to notiec the GUI bloking. Also, this is just a prototype at this stage so I don't mind the GUI blokc. In the future, the code that would use the DLL would have a thread of it's own. But if the listening socket would be blocked by this thread I am at the same state. Sync sockets should seems like the only solution but I wanted to avoid it...
-
Wow, All I asked for was a technical solution :) I have done many multithreading in my life, don't loose sleep over it. I was under the impression the listening socket would not be affected from the blocking, that's all. As for the expected blocking of the GUI, I am aware of that, but my traffic is always quick enough for the client to respond quick enough not to notiec the GUI bloking. Also, this is just a prototype at this stage so I don't mind the GUI blokc. In the future, the code that would use the DLL would have a thread of it's own. But if the listening socket would be blocked by this thread I am at the same state. Sync sockets should seems like the only solution but I wanted to avoid it...
-
Hi, I created a DLL that exports an API for a GUI to use. The GUI call the API and when the function returns, it expects to have some value set in the memory sent to the API, so far so good. The DLL itself implements the API by sending some information over CAsyncSocket. Here is my problem, When I send the data from the DLL to the client, I basically need to block until the client returns my packet back. I do that using a HANDLE set up as an event. When the client would return my call the OnReceive of the socket would get called and then I would set the event. However..... It seems like the blocking (WaitForSingleObject (event, INFINITE)) seems to prevent the listening socket from receiving the reply. Once the blocking is commented out, I get the reply from the client. The problem is that if I remove the blocking my API returns right away and the the GUI has nothing in the buffer :) I know this can be solved with some threading and callbacks and so on. BUT... the listen socket should be a thread of it's own and not be affected by the infinite wait of WaitForSingleObject . what am I missing ?
The problem is you're using CAsyncSocket, which by default needs the message pump working to dispatch asynchronous socket notifications. I would recommend (for your prototype which doesn't use multiple threads)) using sockets directly and using WSAEventSelect() so you can get notifications through an event instead of a window message. Either that, or you have to modify the way you wait. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
-
Hi, I created a DLL that exports an API for a GUI to use. The GUI call the API and when the function returns, it expects to have some value set in the memory sent to the API, so far so good. The DLL itself implements the API by sending some information over CAsyncSocket. Here is my problem, When I send the data from the DLL to the client, I basically need to block until the client returns my packet back. I do that using a HANDLE set up as an event. When the client would return my call the OnReceive of the socket would get called and then I would set the event. However..... It seems like the blocking (WaitForSingleObject (event, INFINITE)) seems to prevent the listening socket from receiving the reply. Once the blocking is commented out, I get the reply from the client. The problem is that if I remove the blocking my API returns right away and the the GUI has nothing in the buffer :) I know this can be solved with some threading and callbacks and so on. BUT... the listen socket should be a thread of it's own and not be affected by the infinite wait of WaitForSingleObject . what am I missing ?
Hi, it looks like you want to turn an asynchronous process into a synchronous process. I wonder why you decided to use CAsyncSocket in the beginning but I could suggest two designs: If you can influence the API then I would change it, instead of calling blocking the API call could accept a window message (or another type of notification) and when the request has completed it will signal that the data is available. If you can't change the API or it would be too costly then there is my sugestion number two which is to wrap this mechanism internally into a worker thread... or simply to implement it with blocking sockets. :) Since you mentioned your application is a GUI and I assume it is event driven, perhaps the first alternative is the best. Hope it helps! Moak
-
Hi, I created a DLL that exports an API for a GUI to use. The GUI call the API and when the function returns, it expects to have some value set in the memory sent to the API, so far so good. The DLL itself implements the API by sending some information over CAsyncSocket. Here is my problem, When I send the data from the DLL to the client, I basically need to block until the client returns my packet back. I do that using a HANDLE set up as an event. When the client would return my call the OnReceive of the socket would get called and then I would set the event. However..... It seems like the blocking (WaitForSingleObject (event, INFINITE)) seems to prevent the listening socket from receiving the reply. Once the blocking is commented out, I get the reply from the client. The problem is that if I remove the blocking my API returns right away and the the GUI has nothing in the buffer :) I know this can be solved with some threading and callbacks and so on. BUT... the listen socket should be a thread of it's own and not be affected by the infinite wait of WaitForSingleObject . what am I missing ?
As Mark said, blocking the message pump seems to be problem. Try using
MsgWaitForMultipleObjectsinstead ofWaitForMultipleObjects.nave [OpenedFileFinder]
-
The problem is you're using CAsyncSocket, which by default needs the message pump working to dispatch asynchronous socket notifications. I would recommend (for your prototype which doesn't use multiple threads)) using sockets directly and using WSAEventSelect() so you can get notifications through an event instead of a window message. Either that, or you have to modify the way you wait. Mark
Mark Salsbery Microsoft MVP - Visual C++ :java:
"The problem is you're using CAsyncSocket, which by default needs the message pump working to dispatch asynchronous socket notifications." This is exactly the root cause of the problem I guess. I did not know the Async socket rely on the message pump, I was sure it's a thread of it's own. Looks like I'll have some threads going... Thanks !
-
"The problem is you're using CAsyncSocket, which by default needs the message pump working to dispatch asynchronous socket notifications." This is exactly the root cause of the problem I guess. I did not know the Async socket rely on the message pump, I was sure it's a thread of it's own. Looks like I'll have some threads going... Thanks !
Shay Harel wrote:
I did not know the Async socket rely on the message pump
It does by default. You can, however, override everything you need to make it use events instead of window messages. You don't get the virtual OnConnect(), OnReceive(), etc calls, however, since you'd have to provide your own thread. At some point it ends up being easier to use Winsock APIs directly IMO :) Mark
Mark Salsbery Microsoft MVP - Visual C++ :java: