[jcifs] Problem reading multiple writes from named pipe

Eric Sword ericsword at grouplogic.com
Thu Apr 10 09:48:46 EST 2003

Using just the PIPE_TYPE_RDWR parameter definitely helps.  I had tried
this before, but kept getting errors.  By process of elimination, I
realized that my use of a BufferedInputStream to wrap the one returned
by pipe.getNamedPipeInputStream() was causing problems.  It wasn't
reading from the underlying stream the exact amount that had been
written from the other side and would throw errors.  By switching to
just using the regular input streams (and copying into a temporary
buffer which I read from in bits and pieces), those problems go
away...for the most part.

There is still a problem in the underlying stream handling I believe.
At least on Windows, if the in.read call (in PipeTalk's ReceiverThread
class in this case) does not read all data from a corresponding write, I
see this exception thrown:

jcifs.smb.SmbException: No description available [ERRDOS/234]
        at jcifs.smb.SmbTransport.send(SmbTransport.java:496)
        at jcifs.smb.SmbSession.send(SmbSession.java:107)
        at jcifs.smb.SmbTree.send(SmbTree.java:92)
        at jcifs.smb.SmbFile.send(SmbFile.java:466)
        at PipeTalk$ReceiverThread.run(PipeTalk.java:18)

I recognized that Windows/DOS error number from seeing it in my C++ test
app.  It's ERROR_MORE_DATA.  You can see it in PipeTalk if you try to
echo more than 20 characters (the size of ReceiverThread's char[]).  I
triggered it with my program because I get back 16-20K of data in a
single write.  Even when I issue the read with a 64K buffer, it still
doesn't get it all at once for some reason and trigger's this exception.

Would it make sense to put in handling in the SmbTransport class to
check for this error and not throw an exception?  Just because there is
more to read doesn't mean doesn't mean there is necessarily an error,
does it?



-----Original Message-----
From: Michael B.Allen [mailto:Michael_B_Allen at ml.com] 
Sent: Tuesday, April 08, 2003 10:32 PM
To: Eric Sword
Cc: jcifs at lists.samba.org
Subject: Re: [jcifs] Problem reading multiple writes from named pipe

I don't think it makes sense to use PIPE_TYPE_CALL or PIPE_TYPE_TRANSACT
because those send a message and get a response on *one round trip*
whereas without PIPE_TYPE_CALL or PIPE_TYPE_TRANSACT you try to read
which blocks and then write and get a write response and finally the
read returns with the result. If you do not use PIPE_TYPE_CALL or
PIPE_TYPE_TRANSACT what you describe works. I modified createnp.c to
write a 0xFF byte for each message read like:

    154     while(ReadFile(inFile, buf, bufferSize, &bytesRead, NULL) >
0) {
    155         char b = 0xFF;
    156         int tmp;
    157         WriteFile(outFile, &b, 1, &tmp, NULL);
    158         WriteFile(outFile, buf, bytesRead, &bytesRead, NULL);
    159     }

ran it with:

    C:\Temp> createnp \\.\pipe\foo

and took a capture of the following PipeTalk:

    $ java -Djcifs.properties=jcifs.prp PipeTalk

and I can see that two separate packets are sent in the response for the
WriteFile calls. So it works.


More information about the jcifs mailing list