On Thu, Feb 23, 2006 at 03:00:46PM +1000, Stephen Thorne wrote:
> I forsee the LAN multicast discovery being nice. Can you provide a
> short description of how it works (what port, what protocol, etc)

Multicast Server Discovery
by James Cameron <quozl at us.netrek.org>


The multicast server discovery feature was added to the Vanilla server
in 2.10.2 and the COW client in 3.2.0 and allows clients to discover
nearby servers.

The information here is subject to change, see the source code for the
current behaviour.


Protocol
--------

Server discovery is done using a multicast UDP query on port 3521, and
is an extension to the metaserver query and response protocol.
Multicast UDP is done by sending a packet to the IP address 224.0.0.1.

The sequence of events is:

1.  the metaserver listens for client queries.

2.  the server listens for client queries.

3.  each client sends a metaserver query, to the listed metaservers
    and also to nearby servers using multicast.

4.  the metaservers receive the query and send back a packet (or
    series of packets) listing the servers that it knows.  The reply
    is directly to the client, and the client merges replies from all
    metaservers.

5.  the server receives the query and sends back a packet about itself.
    The reply is directly to the client.

6.  the client lists all the servers and the local servers on the
    metaserver window.  This is done slightly asynchronously, so that
    the window will show information as it becomes available.

7.  if the user presses the refresh button, steps 3 to 6 repeat.

8.  if the user selects a server, play begins in the usual fashion as
    if the user had typed "netrek -h server".


Packet Format
-------------

The query packet is a single question mark.  This is the same as that
sent by the client to a metaserver.

The reply packet from a server is a series of comma separated text
fields, as follows:

- s, the literal lowercase "s" character, marking this as a server
  reply (as opposed to a metaserver reply),

- type, the type of server, such as "B" for Bronco, same meaning as
  the metaserver reply,

- comment, the text from the server's comment file, which is to be
  shown on the metaserver window,

- ports, the integer number of ports to follow in the message, (each
  port takes three fields),

- port, the port number to contact the server on to play, (the IP
  address is assumed to be the address from which this reply came),

- players, the number of players currently playing who joined on this
  port,

- queue, the number of players waiting on the queue connected to this
  port.

Example: s,B,Test Server,1,2592,0,0 indicates an empty test server.


Other Uses
----------

There are some other uses for the same feature, such as:

- listing specific servers in the client's metaserver list can allow
  the client to query these servers without involving the metaserver.

- the test tool metaget can be used in scripts to query the
  metaserver, a specific server, or all nearby servers.


Configuring Server
------------------

1.  add the 3521u line to ports, as per the sample_ports file, (this
    is done automatically for new servers),

2.  add the file comment in SYSCONFDIR, with a description of your
    server, (this is done automatically for new servers, but the
    default name is "Unnamed Vanilla Server",

3.  restart netrekd,

4.  test with "metaget localhost",

5.  test with "metaget 224.0.0.1".


Configuring Client
------------------

No configuration is necessary.  When the "-m" (metaserver) option is
used, which is the default if no server name is given, the client will
query the metaservers and use multicast discovery.


Implementation
--------------

The netrekd process receives the UDP query packets.  See
newstartd/newstartd.c for the UDP port support.

The netrekd process forks the players program to handle queries.  See
tools/players for the UDP response handler, triggered by the "u"
command line option.

The metaget program demonstrates a way to make a query and receive the
response, emitted to stdout.  It isn't used in a running server unless
a server owner chooses to use it somehow.  See tools/metaget for the
test query program.

See parsemeta.c in the client source for additional details on making
the query and procesisng the responses.


Verification
------------

netrekd adds a line to server log file "log" for each query.

Use "tcpdump -n -s 0 -X udp port 3521" to watch for multicast and
metaserver query and response packets.  For example:

16:51:49.857757 IP 10.0.0.1.40401 > 224.0.0.1.3521: UDP, length 1
        0x0000:  4500 001d 0000 4000 0111 8fce 0a00 0001  E..... at .........
        0x0010:  e000 0001 9dd1 0dc1 0009 2b47 3f00 0000  ..........+G?...
        0x0020:  0000 0000 0000 0000 0000 0000 0000       ..............

16:51:49.859960 IP 10.0.0.3.3521 > 10.0.0.1.40401: UDP, length 38
        0x0000:  4500 0042 000a 4000 4011 269e 0a00 0003  E..B.. at .@.&.....
        0x0010:  0a00 0001 0dc1 9dd1 002e 17a9 732c 422c  ............s,B,
        0x0020:  556e 6e61 6d65 6420 5661 6e69 6c6c 6120  Unnamed.Vanilla.
        0x0030:  5365 7276 6572 2c31 2c32 3539 322c 302c  Server,1,2592,0,
        0x0040:  300a                                     0.


Known Bugs
----------

- doesn't properly handle observer ports for INL servers, but does
  handle the two queues for player ports,


--

-- 
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.us.netrek.org/pipermail/netrek-dev/attachments/20060223/754d1b38/attachment.pgp