Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.programmer
Subject: Re: More questions on sockets
Message-ID: <1991Jun18.050654.17373@thunder.mcrcim.mcgill.edu>
Date: 18 Jun 91 05:06:54 GMT
References: <1991Jun14.162215.14657@ncsu.edu>
Organization: McGill Research Centre for Intelligent Machines
Lines: 41

In article <1991Jun14.162215.14657@ncsu.edu>, jwb@cepmax.ncsu.edu (John W. Baugh Jr.) writes:

>   - when trying to bind a stream socket I sometimes get an error
>     "Address already in use", even though I've closed the socket (for
>     example, when I run the program in succession a couple of times).
>     Is there something else I have to do?

Wait.  As far as I can tell that's the only thing to be done.  (Unless
you want to set SO_REUSEADDR with setsockopt, in which case there is no
protection against one copy of the daemon stealing the port from a
previously-running copy.)

The problem is that you can't bind a socket port N when there exists
any other socket on that machine with a matching address and port, even
if that other socket is part of an established connection, is a
leftover from a previous connection, or is otherwise not the source of
a potential conflict.  (I consider this a bug, but have never been
sufficiently annoyed to fix it.)

If you run netstat, you can see the stray socket lying around making
life hard for you....

>   - assuming I'm on the right track (big assumption), is it possible
>     to raise the level of abstraction of my send_msg/recv_msg
>     functions.  For example, ideally one would like to do the
>     following:
>        send_msg(char *msg, int size, int process);
>        recv_msg(char *msg, int size, int process);
>      where "process" may be a process on any machine.

This is workable *if* you're willing to create some sort of server to
deal with mapping between the "process" values and <machine,port>
pairs.  Given that, there's no problem.  (Such a program is probably
not difficult, unless you want some sort of pre-definition of the
"process" values....)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu