Re: Please describe overlapped operations - ATL / WTL / STL Discussion Boards

Not sure what you mean by 20 characters needing to be retained. No need to walk the string one-by-one...

wcsncpy_s(destination, 60, source, 20);

Will take the first 20 characters of source and copy them to destination. But if you must walk it one-by-one are several ways...

for(i=0; i < 60; i++)
{
    WCHAR *current = &source + (sizeof(WCHAR) * i); // one way
    destination[i] = *current;

    WCHAR current = source[i]; // another way
    destination[i] = current;
}

I'd never declare a variable in a loop like that, so it's just for illustration. Anyway, you can do whatever logic you want to skip the first 20 chars in destination at that point.

Jeremy Falcon

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

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/

modified 20-Jan-14 12:17pm.

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/

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

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 basically equivalent from some point. Note that the implementation of an async operation is often a background thread, for example your own thread or an OS thread or a set of these threads but the implementation of an async operation can also be a hardware implementation (for example a DMA transfer whose completion may be polled or it may be signaled by the hardware for example in the for of an interrupt) or an arbitrary mixture of all the previously listed options. The async operation is async if we are taking a look at it from the perspective of the thread that starts the operation but it isn't async if we are looking at it from the perspective of the thread or hardware that actually performs the operation.

So if we take a look at the previous explanation you see that overlapped operations are indeed async operations and besides this overlapped IO is the most effective IO mechanism of windows. You can start it and you can poll for the result or you can later blocking-wait for the result. From the perspective of the operation-starter thread a blocking call can also be treated as a special case of an async (maybe an overlapped) operation: A blocking call starts the operation and immediately starts blocking-wait for its completion.

If you want to exploit the full power of windows then you wait for the end of many overlapped operations with a single IO completion port (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198%28v=vs.85%29.aspx[^]). The idea behinde IO completion ports is simple: You create an IO completion port and you register many overlapped operations to this "IO completion port", when you start an overlapped IO operation you just register it to this port. When windows finishes with one of the registered overlapped operations then it places a message into the queue of the IO completion port about the result. Besides this what you have to do is creating a thread pool and all threads should blocking-wait on the IO completion port handle for a new incoming message. When one message arrives then a thread grabs it and performs the necessary work (for example if socket/file/pipe/... write has finished then it checks whether you still have writeable data for that handle and if so then it starts another overlapped operation for that handle). Note that the linux epoll api and the bsd kqueue api also works with the same registration and operation-finished-queue concept but the windows api is much more complex because it is mixed with the overlapped api that is terribly easy to put wrong and buggy.

Note that you can use a single IO completion port and a generalized thread pool to perform overlapped read/write operations on many different kind of handles (files/sockets/pipes), this is why WriteFile/ReadFile works also on socket handles just like WSASend/Recv. Besides this no other socket handling api comes close to the scalability of IO completion ports when it comes to handling IO on a lot of handles.

SO_RCVBUF and SO_SNDBUF to zero? Lets say you are writing a file with overlapped IO. Then the overlapped operation basically writes the buffer you supplied into the disk storage occupied by the file or if caching is enabled windows copies the contents of your buffer into the IO cache and then it marks your write operation as finished immediately even before writing the contents to the disk. The same may happen with a blocking file write operation if windows has a lot of disk cache space. You can think of the socket SO_SNDBUF in a similar way as about the IO cache of disk files. Even a blocking send() call can return immediately if you supply a buffer whose size is less than or equal to the size of the free space of the SO_SNDBUF of the socket handle, in this case windows just appends your buffer contents to the end of the SO_SNDBUF of the socket handle and returns immediately. This is true for both blocking and overlapped operations, you are just writing this buffer and not actually sending data with your blocking send() call or your overlapped write operation. Then in the background the network stack performs the actual transfer over the wire in the background...

If you set SO_RCVBUF and SO_SNDBUF to zero then your socket handle basically doesn't have this caching area and in this case windows sends the data over the wire directly from your buffer and your overlapped operation finishes only when all data has been sent. In case of overlapped operations this isn't a big problem because you probably don't care whether an overlapped operation is in progress because it would block on a full SO_SNDBUF or on actually sending the data through the wire. SO_SNDBUF is an extreme optimization that isn't even available on other platforms and if you set the SO_SNDBUF to zero then you have more control over the buffer sizes from which the network stack is working and this can be used for both good and bad, be careful with it.

There is no golden rule to write the "best" networking engine. What is "best" and "optimal" is dependent on the particular problem to be solved and on the target hardware. You can never write something that is the "best" solution when it comes to networking.

Sorry, it seems I sent my previous post as a reply to the wrong place. Smile | :)

I wondered why you were telling me.

Hello,
I've been working on an application that would allow a program to communicate over lan, using UDP and TCP. Here's a general flow of what I was thinking:

1. Send UDP Broadcast to subnet on a port that all applications will listen on (i.e. all listening on 59200)

2. The application running on other nodes, receive the broadcast and echo a UDP broadcast back.

3. Using the information obtained from the UDP echo, a TCP connection is opened and data is exchanged.

4. Connections remain open until an error occurs (this was a requirement of design.)

Is such a design feasible, and if so how would it best be accomplished? I've been reading up on Winsock and MSDN articles on this, and have created client/server applications but have not found very much that would outline a peer-to-peer application like this. I would appreciate any guidance, or direction a resource that could further my understanding on this topic.

Well, first of all, what are you trying to accomplish and what are your requirements?

If your application is supposed to work over internet, UDP broadcast is usually not a good option because most routers will not forward broadcasts (can you imagine how much traffic would be on the internet if every broadcast message was forwarded?). With your scenario, I'm not even quite clear on why you have the UDP piece at all? Why not just have a TCP/IP connection on a known port?

Peer-to-peer simply means there isn't a man in the middle (or computer/server to be precise), that's just about every socket protocol unless you're using some sort of service in the middle.

The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN.

The issue faced is that a specific address is needed for the TCP/IP connection, that will be the piece exchanged via UDP.

I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?

SD1208 wrote:
The goal is peer discovery and exchange of configuration information between the hosts, between systems on a subnet-not over the internet but a LAN.

You mean so that they know about each other without having a set server and client? I still don't follow what you're trying to achieve. Why don't you describe functionally what you're trying to achieve instead.

SD1208 wrote:
I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?

Multiple threads would probably be ideal if a program is expected to work as both a server and client.

If you are doing this on a company LAN, you should give your IT department a heads up. It is possible they have alerts set up on their monitoring software to notify them whenever there is UDP Broadcast activity on their network.

Soren Madsen

"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty

Quote:
I understand that peer-to-peer concept of not having a server, I guess where I'm kind of stuck is how to manage each application having essentially being a client and server. Would each aspect being handled in a separate thread by the ideal method?

Maybe I am miss-understanding, but I suspect that SD1208 is not understanding the phrases client and server. Does this help any:

Any application on any computer can take the server role or client role. Server in TCP/IP does not refer to a "SERVER" computer that is running a "SERVER" operating system.

The server application must start first. It opens a port and listens for any client application. The client connects to a port already opened by a server. Then the two applications can chat.

Thanks for your time
If you work with telemetry, please check this bulletin board: http://www.bkelly.ws/irig_106/

error LNK1104: cannot open file 'uafxcwd.lib'

I have installed vs 2012 express edition.
To use mfc i have installed wdk7.1 and set path for mfc libraries and includes directories.

after that i write a code:

#include<afxwin.h>;
struct CSimpleApp : public CWinApp
{
BOOL InitInstance() { return TRUE; }
};
CSimpleApp theApp;

But the above mentioned 1 link error lnk1104 cannot open file 'uafxcwd.lib' is coming.

I tried static and shared mfc and also trid with different character set.

Anybody can solve pls?

Express edition products do not include MFC, and as far as I am aware the Windows Driver Kit does not either. A quick search of the various directories will tell whether this lib file exists or not.

Veni, vidi, abiit domum

Dear Richard,

I want to use express version with wdk for mfc programming. can you suggest me any way?

Regards,
Prasun

WDK is the Windows Driver Kit, it has nothing to do with MFC.

Veni, vidi, abiit domum

If you want to use MFC, you usually have to pay for VisualStudio. I usually use the "Professional" version, it should have everything you need. Only thing that's useful that any of the other versions have that would be nice is the remote debugger, you have to get one of the other versions for that (for debugging remotely on embedded systems and/or just remote systems).

It is expensive, but if you're a professional, your company should probably cover the cost. If you're a student, I believe you can get student pricing (may depend on university). If you're neither, you may have to consider using an open source alternative. There's quite a few alternative frameworks out there (wxWidgets, Qt, etc.).

I have a problem where i have two dlls with same name.
does changing CLSIDs of any one of it is advisable ? or any other alternate??

jigar

Obviously they would need different CLSIDs as there would be no way of distinguishing between them otherwise. The question remains: why?

Veni, vidi, abiit domum

I have a situation where there are two applications A & B,using C.dll ,problem is that for A, development is frozen,while for B there is a huge overhaul expected in C.dll which will then break A,So either i need to create a new dll for B and rewrite same code of C.dll and do modification ,or i can just copy C.dll project and change its ProgGUID,CLSIDs and do modifications. indeed not a neat solution

jigar

The obvious answer is to create a copy of C.DLL source, probably by starting a new branch in your source control system. You can give it a different name and CLSID and use that for the development, while leaving the operational version intact. This is fairly standard procedure for any project.

Veni, vidi, abiit domum