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