More questions on sockets

[John Chambers]

In article <1991Jun14.162215.14657 at ncsu.edu>, jwb at cepmax.ncsu.edu (John W. Baugh Jr.) writes:
> I'm trying to write "send/receive"-like functions (i.e., send(msg,to),
> receive(msg,from)) to hide some of the details of Internet stream
> sockets for interprocessor communication (oh yeah, and I really don't
> know what I'm doing).  Anyway, a couple of questions:
> 
>   - 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?

It often takes about 2 minutes for the kernel to finush closing down a
TCP (stream) connection. It has to wait for the stream to drain and/or
timeout before it can allow reuse of the  port.   It's  annoying,  but
there's not much to be done about it.

>   - 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.  Okay, so that's
>      probably asking too much.  

Hmm... I've worked with some libraries that did it this way, and in my
experience, this is a bad idea.  It sounds good at first, and seems to
work in small-scale tests.  Where it gets you into trouble is when you
have  two packages X and Y linked into your program, and they both try
to talk to remote servers. Messages go out, and then a message arrives
for  your  process.   Now  let's  see, should it be given to the input
routine in package X or the one in package Y?  In general, the routine
that  gets  the  message  has no way of knowing what other routines in
which other libraries may be looking  for  it;  solving  this  problem
becomes a major artificial-intelligence project.

The file abstraction is a much better solution, because it allows each
package  to set up and completely control its own communications, with
no interaction between separate packages that happen to be linked into
the same process.

-- 
All opinions Copyright (c) 1991 by John Chambers.  Inquire for licensing at:
Home: 1-617-484-6393 ...!{bu.edu,harvard.edu,ima.com,eddie.mit.edu,ora.com}!minya!jc 
Work: 1-508-486-5475 {sppip7.lkg.dec.com!jc,ub40::jc}