Please describe overlapped operations
-
Windows 7, Visual Studio 2008,C++, TCP/IP Please describe what “overlapped” means in terms of Windows sockets I/O. I found some pages but they describe how to use it rather than what it really is. Full Motivation My application will perform high data rate TCP/IP output, and it will be rather bursty. It will call the send function several times in rapid function. Will the use of the overlapped mode provide an advantage? My presumption is that the app can initiate TCP/IP output on multiple buffers and each becomes an almost completely separate I/O function. More Info The app will send out what I call messages. Each message can have its own unique buffer containing all the packet overhead and data. Message A (of A through Z) will very seldom be sent twice in a single burst. I can arrange for an array or structure of messages A through Z keeping them completely separate from each other. Using that, I am thinking that the overlapped option will be useful. From this Microsoft web page: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740087(v=vs.85).aspx My reading of the last four or so paragraphs, indicates that overlapped will facilitate the fast and bursty I/O needed. Further reading leads me to tentatively conclude that the app can call WSAGetOverlappedResult passing in the address of each specific buffer (along with other goodies) and the return value will indicate if the I/O has completed to the point that the app can re-write that buffer without fear of any data being lost. Bonus Question In the web page for WSAGetOverlappedResult, the minimum supported client is Windows 2000 Professional [desktop apps only]. Does that include Windows XP Pro and Windows 7? I see there is more to this and am studying the help page on WSAGetOverlappedResult and WSAOVERLAPPED structure. (Hmmm, event handle. That looks helpful, as in WaitForMultipleObjects()) Conclusion I don’t ask for all the details, just a basic explanation and comment as to if I am going down a viable and/or a good path.
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++, TCP/IP Please describe what “overlapped” means in terms of Windows sockets I/O. I found some pages but they describe how to use it rather than what it really is. Full Motivation My application will perform high data rate TCP/IP output, and it will be rather bursty. It will call the send function several times in rapid function. Will the use of the overlapped mode provide an advantage? My presumption is that the app can initiate TCP/IP output on multiple buffers and each becomes an almost completely separate I/O function. More Info The app will send out what I call messages. Each message can have its own unique buffer containing all the packet overhead and data. Message A (of A through Z) will very seldom be sent twice in a single burst. I can arrange for an array or structure of messages A through Z keeping them completely separate from each other. Using that, I am thinking that the overlapped option will be useful. From this Microsoft web page: http://msdn.microsoft.com/en-us/library/windows/desktop/ms740087(v=vs.85).aspx My reading of the last four or so paragraphs, indicates that overlapped will facilitate the fast and bursty I/O needed. Further reading leads me to tentatively conclude that the app can call WSAGetOverlappedResult passing in the address of each specific buffer (along with other goodies) and the return value will indicate if the I/O has completed to the point that the app can re-write that buffer without fear of any data being lost. Bonus Question In the web page for WSAGetOverlappedResult, the minimum supported client is Windows 2000 Professional [desktop apps only]. Does that include Windows XP Pro and Windows 7? I see there is more to this and am studying the help page on WSAGetOverlappedResult and WSAOVERLAPPED structure. (Hmmm, event handle. That looks helpful, as in WaitForMultipleObjects()) Conclusion I don’t ask for all the details, just a basic explanation and comment as to if I am going down a viable and/or a good path.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
bkelly13 wrote:
Please describe what “overlapped” means in terms of Windows sockets I/O.
It means that the operations will run asynchronously, leaving your application free to do other work. You then need to go back at some other point to check whether the operation has completed, and if so, was it successful.
bkelly13 wrote:
Does that include Windows XP Pro and Windows 7?
Yes, see http://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions[^].
bkelly13 wrote:
if I am going down a viable and/or a good path.
Always a difficult one to answer since it depends on so many factors. It would appear to be a sensible choice, but you would need to run some tests for yourself to be sure.
Veni, vidi, abiit domum
-
bkelly13 wrote:
Please describe what “overlapped” means in terms of Windows sockets I/O.
It means that the operations will run asynchronously, leaving your application free to do other work. You then need to go back at some other point to check whether the operation has completed, and if so, was it successful.
bkelly13 wrote:
Does that include Windows XP Pro and Windows 7?
Yes, see http://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions[^].
bkelly13 wrote:
if I am going down a viable and/or a good path.
Always a difficult one to answer since it depends on so many factors. It would appear to be a sensible choice, but you would need to run some tests for yourself to be sure.
Veni, vidi, abiit domum
Hello Richard, In at least one MSDN help page about socket functions, they write that overlapped is not the same as sync and async. They work together but are not the same. As I interpret the pages: Overlapped means having multiple buffers submitted for I/O at one time. The app can, for example post four sends with four separate addresses (addresses of buffers to send). After the four posts it can be the case that none of them have been signaled as complete. The operating system will then signal each of the four I/Os as being complete some time later. The application must not disturb those buffers until each one has been signaled as complete. As each one is signaled complete, the application can re-use that buffer, but not until then. In the WSASend function argument six is structure WSAOVERLAPPED. We can use WSASend and other TCP/IO functions with async but without overlapped. Or with overlapped. Is my interpretation correct, as far as it goes?
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
-
bkelly13 wrote:
Please describe what “overlapped” means in terms of Windows sockets I/O.
It means that the operations will run asynchronously, leaving your application free to do other work. You then need to go back at some other point to check whether the operation has completed, and if so, was it successful.
bkelly13 wrote:
Does that include Windows XP Pro and Windows 7?
Yes, see http://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions[^].
bkelly13 wrote:
if I am going down a viable and/or a good path.
Always a difficult one to answer since it depends on so many factors. It would appear to be a sensible choice, but you would need to run some tests for yourself to be sure.
Veni, vidi, abiit domum
Hello Richard, In at least one MSDN help page about socket functions, they write that overlapped is not the same as sync and async. They work together but are not the same. As I interpret the pages: Overlapped means having multiple buffers submitted for I/O at one time. The app can, for example post four sends with four separate addresses (addresses of buffers to send). After the four posts it can be the case that none of them have been signaled as complete. The operating system will then signal each of the four I/Os as being complete some time later. The application must not disturb those buffers suntil each one has been signaled as complete. As each one is signaled complete, the application can re-use that buffer, but not until then. In the WSASend function argument six is structure WSAOVERLAPPED. We can use WSASend and other TCP/IO functions with async but without overlapped. Or with overlapped. Is my interpretation correct, as far as it goes?
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
-
Hello Richard, In at least one MSDN help page about socket functions, they write that overlapped is not the same as sync and async. They work together but are not the same. As I interpret the pages: Overlapped means having multiple buffers submitted for I/O at one time. The app can, for example post four sends with four separate addresses (addresses of buffers to send). After the four posts it can be the case that none of them have been signaled as complete. The operating system will then signal each of the four I/Os as being complete some time later. The application must not disturb those buffers until each one has been signaled as complete. As each one is signaled complete, the application can re-use that buffer, but not until then. In the WSASend function argument six is structure WSAOVERLAPPED. We can use WSASend and other TCP/IO functions with async but without overlapped. Or with overlapped. Is my interpretation correct, as far as it goes?
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
-
bkelly13 wrote:
Is my interpretation correct, as far as it goes?
That is my understanding of it. Maybe this whitepaper[^] will help to clarify it.
Veni, vidi, abiit domum
Hello Richard, In that article, the second paragraph in the section titles Overlapped I/O, is a sentence that beings with:
Quote:
If you use the SO_RCVBUF and SO_SNDBUF option to set zero TCP stack receive and send buffer, ....
I think I understand the remainder of the paragraph as saying: We can call the send or receive function telling the OS and the TCP part of the OS, to use the buffer we have supplied as the buffer to output/input the data. That saves the OS/TCP code from performing a copy of the data. This reduces the total number of CPU cycles dedicated to performing my I/O operation. It also means, as I noted earlier, our app cannot touch that buffer until the send/receive is complete. That said, just what does that quoted part of the sentence mean? "... to set zero TCP stack ..." That appears to be just a simple case of not very good choice of words. On the other hand, I may be missing something important.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
-
Hello Richard, In that article, the second paragraph in the section titles Overlapped I/O, is a sentence that beings with:
Quote:
If you use the SO_RCVBUF and SO_SNDBUF option to set zero TCP stack receive and send buffer, ....
I think I understand the remainder of the paragraph as saying: We can call the send or receive function telling the OS and the TCP part of the OS, to use the buffer we have supplied as the buffer to output/input the data. That saves the OS/TCP code from performing a copy of the data. This reduces the total number of CPU cycles dedicated to performing my I/O operation. It also means, as I noted earlier, our app cannot touch that buffer until the send/receive is complete. That said, just what does that quoted part of the sentence mean? "... to set zero TCP stack ..." That appears to be just a simple case of not very good choice of words. On the other hand, I may be missing something important.
Thanks for your time If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig\_106/
Well I didn't write that paper ... However, as I understand it, by using those settings you are allowing the low level data transfer to be done direct to/from your data buffers, rather than using an internal buffer which requires the data to also be copied to/from the application buffers. That is why you must guarantee not to use the buffer until the transfer is signalled complete.
Veni, vidi, abiit domum
-
bkelly13 wrote:
Please describe what “overlapped” means in terms of Windows sockets I/O.
It means that the operations will run asynchronously, leaving your application free to do other work. You then need to go back at some other point to check whether the operation has completed, and if so, was it successful.
bkelly13 wrote:
Does that include Windows XP Pro and Windows 7?
Yes, see http://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions[^].
bkelly13 wrote:
if I am going down a viable and/or a good path.
Always a difficult one to answer since it depends on so many factors. It would appear to be a sensible choice, but you would need to run some tests for yourself to be sure.
Veni, vidi, abiit domum
Overlapped vs Async: I guess you have already programmed multithread apps for windows. Then you have probably met some synchronizations objects like CritcalSection, Mutex, Slim RWLock, ... Do you see, here MS used basically synonyms to differentiate lock types provided by the OS. Generally we could say that all of these are mutexes if we use the word "mutex" out of the context of the windows api documentation but the winapi documents use the word "Mutex" to refer to one of the winapi locks (the one created by CreateMutex) that can have a name and can be shared between processes in return for some performance penalty. After the previous paragraph it will be easier to understand the following: In the socket api docs MS uses the word "async" and "asyncblahblah" to differentiate a set of its socket handling apis from the rest of the apis. Usually with "async" the MS docs refer to the socket handling apis that send you completion callback as a window message (WSAAsyncSelect) but sometimes some docs also use "async" to refer to the bsd compatible select() function call and its more effective windows "equivalent" WSAEventSelect+WSAWaitForMultipleObjects or WSAPoll. But this is true only if we are in the context of the windows api docs and this is quite confusing. If we use async outside the context of the socket winapi docs then we can say that overlapped is also an async operation, the winapi docs just use "async" and "overlapped" to differentiate two different set of apis, its still very confusing as an overlapped operation is also an async operation. I guess this unfortunate naming convention probably comes from the fact that the original "async" api existed earlier than the overlapped stuff. If you search for "asynchronous" you will find a lot of explanations and some of them are so theoretically so abstract that they are totally impossible to practically interpret in my opinion. Here is a very dirty and rough explanation what async means when it comes to programming: An operation is async if it can be started without blocking the starter thread after starting the operation. The thread just starts the operation and later this thread or another one can poll whether the execution has ended or there is another more effective way to detect the operation finish: waiting for it. There is another mechanism to detect the operation finish event: a callback is called by a separate thread when the operation has finished but the pure waiting and the callback can be converted one to the other with user code so they are basic
-
bkelly13 wrote:
Please describe what “overlapped” means in terms of Windows sockets I/O.
It means that the operations will run asynchronously, leaving your application free to do other work. You then need to go back at some other point to check whether the operation has completed, and if so, was it successful.
bkelly13 wrote:
Does that include Windows XP Pro and Windows 7?
Yes, see http://en.wikipedia.org/wiki/Comparison_of_Microsoft_Windows_versions[^].
bkelly13 wrote:
if I am going down a viable and/or a good path.
Always a difficult one to answer since it depends on so many factors. It would appear to be a sensible choice, but you would need to run some tests for yourself to be sure.
Veni, vidi, abiit domum
Sorry, it seems I sent my previous post as a reply to the wrong place. :-)
-
Sorry, it seems I sent my previous post as a reply to the wrong place. :-)