Hi,

I have daemon which responds to UDP broadcasts for the purpose of doing
automatic server discovery. Once a client finds out which host respond to
their broadcasts they will communicate with a TCP server on the same host.
This saves the user from entering the specific server name which is all
fine.

However in some cases there might be two or more servers running on the same
host. The system admin will then configure the TCP servers to run on each
their port. The clients are also capable of connecting to a server on a
non-standard port.
However if the port of the UDP server changes the broadcast clients will not
be able to get a response anymore.
This is due to the fact that a specific UDP broadcast requests is sent to
(255.255.255.255, port).

Is it possible to reliably force SO_REUSEADDR for each server and set both
of them up to use the same known port?

Thanks.

-- Henrik

[ Post a follow-up to this message ]

Henrik Goldman wrote:
> I have daemon which responds to UDP broadcasts for the purpose of doing
> automatic server discovery. Once a client finds out which host respond to
> their broadcasts they will communicate with a TCP server on the same host.
> This saves the user from entering the specific server name which is all
> fine.
>
> However in some cases there might be two or more servers running on the sa
me
> host.

[snip]

> Is it possible to reliably force SO_REUSEADDR for each server and set both
> of them up to use the same known port?

Hi Henrik

As far as I know it's not possible, and it wouldn't make a lot of sense
if it was.

You can listen on the network interface using libpcap (which is
independent of the socket layer) and do your own UDP parsing, but that's
not really a very good idea either.

I'd suggest you use some already existing discovery service such as
ZeroConf. Avahi (http://avahi.org/) is an Open Source implementation,
but there are more both open-source and commercial ZeroConf stacks. If
your OS is reasonably new, it probably comes with one already.

Greetings,
Aaron

[ Post a follow-up to this message ]

Henrik Goldman <henrik_goldman@mail.tele.dk> wrote:
> Is it possible to reliably force SO_REUSEADDR for each server and
> set both of them up to use the same known port?

Issues like that for UDP came-up when IP multicast was invented.  IIRC
the solution/workaround was the addition of the SO_REUSEPORT
setsockopt() call.  For UDP only, not TCP of course...  I suspect the
Stevens Fenner and Rudoff Unix Network programming text goes into it
in some detail as might Stallings.

rick jones
--
a wide gulf separates "what if" from "if only"
these opinions are mine, all mine; HP might not want them anyway... 
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[ Post a follow-up to this message ]

> Issues like that for UDP came-up when IP multicast was invented.  IIRC
> the solution/workaround was the addition of the SO_REUSEPORT
> setsockopt() call.  For UDP only, not TCP of course...  I suspect the
> Stevens Fenner and Rudoff Unix Network programming text goes into it
> in some detail as might Stallings.
>
I've been trying to do some researching of SO_REUSEPORT and it seems that
does not all OS's has this flag.

Windows for instance does not have it whereas it exist on many others.

I guess it's something which is not widely used.

-- Henrik

[ Post a follow-up to this message ]

On Feb 12, 7:49 am, "Henrik Goldman" <henrik_gold...@mail.tele.dk>
wrote:

> However in some cases there might be two or more servers running on the sa
me
> host. The system admin will then configure the TCP servers to run on each
> their port. The clients are also capable of connecting to a server on a
> non-standard port.
> However if the port of the UDP server changes the broadcast clients will n
ot
> be able to get a response anymore.
> This is due to the fact that a specific UDP broadcast requests is sent to
> (255.255.255.255, port).
>
> Is it possible to reliably force SO_REUSEADDR for each server and set both
> of them up to use the same known port?

Yes, however exactly how you do it may vary from platform to platform.
You want to use SO_REUSEPORT where that option exists.

DS

[ Post a follow-up to this message ]

Henrik Goldman wrote:
> I have daemon which responds to UDP broadcasts for the purpose of doing
> automatic server discovery. Once a client finds out which host respond to
> their broadcasts they will communicate with a TCP server on the same host.
> This saves the user from entering the specific server name which is all
> fine.

What about changing the process that listens on the UDP port into a sort
of generic "server location service" so that the two TCP servers can
send UDP packets signalling that they are listening (or no longer listening)
on whatever ports and IP addresses?

Then clients could broadcast to the same port and get a list of all the
servers running on that host.

- Logan

[ Post a follow-up to this message ]

> What about changing the process that listens on the UDP port into a sort
> of generic "server location service" so that the two TCP servers can
> send UDP packets signalling that they are listening (or no longer
> listening)
> on whatever ports and IP addresses?
>
> Then clients could broadcast to the same port and get a list of all the
> servers running on that host.

In an ideal world I'd certainly like to do your proposal. However
non-technical things forces me not to use this as an option. One strong
requirement is that people must say it's easy to use and not say it's too
hard to install two services instead of one. It's only a question of
business competition and position on the market. If people get a easier
alternative it relates to lost sales for this reason.

I agree with you though that it's by far the best one.

-- Henrik

[ Post a follow-up to this message ]

"Henrik Goldman" <henrik_goldman@mail.tele.dk> wrote in message
news:45d1d063$0$908$edfadb0f@dread12.news.tele.dk... 
>
> In an ideal world I'd certainly like to do your proposal. However
> non-technical things forces me not to use this as an option. One strong
> requirement is that people must say it's easy to use and not say it's too
> hard to install two services instead of one. [...]

Couldn't you build the functionality into the existing daemon? Probably the
simplest way would be to fork (twice, probably) if you succeed in binding
the UDP socket, and have the (grand)child become the "server location
service". The obvious problem with this approach is discovery stops working
forever if the service dies.

Alternatively, maybe something like the following would work. Periodically
create a UDP socket and try to bind it to the discovery port. If bind()
fails, send a message to the discovery port saying "I am a server listening
on TCP port X." If it succeeds, in addition to responding to discovery
messages, handle the "I am a server" messages: add the server to a list with
a timeout that is greater than the period between bind attempts. When you
receive a discovery message, purge expired entries from the list then send
the list (plus your own TCP port). This approach is not perfect - for
instance, it creates a "hiccup" in server discovery if the server with the
UDP socket exits or dies. There are probably issues I didn't think of; if
so, perhaps someone else will point them out.

Alex

[ Post a follow-up to this message ]

> Yes, however exactly how you do it may vary from platform to platform.
> You want to use SO_REUSEPORT where that option exists.
>

I found that on most platforms SO_REUSEADDR works perfectly fine. In fact
many platforms does not have SO_REUSEPORT.
The only platform which SO_REUSEPORT was specifically needed was on HP-UX.

In any case using both flags where available works out fine.

-- Henrik

[ Post a follow-up to this message ]