overlapped IO named pipes unreliable
Chris Jeske
or feedback is most welcome.
I am using named pipes with overlapped IO for communication
between processes on different machines. The server machine
has 2 threads: The main thread does overlapped writes to the
pipe, and the other thread waits on the overlapped events for
completions. The client processes are similar: the main thread
starts an overlapped read of the expected size, and a separate
thread is waiting for the completion of the read.
The problem is that the server sends 2 initial messages to the
client. The first of these gets through, but the second does
not. In fact, the server's thread that is waiting on completions
never gets the completion for the second message.
I have checked everything that I can think of. The OVERLAPPED
structures used in the WriteFile() call are being maintained. I
am actually waiting on the same event handle that was specified
in the OVERLAPPED structure. I am not touching the buffer that
gets written before I get the completion for it. In short, everything
looks like it should work, but once the WriteFile() call returns,
the message just disappears into the ether.
Are named pipes unreliable in this way? Or do I need to flush
the buffers somehow?
As background, the server does a CreateNamedPipe() with
overlapped access, and PIPE_TYPE_MESSAGE | PIPE_READMODE_MESSAGE flags.
The client does a CreateFile() with overlapped flag set, and
then does a SetNamedPipeHandleState() to set PIPE_READMODE_MESSAGE.
Thanks for any help,
Chris Jeske
Slava M. Usov
>Are named pipes unreliable in this way? Or do I need to flush
>the buffers somehow?
No, so far nobody complained. How about posting some code we could look at?
-- Slava
Please send any replies to this newsgroup.
Felix Kasza [MVP]
> In fact, the server's thread that is waiting on completions
> never gets the completion for the second message.
I, too, would be interested in some code showing the problem. In the
meantime, however, you may want to check that you properly handle the
case where the I/O is executed synchronously -- async execution is
wholly at the discretion of the OS.
--
Cheers,
Felix.
If you post a reply, kindly refrain from emailing it, too.
Note to spammers: fel...@mvps.org is my real email address.
No anti-spam address here. Just one comment: IN YOUR FACE!
Gerbert Orasche
I have done quite a big bunch of eork on implementing exactly what you are
doing now. What I can say: Named Pipes are very reliable when doing
IOCompletion (at least more reliable than TCPIP on a localhost connection)
Most problems I had when completions were not signalled came from omitting
IO before the previous was finished.
cu
Chris Jeske <je...@gpu.srv.ualberta.ca> wrote in message
news:7af64n$n50$1...@pulp.ucs.ualberta.ca...
>Hi! I have run into a problem that has me stumped. Any suggestions
>or feedback is most welcome.
>
>I am using named pipes with overlapped IO for communication
>between processes on different machines. The server machine
>has 2 threads: The main thread does overlapped writes to the
>pipe, and the other thread waits on the overlapped events for
>completions. The client processes are similar: the main thread
>starts an overlapped read of the expected size, and a separate
>thread is waiting for the completion of the read.
>
>The problem is that the server sends 2 initial messages to the
>client. The first of these gets through, but the second does
>not. In fact, the server's thread that is waiting on completions
>never gets the completion for the second message.
>
>I have checked everything that I can think of. The OVERLAPPED
>structures used in the WriteFile() call are being maintained. I
>am actually waiting on the same event handle that was specified
>in the OVERLAPPED structure. I am not touching the buffer that
>gets written before I get the completion for it. In short, everything
>looks like it should work, but once the WriteFile() call returns,
>the message just disappears into the ether.
>
>Are named pipes unreliable in this way? Or do I need to flush
>the buffers somehow?
>
Chris Jeske
: I, too, would be interested in some code showing the problem.
: [ snip ] ...
We have a small test program that exhibits the behaviour I complained
about before, but only on an SMP machine with > 2 cpus. The problem
is very timing dependent in our real application code, so it was
somewhat difficult to reproduce :>
(We had done some quick tests to see if named pipes were viable, and
then plugged a named pipe module into our protocol code, so just posting
snippets of code would not have done the trick.)
I will make the test program as short as possible and post it
here to see if you people can find any flaws in it...
--
Chris Jeske
je...@gpu.srv.ualberta.ca
http://www.ualberta.ca/~jeske