[jcifs] Problem reading multiple writes from named pipe

Eric Sword ericsword at grouplogic.com
Thu Apr 17 22:49:18 EST 2003

That matches the behavior I saw prior to switching to just the
PIPE_TYPE_RDWR constant.  The only problem is that our existing
application does, in fact, read and write twice to a transact named
pipe.  That's why I had to deal with this screwy protocol to begin with;
I didn't just make it up for grins. ;-)  It's been working great this
way for about 5 years now.  As I mentioned previously, the PipeTalk
application seems to function fine talking to the pipe in our main
application (and my pipe_project tester), except when it tries to read a
very large amount of data (>5K-10K), even though the data does not
exceed the side of the buffer given.

In any case, thanks for the help.  This is a side project that I will
return to as I am able.  If I discover anything new, I will post it.


> -----Original Message-----
> From: Michael B.Allen [mailto:Michael_B_Allen at ml.com] 
> Sent: Wednesday, April 16, 2003 9:22 PM
> To: ericsword at grouplogic.com
> Cc: jcifs at samba.org
> Subject: Re: [jcifs] Problem reading multiple writes from named pipe
> On Tue, 15 Apr 2003 15:15:28 -0400
> "Michael B.Allen" <miallen at ioplex.com> wrote:
> > > > >pipe_project \\.\pipe\foo /M 0x80000003 /P 0x6
> > > > 
> > > 	I don't think you can do this Eric. Before I believe I mentioned
> > > 	PIPE_TYPE_CALL would not work with separate write. The
> > > 	above flags would create a transact named pipe. I'm surprised
> > > 	this server works with PipeTalk. If you want to use
> > > 	must issue your message in one buffer. If you want to use
> > 
> > Actually, on second thought, I believe PIPE_TYPE_TRANSACT should be 
> > able to receive from multiple writes. PIPE_TYPE_CALL definately 
> > cannot. I'll look closer at this and get back to you. In 
> the meantime, 
> > if it doesn't matter to you, you can use the regular file IO style 
> > pipe.
> No. My origial suspicion was correct. It does not appear that 
> you can write twice on the server end of a Transact Named 
> Pipe. The PipeTalk program unmodified creates a File IO style 
> named pipe which is incorrect with the options you provided 
> to createnp.exe. If you modify PipeTalk to include the '| 
> PIPE_TYPE_TRANSACT' flag it does not generate the 234 
> Exception and correctly performs the transact named pipe 
> operation (as observed on the wire) but the server generates:
>   C:\Temp>pipe_project \\.\pipe\foo /M 0x80000003 /P 0x6
>   Attempt Connect.
>   Pipe connection successful.
>   Start Read.
>   bytesRead: 66
>   read: hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
>   length written
>   bytesWritten: 66
>   errorCode: 109
>   Success: operation performed successfully
> Error 109 is 'The pipe has been ended'.
> Mike

More information about the jcifs mailing list