Re: UDP socket close problem

From: Mark Stevens (mas78910_at_hotmail.com)
Date: 12/04/03 

Date: 4 Dec 2003 01:53:52 -0800

Michael Kerrisk <michael-dot-kerrisk-at-gmx-dot-net@NOSPAM.COM> wrote in message news:<f45psv89lfd5sj2ga5omoau1hsbjg33f50@4ax.com>...

<snip>

>
> Now, with a bit of work, I can replicate the behaviour you describe
> (though I'm not quite sure why things are done this way). But what
> you are doing doesn't seem to make sense in the light of your first
> paragraph. You say that you choose an ephemeral port by binding to
> port 0. That's fine. But in the second para you talk about another
> server binding to that same port. Why are you doing this -- why does
> it matter to this server that it binds to the same ephemeral port as
> the earlier server invocation? And why do you have clients sending
> datagrams to a port to which there is no server? (I ask this because
> it sounds like the problem may be solved by a different -- perhaps
> better -- application design.)
>
> (By the way, SO_REUSEADDR seems to have no effect on this behaviour.)
>

Thanks for looking into this - it gives me some consolation to know
that it's not just my code.

As to why it's being done this way: The real situation is more
complicated than I describe in my orignal post, but there I wanted to
convey the problem without clouding the issue with details.

I have lots of client processes which need to be able to send
datagrams to a server, starting and stopping transmission at the
request of a user. It is possible that many of these clients will be
sending data to the server at once. If these client processes all
send their data to a single port at the server then the server needs
to untangle where these datagrams come from in order for them to be
handled properly.

To avoid this difficulty I have the following scheme: a management
process finds a free port using bind(0), as described in my original
post. It notes the port number and closes the matching socket
descriptor. The management process then communicates the port number
and server name to the client that is required to start sending data,
it also communciates the port number to the server to start receiving
datagrams on. The client then starts sending data to the specified
port on the server and the server starts 'listening' to the specified
port. In this way the server knows that any data received on a
particular port came from a particular client and can thus deal with
it very easily.

This might sound overly complicated but the software project I'm
working on already has the infrastructure in place to make it the
easiest solution.

I'm certain that a lot of people will disagree with this design, but I
don't want to draw attention away from my main issue, which is the
inconsistency in behaviour between kernel-allocated and hand-allocated
ports.

Thanks,

Mark Stevens

Relevant Pages

  • Re: Unable to print to networked printer - get access denied messa
    ... Check the permissions on the server assuming the client has a true RPC ... How is the Standard TCP/IP port configured for the device? ...
    (microsoft.public.windowsxp.print_fax)
  • Re: interfaces lo:1 lo:2 lo:3? (for remote ssh tunnels)
    ... That's the problem tunneling (port forwarding) solves. ... >>can't get past the client firewall. ... > I don't understand why the server would be making the ... server initiates another connection to the client -- in this ...
    (Debian-User)
  • Re: Remote Connection Issue
    ... through port number 3389 and a workstation on the LAN through port number ... I understand that you want to allow a LAN client ... and you have configured server publishing rule ... > By default Terminal Server and Windows 2000 Terminal Services uses TCP ...
    (microsoft.public.windows.server.sbs)
  • Re: RealVNC
    ... Default listening port for RealVNC server that runs on the machine on which ... Then there is default Java listening port on port 5800 on the client machine ...
    (microsoft.public.windows.server.sbs)
  • Re: Redirecting data sent to a local printer to another host and port on the network
    ... All client workstations have access to the ... simply redirecting netcat traffic on port 9100 to port 515 on ... Only LPR clients talk to LPD print server daemons. ... >workstation at the branch site where the print job originated. ...
    (comp.unix.sco.misc)