Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU.UUCP
Newsgroups: comp.windows.x
Subject: Re: 128k request limit
Message-ID: <870413081741.6.RWS@KILLINGTON.LCS.MIT.EDU>
Date: Mon, 13-Apr-87 07:17:00 EST
Article-I.D.: KILLINGT.870413081741.6.RWS
Posted: Mon Apr 13 07:17:00 1987
Date-Received: Tue, 14-Apr-87 23:47:47 EST
References: <18287@ucbvax.BERKELEY.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 23


    >		  At connection setup the server states the maximum request size
    >that it will accept; the maximum value it can state is 256Kb.

	    Why is there a limit at all, e.g. why not allow up to whatever the
    server's (operating system/environment/hardware imposed) limit is?

In the V11 encoding, each request/reply includes a uniform length field
giving the total length of the request/reply.  This makes it much easier
to handle I/O in the normal case (and also makes it possible to write
certain kinds of IPC filters).  The request length field is 16-bits,
expressed in units of 4 bytes.  This is perfectly adequate for
essentially everything but sending huge images; making the length field
32-bits would mean wasted space in nearly all requests.  (The reply
length field is 32-bits, since replies are rare, and since it is useful
to be able to get back a large image in one piece.)  As I have said, I
believe sending large images in chunks is acceptable (and more efficient
in most server implementations, which must buffer an entire request
before executing it).  If one is serious about sending huge images, the
client will probably be running on the same machine as the server, and
one would do well for performance to define a protocol extension to pass
the image directly using a pointer to shared memory, in which case the
length restriction again doesn't matter.