Path: utzoo!mnetor!uunet!husc6!mailrus!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: GaaaK! Unix networking called "GOOD"?!?
Message-ID: <8805080127.AA22677@cory.Berkeley.EDU>
Date: 8 May 88 01:27:35 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 46

:In article <517@viscous> brianm@sco.COM (Brian Moffet) writes:
:that he would like to see unix on amiga's, and mentions all sorts of
:"good" things about unix. (Such as consistent devices (YEA!) and
:"standard networking" (presumably meaning sockets.)
:
:My rebuttal:
:Unix? Isn't that the thing that limits you to 16 files per process?
...
:In sockets, you are heavily limited to only 16 total.
:In Sockets, you have one message port for making connections, and you must
:have another port for each person you are currently talking to. (16 max).
...
:In sockets, you can only select(), and then you have to actually poll
:to see which one said hi. If you poll in order (1-2-3-4-5-etc), it is
:possible for a message to come in on 2 after you've check it.

	Where did this guy come from?  This is total bull and everybody
knows it.  I don't even know which UNIX system you are comparing.  In
the system I use (BSD4.3), the PER PROCESS limit can be anything up to
256, and is usually set at 64.  The select() call returns variables
telling you *exactly* which file descriptors are ready for reading,
writing, or have an exceptional condition pending, no polling involved
from the process's standpoint (though I admit there is considerable
overhead for the system setting up the sleep/wakeup).  Anybody who uses 
select() not only knows this, but understands the programming mechanics
of it as well... 

	"If you poll in order ..." . no dah, the same thing would happen
under any multiple-stream based file handled system.  When you loop around
to the next select, it returns immediately with the 2 that came in after
you processed them.  Atomic operations don't exist under sockets (for
STREAM sockets), at least not in terms of getting arbitrarily sized data 
blocks (>1K) in one read(), but then again, since you know the block size
it's trivial to loop on it and get 'atomic' operations.  There are a
thousand ways to do it.

	As far as multiple writers go, it's quite simple.. you just
dup() a socket descriptor, fork (or fork/exec), and whalla, you have
multiple writers.  You seem to have glossed over the reasons WHY UNIX does
things the way it does.  Does the word "firewalls" mean anything?  How 
about "Network Compatible Communications Standard"???  I don't know about
you, but I like being able to ftp some far away ARPA node from any machine
on campus.... the networking system may transparently route it through a
dozen machines or more, but it works quite efficiently.

					-Matt