Re: DO broadcast

[Tobias]

> We also thought about having a name server, but we can't rely on always
> having a name server on the local network.
> What happens if the current server disapears ? Which host should become
> the new name server ? How will the new name server know the games that
> were registered before the old one disapeared ? What if a malicious user
> try to start a second name server to hide the current ?

this is addressed with multicast dns [1] + dns service discovery [2] (all 
together in rendezvous and zeroconf [3]). there each host has one (m)dns 
server. mdns traffic should NOT be routed, so this may not work in large 
networks (as the internet), but DO notifications should not either imo, 
gnustep sends notifications as broadcast, afaik. (correct me if im wrong 
(which i hope ;))

you can take the gpl+bsd licensed mdns daemon at dotlocal.org and advertise 
your service with that.
(you will have to change your code to look for services then, but you could 
still alter gnustep's notification system to use this ;-))

> Of course some of these problems could have solutions like establishing
> a protocol for the election of the name server (like, if there is no
> name server, wait for a random time, if there is still no server, start
> one), and each games could send a message every minute to register
> themselves to the current name server (a timeout would means that the
> current one is dead). But these adds a lots of complexity, and i'm not
> sure how well they would practicaly work.

this is unneccessary network traffic + unneccessary load on the server. i 
think, this should ALWAYS be avoided.


> It seems to be the very same problem for notifications how could we be
> sure there will always be a gdnc (and only one) configured as a
> network-wide server ?

you cannot rely on this.

1 http://www.multicastdns.org/
2 http://www.dns-sd.org/
3 http://www.zeroconf.org/

regards,
~ibotty