dcvint@lion.uwaterloo.ca (Dee Vint) (03/14/91)
Does anybody know of an implementation of Berkely sockets for SCO (or any other) System V unix system? Before I attempt to create my own implementation I would like to know if somebody has done it or started and found it couldn't be done. If your wondering why I need it, it is because our current assignment in my Operating Systems course requires me to right a remote filesystem using RPC's and they want it implemented using Berkley socekts (I guess it because the school machine all run Berkley unix). Any Help would be appreciated. Thanks in Advance -- -----------------------------------------------------------------------------. | Diane Vint (Dee), dcvint@lion.waterloo.edu | | Co-op Term | | Gellman.Hayward & Partners Ltd |
cpcahil@virtech.uucp (Conor P. Cahill) (03/14/91)
dcvint@lion.uwaterloo.ca (Dee Vint) writes: >Does anybody know of an implementation of Berkely sockets for SCO (or any other) > System V unix system? Before I attempt to create my own implementation I would >like to know if somebody has done it or started and found it couldn't be done. Most, if not all, of the System V/386 vendors include a sockets compatibility library layered on top of streams. I have used ISC's version and it appears to work fine (i.e. I have had no problems porting socket code between my system and other BSD systems). I have heard that ESIX has some problems in thier implementation. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc. uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
carroll@cs.uiuc.edu (Alan M. Carroll) (03/15/91)
In article <1991Mar14.122151.21216@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > dcvint@lion.uwaterloo.ca (Dee Vint) writes: > > >Does anybody know of an implementation of Berkely sockets for SCO (or any other) > > System V unix system? > I have used ISC's version and it appears > to work fine (i.e. I have had no problems porting socket code between > my system and other BSD systems). A problem that I have had (2.0.2) with ISC is that if I have a socket that is a passive socket, and I poll() on it, waiting for input, poll() does _not_ return when another process connects to the socket (neither does select()).. This means that if I want to read/write on connected sockets _and_ listen for new connections, I lose. -- Alan M. Carroll "I hate shopping with the reality-impaired" Epoch Development Team - Susan CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll
carroll@cs.uiuc.edu (Alan M. Carroll) (03/16/91)
In article <1991Mar14.193619.21766@m.cs.uiuc.edu>, carroll@cs.uiuc.edu (Alan M. Carroll) writes: > In article <1991Mar14.122151.21216@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes: > > dcvint@lion.uwaterloo.ca (Dee Vint) writes: > > > > >Does anybody know of an implementation of Berkely sockets for SCO (or any other) > > > System V unix system? > > I have used ISC's version and it appears > > to work fine (i.e. I have had no problems porting socket code between > > my system and other BSD systems). > > A problem that I have had (2.0.2) with ISC is that if I have a socket > that is a passive socket, and I poll() on it, waiting for input, > poll() does _not_ return when another process connects to the socket Thanks to a totally excellent system dude at ISC, I now have my code working under 386ix (2.0.2). The bottom line is that under 386ix, passive sockets indicate a _priority_ message when a connection is made, not a normal input waiting. By changing my code to take this into account, it works. However, I'd say that this does count as an incompatability, since on a number of other OS's, passive sockets indicate input waiting when a connection is made (in particular, this is the case under SunOS for both select() and poll()). -- Alan M. Carroll "I hate shopping with the reality-impaired" Epoch Development Team - Susan CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll
mjhammel@Kepler.dell.com (Michael J. Hammel) (03/19/91)
In article <1991Mar14.193619.21766@m.cs.uiuc.edu>, carroll@cs.uiuc.edu (Alan M. Carroll) writes: > A problem that I have had (2.0.2) with ISC is that if I have a socket > that is a passive socket, and I poll() on it, waiting for input, > poll() does _not_ return when another process connects to the socket > (neither does select()).. This means that if I want to read/write on > connected sockets _and_ listen for new connections, I lose. Hmm. Maybe I don't understand the problem, but how about doing it like this: for (;;) /* begin infinite loop waiting for new connections */ { if ( (t=accept(s, &isa, &i) ) < 0) /* hang in accept, wait for new connects*/ { ...error checking code } if ( (childpid=fork()) == 0) /* child process if fork() returns 0 */ { ...handle connection here in child process; the child inherits the socket } close(t); /* close the socket from the accept call */ } This should allow you to read/write on connected sockets in a child process and wait for more connections in the parent. You can specify how many accepts can be queued with a listen() call, I believe. This seems to work in a simple application I wrote. Michael J. Hammel | mjhammel@{Kepler|socrates}.dell.com Dell Computer Corp. | {73377.3467|76424.3024}@compuserve.com #include <disclaim/std> | zzham@ttuvm1.bitnet | uunet!uudell!feynman!mjhammel #define CUTESAYING "Recycle. Just do it."
carroll@cs.uiuc.edu (Alan M. Carroll) (03/20/91)
I'm going to move this over to comp.unix.programmer, because it's changed into a socket programming discussion. In article <16730@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes: > In article <1991Mar14.193619.21766@m.cs.uiuc.edu>, carroll@cs.uiuc.edu > (Alan M. Carroll) writes: > > [ Can't poll() listening sockets ] > Hmm. Maybe I don't understand the problem, but how about doing it like this: > > for (;;) /* begin infinite loop waiting for new connections */ > { > if ( (t=accept(s, &isa, &i) ) < 0) > { > ...error checking code > } > > if ( (childpid=fork()) == 0) /* child process if fork() returns 0 */ > { > ...handle connection here in child process; the child inherits the socket > } There's a number of reasons for not doing it that way. The program that I am writing is a "software bus", which accepts messages from a set of clients, and routes those messages to the set of clients that are interested in them. Each client connects to the bus via a scoket, which is used to send messages to other clients, and receive them. 1. I don't like fork(), and avoid it whenever possible. Partly it's a resource thing (particularly process slots), and partly because I consider dealing with child processes painful, buggy, and less than portable. 2. For connecting on sockets, I think that fork() only makes sense if the child processes do significantly different things, as for example in inetd. However, in my program every socket is treated in exactly the same way. Therefore, that functionality should be moved into the single program, to save CPU, memory, and process slots. 3. Because of the nature of the program, data from any socket can have a need to be sent to an arbritrary subset of all the other sockets. In order to do this using child process, each child process would have to have a means of communicating with either all the other child processes (and detect when any of them exited), or with the parent process which would then forward the messages. The former is too ugly to even discuss*. The latter can't work, because it brings us back to the original problem - how does the parent move the data when it's hanging on an accept? 4. I don't have threads, which might otherwise seem like a better solution. *This is of course the problem the program was built to solve. -- Alan M. Carroll "I hate shopping with the reality-impaired" Epoch Development Team - Susan CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll