Path: utzoo!mnetor!uunet!husc6!mailrus!ames!ucsd!sdcsvax!ucsdhub!jack!elgar!ford
From: ford@elgar.UUCP (Ford Prefect )
Newsgroups: comp.sys.amiga
Subject: Re: GaaaK! Unix networking called "GOOD"?!?
Message-ID: <147@elgar.UUCP>
Date: 8 May 88 20:25:22 GMT
References: <517@viscous> <10227@stb.UUCP>
Reply-To: ford@elgar.UUCP (Ford Prefect )
Organization: Omnicron Data Systems,  Bonita, CA
Lines: 105
Keywords: Unix SYSV 4.2 Amiga
Summary: AntiFlame  (Yes, Amiga Exec is good, but <10227@stb.UUCP> is B.S.)

Uh-oh, another one of those articles where I won't be able to sleep
with the thought that someone might read that article and actually
*believe* some of it...

In article <10227@stb.UUCP> michael@stb.UUCP (Michael) writes:
>"standard networking" (presumably meaning sockets.)

Not necessarily sockets.  AT&T has a completely different IPC/
networking methodology.  I don't know why, since BSD networking is one
of the few BSD enhancements that was neither a hack nor a kludge,
but a very well-designed system.

>My rebuttal:
>Unix? Isn't that the thing that limits you to 16 files per process?

In the olden days many years ago, Unix systems were typically configured
with a maximum of 20 simultaneously open files per process.  Nowadays
it's a tunable kernel parameter, with a typical value of 60 or 80.  I
never found 20 to be a limitation anyway, although it was a bit silly
that the older Sun servers could only serve 19 workstations at a time.

>In Chaos (Commodore's Home-made Amiga Operating System), there is no
>limit to the number of message ports or file handles you can have
>open.
>In sockets, you are heavily limited to only 16 total.

(The limit is more like 100, see above.)  If you can think of an
application that can use that many separate connections, I'll be
surprised.

>In Chaos, you can have one message port to talk to everyone, simplifying
>all your communications

If you find this simpler, you can do it with sockets too.

>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).

This is only if you choose to make a connection, something which
"chaos" can not even do.  And again, your number 16 seems to have come
out of thin air.

>In Chaos, you can easily wait for a message on any port, including getting
>software interrupts, or even running as the task that sent you the message
>(undocumented, but it's there in 1.2)

Same with sockets, except the last bit, which is not applicable to the
socket abstraction anyway, since it is much more general (i.e., the
"other end" can be on a different machine on a different network with
a different type of CPU).  And with Unix you can wait for a message on
things other than an ipc port (like a serial port).

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

This is not true.  All normal I/O operations are applicable to sockets,
and the select function returns a list of descriptors which are ready.
The select() process is reliable in that you will never sit waiting
for a message when you already have one ready.

And it's actually "chaos" where you have to poll, or be limited to 16
signal bits for message ports.  If you use software interrupts, you
still have to signal your process, and either do the equivalent of
polling or again devote a signal to each type of event you want to
see.  But I still think that most programs are only interested in one
or two types of messages and will not be wanting to select lots of
message ports.  If it's properly designed, it can have just one main
input stream and encode the message type and reply-address in the
message.  This works with Exec messages or BSD sockets.

>In Chaos and V7-ATnT, pipes are atomic.

Also not true.  "Chaos" does not have pipes.  Unix pipes are not
atomic; you can read any or all of the bytes that have been queued in
one read() call.  A pipe device driver can be (and has been) written
for AmigaDos, and whether it is "atomic" is up to the implementor.
The same is true of Unix.

>In sockets, pipes are completely unguaranteed for multiple writers.

Sockets are not necessarily pipes.  The pipe() call on BSD returns two
connected sockets which act very much like the original pipes of Unix.
But you can create sockets of your own using IP or UDP protocol and
connect them.  Then you have guarranteed delivery (IP) or atomic
datagrams (UDP) or both if you layer some handshaking on UDP.  You can
choose between "connection-oriented" or "connectionless" communication
and still talk to a port on another machine.


Anyway, I agree that the Amiga Exec has a very powerful and flexible
low-level message-passing mechanism.  But it is very specialized and
is optimized for a very different purpose than Unix IPC.

I think that behind all stb!michael's handwaving I can see his real
objections, which boil down to the standard "Unix vs. Exec /
abstract vs. concrete / portable vs. programming-on-the-metal" debate
which I don't want to start up again.

					-=] Ford [=-

"Once there were parking lots,		(In Real Life:  Mike Ditto)
now it's a peaceful oasis.		ford%kenobi@crash.CTS.COM
This was a Pizza Hut,			...!sdcsvax!crash!kenobi!ford
now it's all covered with daisies." -- Talking Heads