[jcifs] Problem reading multiple writes from named pipe

Eric Sword ericsword at grouplogic.com
Thu Apr 10 23:38:33 EST 2003


The main difference is that I do 2 reads and 2 writes for every send
from either side.  The real protocol I am trying to implement is to send
a 4-byte int that is the length of the rest of the message and then to
send the message itself.  Reading is done the same - read the length
then read the message.  When I was using a BufferedOutputStream to send
the data to the C++ program, I would get the 234 error in my modified
createnp.c when reading the length.  This was reasonable because the
buffered stream wouldn't actually write until I called flush(), so there
was really only 1 write on the underlying communication stream.  When
createnp issued a ReadFile with a buffer length of 4 to get the int, it
would properly return the 234 error.  Everything else would be fine.  It
would read the length and then read the rest of the data as well.  I
switched to just use the regular OutputStream and issuing 2 "real"
writes to it on the Java side and now the C++ side does not get the 234
error, though the Java side now is.  

The main difference between my createnp and yours is that I have 2
writes:

	[snip - read in length and then message using two ReadFile
calls]
	[snip - length of read message is put into length variable]

	//write length
	returnCode = WriteFile(outFile, &length, sizeof(length),
&bytesWritten, NULL);
	//echo message
	returnCode = WriteFile(outFile, buf, bytesRead, &bytesWritten,
NULL);

The secondary difference is that I am running on Windows on both sides
while you appear to be running on a Unix box judging from your command
prompt.  I don't know if Windows would exhibit other behavior for some
reason.

(I should point out that I used an unmodified PipeTalk to make sure it
generated the same exception as my other tester program.  It still does
just one read/write while the modified C++ program did 2 read/writes in
return.  So the C++ side would get the 234 error in this case, but I put
in error checking to handle that.)

Does that help?

Thanks,

Eric

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


On Wed, 9 Apr 2003 19:48:46 -0400
"Eric Sword" <ericsword at grouplogic.com> wrote:

> 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)
...
> 
> 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.

I'm having trouble reproducing this Eric. I modfied createnp to send
back a larger amount of data without problems:

[miallen at miallen3 jcifs]$ java -Djcifs.properties=../miallen.prp
PipeTalk "smb://miallen2/ipc$/foo" yoyoyo yoyoyo yoyoyoXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXX

As you can see prints each chunk of 20 bytes just like the call asks
for. Echoing more than 20 bytes without the createnp.c mod also yields
the expected results:

[miallen at miallen3 jcifs]$ java -Djcifs.properties=../miallen.prp
PipeTalk "smb://miallen2/ipc$/foo"
thisstringismuchlongerthantwentybytesinlength
thisstringismuchlongerthantwentybytesinlength
thisstringismuchlong
erthantwentybytesinl
ength

Can you tell me how to modify createnp.c to reproduce this
ERROR_MORE_DATA behaviour? That's definately wrong. The change I made
was simply:

static const char *extra =
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX";
...
while(ReadFile(inFile, buf, bufferSize, &bytesRead, NULL) > 0) {
    char out[0xFFF];
    int len = strlen(extra);
    memcpy(out, buf, bytesRead);
    memcpy(out + bytesRead, extra, len);
    WriteFile(outFile, out, bytesRead + len, &bytesRead, NULL); }

Mike



More information about the jcifs mailing list