[jcifs] Re: [jcfs] Re: Large File upload performance

Michael B Allen mba2000 at ioplex.com
Sun Sep 21 06:10:08 EST 2003


>> because the server could (and probably would) receive each in separate
>> packets. A well behaved server should accept this but I seriously doubt
>> they do.
>
> ...but you're right, they should.  It should be read as a stream on the
> receiving end, and this type of problem should be handled because TCP
> messages can be fragmented in transit, with chunks lost here and there.
> Also, it is possible to send SMBs that are larger than the (MTU-overhead)
> size, and these will certainly be fragmented.  So, this may be worth a
> try.

The problem scenario is:

read(sock, buf, 32);

where it is not considered that fewer than 32 bytes could be read. It's
simply assumed that reading such a small amount would always succeed and
99.999999% of the time it will. For 100% success however something like
the following function would be necessary:

ssize_t
readn(int fd, void *dst, size_t n)
{
	size_t nleft;
	ssize_t nread;
	char *ptr;

	ptr = dst;
	nleft = n;
	while (nleft > 0) {
		if ((nread = read(fd, ptr, nleft)) < 0) {
			return nread;
		} else if (nread == 0) {
			break;
		}
		nleft -= nread;
		ptr += nread;
	}
	return n - nleft;
}

Given that SMB servers decode messages incrementally (they have to as they
discover how big the next fragment is) and the track record in quality of
implementations, I do not have confidence that *every* read of every
server encountered properly handle short-counts. And testing each server
requires special software that deliberately floods a server with
fragements. Larger MTU+ sized messages are all variable sized payloads
read in chunks which undoubtedly *do* consider the read return value so it
cannot be extrapolated that all reads will be handled properly.

Mike

-- 
A program should be written to  model the concepts of the task it
performs rather than the physical world or a process because this
maximizes the  potential for it  to be applied  to tasks that are
conceptually similar and, more  important, to tasks that have not
yet been conceived.



More information about the jcifs mailing list