waiting on events for socket activity
-
Windows 7, visual studio 2008, C++ Reference: http://www.winsocketdotnetworkprogramming.com/[^] I just discovered this site and now I think that a TPC/IP class can be created that does not use messages and needs no window. Async socket operation can generate events such as FD_SEND (it is okay to send now) and FD_READ (Windows has received some data for the application to capture.) I can also declare and generate my own events. If I put the TCP/IP code in a class, make it a thread and crank it up, I can also pass it handles of events I have created along with the some other goodies in a single structure (such as the address of the buffer where the main app puts data to send out). One of the key calls is WSAWaitForMultipleEvents() function where one of the arguments is an array of event handles. I did not recognize anything that places a limit on the type or category of events that it can received. (Is there any such thing as that? I know that Windows reserves event numbers below a certain value.) Rather than a long post I will hope that the knowledgeable reader will recognize the intent and comment on the feasibility and/or loop holes and gotchas that await.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
-
Windows 7, visual studio 2008, C++ Reference: http://www.winsocketdotnetworkprogramming.com/[^] I just discovered this site and now I think that a TPC/IP class can be created that does not use messages and needs no window. Async socket operation can generate events such as FD_SEND (it is okay to send now) and FD_READ (Windows has received some data for the application to capture.) I can also declare and generate my own events. If I put the TCP/IP code in a class, make it a thread and crank it up, I can also pass it handles of events I have created along with the some other goodies in a single structure (such as the address of the buffer where the main app puts data to send out). One of the key calls is WSAWaitForMultipleEvents() function where one of the arguments is an array of event handles. I did not recognize anything that places a limit on the type or category of events that it can received. (Is there any such thing as that? I know that Windows reserves event numbers below a certain value.) Rather than a long post I will hope that the knowledgeable reader will recognize the intent and comment on the feasibility and/or loop holes and gotchas that await.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
This is perfectly feasible, and there's a good example at the WSAWaitForMultipleEvents[^] help page.
-
This is perfectly feasible, and there's a good example at the WSAWaitForMultipleEvents[^] help page.
OK, I am going that way, mostly, I think. After a bunch of searching I have found/concluded that the several version of WaitForMultiple[Event,Object] all wind up using this:
DWORD WINAPI WaitForMultipleObjects(
_In_ DWORD nCount,
_In_ const HANDLE *lpHandles,
_In_ BOOL bWaitAll,
_In_ DWORD dwMilliseconds );from this page: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx[^] If the other versions, specifically the WSA versions are wrappers, and my primary goal is speed (i.e. minimum overhead), then it seems I should use the most fundamental call. This looks just about as simple as it could be. I am coding up a simple bare-bones thread to test it out. I think I have that ready will start of the main app that will create the events that the thread waits on. Do you foresee any problems with this? Edit: My searches have not produced a clear distinction between wait for EVENT and wait for OBJECT. They appear to be synonyms. Is that correct?
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
-
OK, I am going that way, mostly, I think. After a bunch of searching I have found/concluded that the several version of WaitForMultiple[Event,Object] all wind up using this:
DWORD WINAPI WaitForMultipleObjects(
_In_ DWORD nCount,
_In_ const HANDLE *lpHandles,
_In_ BOOL bWaitAll,
_In_ DWORD dwMilliseconds );from this page: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025(v=vs.85).aspx[^] If the other versions, specifically the WSA versions are wrappers, and my primary goal is speed (i.e. minimum overhead), then it seems I should use the most fundamental call. This looks just about as simple as it could be. I am coding up a simple bare-bones thread to test it out. I think I have that ready will start of the main app that will create the events that the thread waits on. Do you foresee any problems with this? Edit: My searches have not produced a clear distinction between wait for EVENT and wait for OBJECT. They appear to be synonyms. Is that correct?
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
You'll need to implement a mechanism to shutdown and close the connected sockets if the client closes the connection (I used a WaitForSingleObject in the listening socket thread, with timeout 0 on each of the associated thread handles in turn, to see if it's still running, but it can be done in many other ways). The WSA versions are wrappers around the WaitForSingleObject and WaitForMultipleObject, yes. EVENT and OBJECT and HANDLE are effectively all the same thing - they are numerical identifiers that the system uses to look up internal things. In most cases . This means that you can wait on a thread handle (that identifier will be signaled when the thread terminates) for instance. There's a list of the things that can be waited on in the documentation. Best of luck!
-
You'll need to implement a mechanism to shutdown and close the connected sockets if the client closes the connection (I used a WaitForSingleObject in the listening socket thread, with timeout 0 on each of the associated thread handles in turn, to see if it's still running, but it can be done in many other ways). The WSA versions are wrappers around the WaitForSingleObject and WaitForMultipleObject, yes. EVENT and OBJECT and HANDLE are effectively all the same thing - they are numerical identifiers that the system uses to look up internal things. In most cases . This means that you can wait on a thread handle (that identifier will be signaled when the thread terminates) for instance. There's a list of the things that can be waited on in the documentation. Best of luck!
Very Cool. That helps. I shall sally forth into this new arena. Thank you for taking the time to reply.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/