D. Allen [CGL]" <idallen@watpix.waterloo.edu> (01/27/91)
Most stream entries in /etc/services are stream/nowait, so you get a fresh copy of the thing for every connection. However, stream/wait entries are allowed, and are useful for some kinds of daemons. For stream/wait entries under BSD, you get passed the socket descriptor *before* the accept() is done; on Ultrix you get passed the descriptor *after* the accept() is done. The Ultrix behaviour is needlessly limiting. Under BSD, you can specify stream/wait if you have a daemon that isn't used much, but which knows how to handle its own connections. When the first connection comes in, inetd starts it up, and it can stay around for a while, looping doing accept() on the socket descriptor. The daemon can continue accepting new connections, and eventually it can go away if there is nothing to do. We use this for a multi-person "chat" program here at Waterloo. Under Ultrix, you can't have a stream/wait daemon under inetd, because the accept() is already done and you have no access to the original socket descriptor. So the daemon can't use accept() itself and only one connection is possible. Comparing the source to Ultrix inetd.c and BSD inetd.c, the fix to repair the Ultrix stream/wait behaviour is quite easy; I wonder why Ultrix chose not to allow stream/wait services? -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada