Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!SRI-SPAM.ARPA!robert
From: robert@SRI-SPAM.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: tcp on SUN computers.
Message-ID: <8606052118.AA06342@sri-spam.arpa>
Date: Thu, 5-Jun-86 17:18:12 EDT
Article-I.D.: sri-spam.8606052118.AA06342
Posted: Thu Jun  5 17:18:12 1986
Date-Received: Fri, 6-Jun-86 00:30:22 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 46
Approved: tcp-ip@sri-nic.arpa


Hello there,

	I have a question regarding the implementation of TCP
used on the SUN computers.  Specifically the question concerns
version 2.2 of SUN UNIX, but will no doubt extend to their later
(and earlier) releases.

	The question follows;

	I have had occasion to use non-blocking sockets (TCP links)
as a link across the Internet between 2 or more SUNs.  Empirically,
I have discovered that there is a limit of 2048 bytes which can
be written in a single non-blocking write.  Anything more than
that and an error is returned "EMSGSIZE", which indicates that
the internal buffer is only 2048 bytes.  Note that if I use
blocking sockets, the size is unlimited.  There is also a limit
of 4096 bytes total which can be held "in the pipe", before the
receiving side of the socket must do a read to clear the internal
buffers.
	In a Client/Server relationship, the server will read
the bytes which the client writes into the socket.  I've noticed
that with non-blocking sockets where greater than 2K bytes can
be written, that continuous calls to recv() or read() by the server
will return 2K byte chunks.  This leads me to believe that the
SUN implementation can only handle a max of 2K byte transfers, and
with only two of these before a read must be done.  I've talked
with SUN tech support and they tell me that this 'seems to be'
the case, although without talking directly to an engineer I could
not get a good idea of why this is.
	Finally, my question is this.  Why is there a 2K limit, and
can it be changed, perhaps with a kernal reconfiguration?  It seems
to me that putting such a limit on the sockets is a poor implementation
for that layer, which should not restrict data size.  Shouldn't
such 'packetizing' be done at a lower layer than what sockets are
the entry point to?  Or are sockets actually a lower layer interface
than I think?

	Any comments, pointers, or commiserations would be greatly
appreciated.

					Robert Allen

					(415) 859-2143,

					robert@sri-spam.ARPA