Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!ucbvax!BU-CS.BU.EDU!root
From: root@BU-CS.BU.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  tcp on SUN computers.
Message-ID: <8606060122.AA26592@bu-cs.bu.edu>
Date: Thu, 5-Jun-86 21:22:32 EDT
Article-I.D.: bu-cs.8606060122.AA26592
Posted: Thu Jun  5 21:22:32 1986
Date-Received: Fri, 6-Jun-86 20:20:27 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 52
Approved: tcp-ip@sri-nic.arpa


There are two questions in your query,

1.> ...Finally, my question is this.  Why is there a 2K limit, and
>can it be changed, perhaps with a kernal reconfiguration?  

It almost certainly can be changed given sources, perhaps it can be
changed otherwise or perhaps that is a suggestion that might be
reasonable for binary sites. Perhaps for performance reasons it
doesn't make sense to change this (what is a better number and why?
Simply that it would make it easier for you to ignore the fact that
you are doing non-blocking I/O is not a great reason.)

2.> 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?

This is a different question. Most importantly you state that this
occurs only with non-blocking I/O.

In the first place, this is not 'packetizing'. You provided 2K bytes
and it received 2K bytes (and made it available to your consumer
process.) The fact that they are both the same size is neither a
coincidence nor a fault of the implementation. Something like packetizing
might be implied had you read less than 2K and found the difference
thrown off the floor (I guess, not sure there is any way this term
can be worked into this conversation sensibly.)

At some point a resource runs out, there is no way around that. On
blocking (normal mode) I/O this results in a the process being blocked
and waiting until resources are available. When you requested non-blocking
I/O the system still had to do *something* when resources ran out (as
I said, exactly how much of this resource should be allocated to a given
process is an entirely different question.) What would you suggest it
do? Ignore your I/O? Do it "anyhow"? Block you "anyhow"? I think it
is doing the right thing (telling you immediately that I/O is not possible
right now.)

I think this was simply necessitated by allowing the user to specify
non-blocking I/O, there is no fundamental difference between this and
blocking I/O except the reason you felt it was "unlimited" in the latter
case was only because the system took the responsibility for making you
wait, as soon as you requested non-blocking I/O you stated that you
wished to take that responsibility on yourself (ie. you probably had
something else to do while waiting.)

>Robert Allen

	-Barry Shein, Boston University