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