I've had a look at the metaserver code just now, at scan.c and
disp_udp.c, and it would be quite simple to adjust that to account for
INL servers.  I made the UDP protocol extensible.

But you mentioned port 3521.  Does the NetrekXP client use the UDP or
TCP connection?  If TCP, then I don't think I'd like to change the
format.  I'd really like Stas to use UDP if he can.  ;-)

To hack it now without changing any code, in the backwards compatible
way, the .metaservers file for the INL server should contain one line
for each port, using a DNS alias.

For example; 3521 60 120 B 2592 2593 open 3521 60 120 B 4566 4000 open 3521 60 120 B 4577 5000 open 3521 60 120 B 4000

We should add a server type for an INL server, and include INL servers
that have solicited in the response to the client.  I'd want to make a
new server side protocol version to include all four ports.  I'd expect
the client developers to accept four ports and figure a way to display

Erik wrote:
>    b) Currently only the player port is listed! 

Yes, that's insufficient.

We didn't design in a protocol version number for the client UDP query,
but there's room; only the first character is checked now and it must be
a question mark.  We could add a version number after that, and have the
later version cause more ports to be listed.

I'm happy to change COW.

> 3) Problem is I have not yet found the point where to put the
>    call to solicit(). How can the server check if it is an INL
>    server? 

(status->gameup & GU_INROBOT)

The flag is set by the INL robot.

>    Which process owns that metaservers[] table? 


>    Should the check be done in deamon (which has the solicit() call),
>    or in netrekd when a player enters?

Daemon.  It won't be running until a player enters.

> Any feedback is appreciated. I am really convinced this is a
> necessary feature to promote clue netrek to midbies who simply
> happen to not be a computer wizard ;-)

I agree.

James Cameron    mailto:quozl at

vanilla-devel mailing list
vanilla-devel at