neerma@COD.NOSC.MIL (Merle A. Neer) (02/19/88)
------- It just occurred to me that this list may be the best place to go for help with a problem we have been struggling with for years. We have been developing client/server processes on tcp for going on ten years and have had the unfortunate experience of having to sometimes do it on UNIX. The problem simply stated is this: the user process cannot get the status of its tcp connections from UNIX. Yeah, we know about SIGPIPE but it only works sometimes. What I'm really concerned about is that so many other implementations of tcp seem to be derived directly from the UNIX bsd versions of tcp. They in turn inherit the deep dark mysteriousness of the status of connects. Have any UNIX guru-types ever considered offering a 'status(myconnect)' call? We'll gladly pay for one. Or even just a 'signal(YOURCONNECTISBOGUS,letmeknow)' would be nice? I would like also to hear from other unfortunate souls that have to program on UNIX tcp to see how they have dealt with this problem. Yes, we have worshipped at the UNIX altar long enough to deserve some secrets. Just a few. Merle Neer neerma@nosc -------
dannyb@kulcs.uucp (Danny Backx) (02/24/88)
> sometimes do it on UNIX. The problem simply stated is > this: the user process cannot get the status of its > tcp connections from UNIX. [...] > Have any UNIX guru-types ever considered offering a > 'status(myconnect)' call? We'll gladly pay for one. > Or even just a 'signal(YOURCONNECTISBOGUS,letmeknow)' > would be nice? [...] > Merle Neer > neerma@nosc Could you post a more complete list of what you think a user interface to TCP should include ? As for your request on 'YOURCONNECTISBOGUS', I think you can arrange something like that on BSD. (I don't know whether you're talking about BSD or Sys-V). If you are interested, look in the manual entries for socket(2), setsocketopt(2) - look for the SO_KEEPALIVE option. I'm not sure if you can detect dead connections with select(2), or maybe with SIGIO or SIGURG. If you find a way, please post it. I'm sure lots of people are interested. Danny -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Danny Backx | mail: Katholieke Universiteit Leuven Tel: +32 16 200656 x 3537 | Dept. Computer Science E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A ... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven dannyb@kulcs.BITNET | Belgium
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (03/01/88)
On our emulation of Berkeley sockets (on a DOS PC), select() will indicate that a connection is readable, writeable, and/or has an exception, depending on which conditions were select'ed, if the connection has died. The theory is to cause the caller to do an I/O specific to that connection, whereupon he will get an error. In the process of determining what to do, it was discovered that this behaviour is not consistent across real Unix implementations. What does POSIX say? James VanBokkelen FTP Software Inc.
mouse@mcgill-vision.UUCP (der Mouse) (03/17/88)
In article <8802181625.AA27348@cod.nosc.mil>, neerma@COD.NOSC.MIL (Merle A. Neer) writes: > The problem simply stated is this: the user process cannot get the > status of its tcp connections from UNIX. > Have any UNIX guru-types ever considered offering a > 'status(myconnect)' call? We'll gladly pay for one. If you're running 4.3, I can give you a socket ioctl to return the status of the connection (as in one of the values in ../netinet/tcp_fsm.h, like TCPS_LISTEN, TCPS_ESTABLISHED, TCPS_CLOSING, etc). It's not really hard; it'd take all of an afternoon. Just drop another ioctl into ../h/ioctl.h and into ../netinet/tcp_usrreq.c (in the if req == PRU_CONTROL statement). der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu