Streamed data via pipes

[alxx]

Hello everyone.

A Win32 application (the "server") is sending a continuous stream of data over a named pipe. GetNamedPipeInfo() tells me that input and output buffer sizes are automatically allocated as needed. The pipe is operating in byte mode (although it is sending data units that are bigger than 1 byte (doubles, to be precise)).

Now, my question is this: Can I somehow verify that my application (the "client") is not missing any data when reading from the pipe? I know that those read/write operations are buffered, but I suppose the buffers will not grow indefinitely if the client doesn't fetch the data quickly enough. How do I know if I missed something? Does the server (or the pipe?) silently discard data that is not read in time by the client?

BTW, can I rely on proper alignment of the data the client reads using ReadFile()? As far as I understood, ReadFile() may return with less bytes read than specified, i.e. NumberOfBytesRead <= NumberOfBytesToRead. Do I have to check every time that NumberOfBytesRead is a multiple of sizeof(double)?


Alex

[kbw]

Named pipes in WIN32 have guaranteed delivery. Just check the error codes on your reads/writes.

[webJose]

kbw is correct. You are guaranteed data delivery. If the pipe is full in the server side, the thread writing to the pipe will block on the next call to WriteFile() until the client reads data off of it.

You are not guaranteed proper byte alignment. You may very well read half a double. Maybe the server does something to guarantee this to you, but it is not something inherent in the pipes model.

[alxx]

If the pipe is full in the server side, the thread writing to the pipe will block on the next call to WriteFile() until the client reads data off of it.

I just discovered that Sysinternals' FileMon can also monitor pipe operations. For testing purposes I connected the client to the named pipe and did _no_ read operations, just waiting. The server writes a few hundred kB to the pipe every 4--5 seconds, even though nobody is fetching the data from the pipe on the client side. No blocking write operation ... And so far no limits in buffer-size seem to have been reached.

This is either a very big buffer ... or the server does some additional magic to just using WriteFile() and waiting for the client to read.

You are not guaranteed proper byte alignment. You may very well read half a double. Maybe the server does something to guarantee this to you, but it is not something inherent in the pipes model.

I see. That means I should probably do some checking since I don't really know about the server ...

Thanks for your help, guys.

[Incubbus]

I got another question on this topic:

Am I able to connect to a Client/Server on the internet?... how to enter the target machines` name in my "CallNamedPipe" or any other else conncting function?



Inc

[webJose]

I have never done it, but I think you can specify the IP address instead of the host name. But you may very well forget about this. This requires File and Printer Sharing over the Internet, and 99.99% of the PC's firewalls will block this access from the public Internet.

[kbw]

Don't use Named Pipes for communication across a WAN. It has heavy overheads.

[Incubbus]

I read they were faster and more safe?... nothin about overhaed... where does the overhead come from?

greetings

[kbw]

The overhead comes from all the NT Security/Lan Manager crap. If you want to send data reliably across an IP network, use TCP.