New COW 3.0pl1 metaserver behavior
Carlos Villalpando
Well, since the new documentation and/or changelog isn't
usually wrapped in together with the binary, and I've already
read some minor confusion on the subject, I've decided to post
the relevant part of the documentation to clarify things.
Some of the information is old hat but a fair amount of the
new behavior is intersperced within. The first part is the
documentation, the last part is the changelog entries for
those curious about the c->s protocol.
--Carlos V.
==============================================================
7.0 MetaServer Options
**************************************************************
The MetaServer and the MetaServerCache are provided to help
you find a netrek game to join. Both services provide a list
of the popular netrek servers. The MetaServer is neat because
provides information on the number of players at each site.
The MetaServerCache is neat because it is much faster if you
can guess where a game will be.
To access the MetaServer, use the command line switch "-m" or
"-M". For example "cow -m". To access the MetaServerCache,
use the "-k" switch instead. The command line options are as
follows:
-m Default to UDP connection mode to metaserver if
metaType not set
-M Default to TCP connection mode to metaserver if
metaType not set
-k use TCP metaserver cache to display known servers
If metaType (defined later) is set, -m or -M will connect to
metaserver based on what metaType is set to.
1) Where to find the MetaServer:
You can use the options "metaport" and "metaserver" to point
COW to a new MetaServer. The defaults for these options are:
metaport: 3521
metaserver: none
The metaserver usually resides at metaserver.netrek.org port
3521
In UDP mode multiple metaservers can be listed on the
"metaserver" option, comma separated. Example:
metaserver: metaserver.netrek.org, metaserver.eu.netrek.org
Also in UDP mode, if a hostname listed has more than 1 IP
address, the client will attempt to connect to all IPs listed
in that hostname. It will then merge all responses into 1 list
and display that list.
In TCP mode, only 1 hostname may be listed.
2) How to create a list of known servers for the
MetaServerCache:
Before you can use the MetaServerCache, you must give COW a
file in which to cache the information from the MetaServer.
Use the .xtrekrc options "metaCache" and "metaUDPcache" to
specify these files. The files path will be relative to your
home directory unless you start the file name with a slash
(/). "metaCache" defines the TCP cache, and "metaUDPcache"
defines the UDP cache. The TCP and UDP cache can NOT be the
same. They are incompatible formats.
For example, to set the cache files to "~/.metaCache" and
"~/.metaUDPcache" use:
metaCache: .metaCache
metaUDPcache: .metaUDPcache
Unlike the MetaServer, the MetaServerCache will not show the
number of people playing at a server. If a server is
contactable, it will be shown as "Active".
Warning: If "metaCache" or "metaUDPcache" are set, COW will
also use a second, temporary file. This file with have the
name of the metaCache file with the last character changed to
either a 'T' or an 'R'. Eg, ".metaCache" becomes ".metaCachT"
and "BEAST" becomes "BEASR". Ensure that this temporary file
does not overwrite something important.
3) How to set the connection type to the metaserver:
The xtrekrc option "metaType" will determine how COW connects
to the metaserver. The default for this option is:
metaType: (default: whaterver the command line has, -m=1
-k=2 -M=3 out of range values default to 3)
where the values 1, 2, 3 are defined as:
How to connect to the Metaserver. Connect with UDP, cache,
or TCP.
1 == cache, then UDP
2 == cache, then TCP
3 == TCP, then cache
UDP mode offers more options and more recent information as
well as a quicker startup and a refresh button, explained
later. TCP mode is the normal method and should be used when
connections are unreliable or if you're behind a firewall.
4) How much information will be shown:
You can now control the amount of information that the
MetaServer displays for you by setting the "metaStatusLevel"
flag. The default is:
metaStatusLevel: 3
The status levels are coded as follows.
0 Servers which have players but not a wait queue.
1 + Servers with a wait queue.
2 + Servers with nobody playing. (see NOTE1).
3 + Servers which have Timed Out for the MetaServer (see
NOTE2).
4 + Servers which the MetaServer has not been able to
connect to.
NOTE1: When using the MetaServerCache, "metaStatusLevel"
values of less than 3 are treated as the value 3. This
minimum is enforced because the cache does not attempt to show
the number of people playing at a site.
NOTE2: If you are a long way from the MetaServer, you are
advised to ignore TimeOut errors. For example, the MetaServer
in America may have difficulty contacting to a server in
Holland while the link from England to Holland is very good.
5) The Fallback
If you attempt to contact the MetaServer, and the connection
times out, COW will try to show the MetaServerCache instead.
Similarly, if you attempt to use the MetaServerCache, and your
"metaCache" file does not exist, COW will attempt to call
theMetaServer.
In UDP mode, COW will show the UDP cache right away, and then
update the screen as responses come in.
6) The display
COW will pop up a window with a list of game servers. The
format of the window is 1 server per line, starting with the
server name, followed by the server status, and the server
type. In UDP mode it will also show the age of the data on
that server. In UDP mode, a refresh button is also available.
Hitting that line will re-query the metaservers for more up to
date data. Please don't abuse this and rapidly click this
button over and over as this may make the metaserver admins
ban you from connecting.
To choose a server to play on, LEFT click on the server. To
join as an observer RIGHT click on the server. COW will then
connect to the game server.
7) Miscellaneous
The option "metaverbose" will make UDP metaserver queries
slightly more verbose. When on, COW will display who its
connecting to and who responds. The default for this option
is:
metaverbose: off
=============================================================
And the changelog entry:
=============================================================
3.00 pl1 Mar. 27, 1999
- Added UDP queries to the metaserver. [cameron, villalpando]
- Added Multiple metaserver support. [cameron, villalpando]
- Metaserver KEYGOD alias: clien...@clientkeys.netrek.org
[villalpando]
- New xtrekrc variables: metaverbose, metaUDPcache, metaType
[cameron,villalpando]
- modified behavior of metaserver to do multiple metaservers
[cameron]
- changed metaserver menu. Added age of data and refresh
button [cameron]
- new option, -M for TCP metaserver [cameron]
- changed option -m for UDP metaserver [cameron]
**************************************************************
March 1999
**************************************************************
(1) ------
Added UDP metaserver, and multiple metaserver queries to
client.
Multiple metaservers is available only in UDP mode.
Multiple metaservers may be listed in the metaservers
variable, or a host name may have multiple IPs.
Client essentially sends a '?' using UDP to the
metaserver(s) and waits for a response. Client should
expect anywhere from 0 to infinite responses. Response
comes back in the form:
r,NN\n
Where r is the literal 'r', and NN is the nuber of servers
returned. Server format is 1 per line in the following
format, comma separated: (from the metaserver code snippet
from disp_udp.c)
sprintf(bp,"%s,%d,%d,%d,%d,%d,%c\n",
sp->hostname, /* host name of server */
sp->port, /* port number of server */
extendedstatus, /* metaserver statuscode */
now - sp->last_update, /* age of data in seconds */
sp->player_count, /* count of players on
server */
sp->queue_size, /* length of wait queue */
sp->type[0] ); /* type code, B, P, etc */
Two notes are required:
1) Line length is defind in the metaserver as:
MAX_HOSTNAME+1 +6+1 +3+1 +6+1 +3+1 +3+1 +1+1 +1
host port stat age play que type \n
where MAX_HOSTNAME is
#define MAX_HOSTNAME 64
An example output is:
r,19
hp06.ee.ualberta.ca,2592,6,244,0,0,P
megalag.netrek.org,2592,4,1780,0,0,F
moore.machine2.dsl.psn.net,2592,6,1804,0,0,B
netrek.unh.edu,2592,6,524,0,0,B
paradise.games.uk.demon.net,2592,6,1604,0,0,P
tanya.ucsd.edu,2592,4,1781,0,0,P
defiant.theo-physik.uni-kiel.de,2592,3,630,0,0,P
europa.informatik.uni-frankfurt.de,2592,3,676,0,0,P
mit.netrek.org,2592,3,676,0,0,B
netrek.cs.mcgill.ca,2592,3,796,0,0,B
netrek.syd.att.net.au,2592,3,800,0,0,B
se.netrek.org,2592,3,864,0,0,B
soda.csua.berkeley.edu,2592,3,878,0,0,B
spamburger.openface.ca,2592,3,871,0,0,B
kirk.hal-pc.org,2592,2,121,1,0,B
continuum.us.netrek.org,2592,2,123,6,0,B
hockey.netrek.org,2592,2,123,6,0,H
monster.wormwood.org,2592,2,203,7,0,C
guinness.crhc.uiuc.edu,2592,1,323,0,4,B
2) In TCP mode, if a game server is dead, the metaserver will
print out sp->why_dead instead of sp->status. Since
metastatuslevel filters out the metaserver output based on
the game server status, sp->status had to be expanded in
the metaserver to extended status when reporting back to
the client. From disp_udp.c in the metaserver:
/* this if structure is to satisfy COW's server filtering
based on */
/* the TCP ouput of the metaserver. TCP was text, this is
only #s */
if (sp->status == SS_NOCONN )
extendedstatus = (sp->why_dead == WD_TIMEOUT) ? 6 : 4;
else
extendedstatus = sp->status;
And in the client, parsemeta.c:
#define SS_WORKING 0
#define SS_QUEUE 1
#define SS_OPEN 2
#define SS_EMPTY 3
#define SS_NOCONN 4
#define SS_INIT 5
/* not a real metaserver number, but overcomes a limitation
of dropping text description of sp->why_dead */
#define SS_TOUT 6
This note is here mainly for people looking at metaserver
and client code at the same time.
(2) ---
A refresh button was added to the client selection window
to re-query the metaservers.
(3) ---
KEYGOD changed to clien...@clientkeys.netrek.org
(4) ---
New command line option behavior was added. -m and -M set
the default connection type to the metaserver UNLESS
metaType is defined in the .xtrekrc.
-m Default to UDP
-M Default to TCP
Out of bounds values for metaType default to TCP.
James Cameron
Are there any comments from people using the new and faster metaserver
query mode in the new client? Do you find it faster?
--
James Cameron (cam...@stl.dec.com)
OpenVMS, Linux, Firewalls, Software Engineering, CGI, HTTP, X, C, FORTH,
COBOL, BASIC, DCL, csh, bash, ksh, sh, Electronics, Microcontrollers,
Disability Engineering, Netrek, Bicycles, Pedant, Farming, Home Control,
Remote Area Power, Greek Scholar, Tenor Vocalist, Church Sound, Husband.
"Specialisation is for insects." -- Robert Heinlein.
Nicolas Blais
What new query mode? Is that a compile time option?
--
Nicolas Blais nicb...@videotron.ca
Powered by FreeBSD http://www.freebsd.org
My current running version : FreeBSD 3.1-RELEASE
http://pages.infinit.net/primary
Carlos Villalpando
nicb...@videotron.ca says...
> James Cameron wrote:
> >
> > Thanks for that, Carlos.
> >
> > Are there any comments from people using the new and faster metaserver
> > query mode in the new client? Do you find it faster?
>
>
Its new behavior introduced in COW 3.00pl1 No new information
comes across, just how it gets sent. The real advantage from
the client's point of view is the multiple-metaserver query.
See article at the head of this thread. Its message id is:
<MPG.119c27b48...@news.earthlink.net>
Or just search Dejanews, erm, Uhh. Deja (why did they change
their name? The old one was cool.) And search on my e-mail
address. unbe...@earthlink.net It should be easy to find as
I don't post very often. Deja split it to 3 parts, though.
Click "get all parts" link to see it all at once.
--Carlos V.
vlo...@canada.com
unbe...@earthlink.net (Carlos Villalpando) wrote:
> Or just search Dejanews, erm, Uhh. Deja (why did they change
> their name? The old one was cool.
Probably to force people to see an extra layer of ads before they can
get to the good stuff. Speaking of good stuff, I just discovered I can
retrieve POP mail at deja - pretty cool since I can't access my POP
mail from work any other way (that I know of). And since I don't do
anything at work except surf the net and post to r.g.n., POP access is
going to be really handy.
> And search on my e-mail address. unbe...@earthlink.net It should be
> easy to find as I don't post very often.
Searching on vlouie is also an interesting excersize.
--
Bozo
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Michael Bain
Nicolas> James Cameron wrote:
>>
>> Thanks for that, Carlos.
>>
>> Are there any comments from people using the new and faster metaserver
>> query mode in the new client? Do you find it faster?
>>
Nicolas> What new query mode? Is that a compile time option?
I find it slower. Most of the time it first comes up with no entries
and I have to hit the refresh key. Could this be a name server
problem?
--
Michael Bain System Functional Test Application Support
michae...@boeing.com Seattle
Linux system uptime: 165 days and counting ...
Steve Sheldon
>>>>>> "Nicolas" == Nicolas Blais <nicb...@videotron.ca> writes:
>Nicolas> James Cameron wrote:
>>>
>>> Thanks for that, Carlos.
>>>
>>> Are there any comments from people using the new and faster metaserver
>>> query mode in the new client? Do you find it faster?
>>>
>Nicolas> What new query mode? Is that a compile time option?
>I find it slower. Most of the time it first comes up with no entries
>and I have to hit the refresh key. Could this be a name server
>problem?
Hmm, I have noticed that at any given time at least one metaserver seems to
be nonfunctional.
But I thought the goal of the new query mode was to hit multiple servers
and give you combined results. So you should be getting at least something.
Or so the theory goes...
--
Steve Sheldon email: she...@yuck.net
BSCS/MCP url: http://www.sheldon.visi.com
a tuber
for asking, but just why is it that my client (Cow2.02) always shows
two entries for continuum on the metaserver list?
It's not too annoying because there aren't that many games nowdays,
but I thought I'd ask.
-Dan Damouth
--
Joss Whedon: "As far as I'm concerned, the first episode of BUFFY
was the beginning of my career. It was the first time I told a
story from start to finish the way I wanted."
Carlos Villalpando
she...@visi.com says...
> Michael Bain <michae...@boeing.com> writes:
>
> > James Cameron wrote:
> >>
> >> Thanks for that, Carlos.
> >>
> >> Are there any comments from people using the new and faster metaserver
> >> query mode in the new client? Do you find it faster?
> >>
> >and I have to hit the refresh key. Could this be a name server
> >problem?
Define a metaUDPcache in your .xtrekrc/.netrekrc for an
instantaneous list before the metaservers respond.
Example:
metaUDPcache: .metaUDPcache
The way it is set up now is that it displays the cache, if
any, sends off queries to the metas, gets responses, and
displays whatever responses it gets. Once a second, it checks
for new responses. At least that is how it works under X
boxes. Haven't tried a Win95/98 box yet.
I notice you said "Most of the time" Probably because on
occasion, whatever meta you are querying responds quicker than
the initial 1 second timeout to wait for initial responses.
Most of the time for you its not, apparently. Slowish link?
> Hmm, I have noticed that at any given time at least one metaserver seems to
> be nonfunctional.
Spout off to the metaserver admins when you notice one down.
We had a minor problem with 1 uncaught bug in one server 2
weeks ago, and my server has a watchdog on it to re-start it
if it dies.
If you're in UDP mode, defining:
metaverbose: on
Will tell you who was queried and who responded.
> But I thought the goal of the new query mode was to hit multiple servers
> and give you combined results. So you should be getting at least something.
It will hit multiple servers if you list multiple servers, or
a hostname has multiple IP addresses, or both.
Example, since metaserver.netrek.org resolves to both
metaserver.us.netrek.org and metaserver2.us.netrek.org, the
metaserver lines:
metaserver: metaserver.netrek.org
and
metaserver: metaserver.us.netrek.org,metaserver2.us.netrek.org
are equivalent in UDP mode.
The line:
metaserver: metaserver.netrek.org, metaserver.eu.netrek.org
Will hit all 3. Defining metaserver.netrek.org and either or
both of metaserver.us and metaserver2.us is redudnant and will
irk us. *grin*
--Carlos V.
Carlos Villalpando
ntco...@heron.eecs.umich.edu says...
> Um, speaking of the metaserver. I realize this is a little late
> for asking, but just why is it that my client (Cow2.02) always shows
> two entries for continuum on the metaserver list?
Longish story. Well, not really, but you might get bored.
The short answer:
It has to do with the solicit code and continuum being a
multiple-homed machine.
The long answer:
The solicit code in the metaserver checks the from_addr in the
IP header received for a solicit update from a server to do a
simple sanity check to prevent spoofing. If the headers don't
match, the metaserver assumes it is a new server and will
create a new entry.
Regardless of who it gets solicit updates from, the metaserver
will continue to query servers it hasn't checked on or heard
from according to when it last checked on it/heard from it and
its last known status.
Continuum runs on a multiple-homed machine.
continuum.us.netrek.org resolves to the secondary interface on
the machine. The default route out of the machine comes out
the primary interface (different IP address). So any new
connections that originate from continuum have the address of
the primary interface slapped on them. We haven't figured out
how to force the intial connection to bind to the secondary
interface.
Now the reason why there are 2 entries: The metaserver knows
continuum by its secondary interface, and continuum is sending
solicits by its primary interface. They'll never match.
Solutions:
1) Force the solicits to bind to the secondary interface:
Haven't figured it out at the socket call level and we are
unwilling to add explicit routes to the routing table.
2) Change the metaserver rc file to point to the primary
interface:
Tanner has requested that we leave it at its current IP
address as the primary IP address of the machine may go
away and he can assign the secondary IP address to any
other machien without too much disruption.
3) "Well, continuum solicits, you don't have to list it
explicitly in the metaserver's .rc files!"
Well, yes. But Tanner has been swamped with work and has
yet to apply a recent patch to add an RSA flag to the
metaserver solicits. Quite a few clients depend on that
flag to connect properly. Once that patch is installed, It
is reasonable to remove the explicit listing. It isn't
critical, and he has real work to do. Cameron, willing to
help?
Hope that doesn't over-explain things.
--Carlos V.
Michael Bain
Carlos> In article <dz103.1201$cG.1...@ptah.visi.com>,
Carlos> she...@visi.com says...
>> Michael Bain <michae...@boeing.com> writes:
>>
>> > James Cameron wrote:
>> >>
>> >> Thanks for that, Carlos.
>> >>
>> >> Are there any comments from people using the new and faster metaserver
>> >> query mode in the new client? Do you find it faster?
>> >>
>> >I find it slower. Most of the time it first comes up with no entries
>> >and I have to hit the refresh key. Could this be a name server
>> >problem?
Carlos> I notice you said "Most of the time" Probably because on
Carlos> occasion, whatever meta you are querying responds quicker than
Carlos> the initial 1 second timeout to wait for initial responses.
Carlos> Most of the time for you its not, apparently. Slowish link?
Most of the time there are no entries. I'll use your suggested mods
to my .xtrekrc file and see if that improves things.
I believe that when I do get entries, it is when another copy of COW
is already running. Sounds like my cache must be disappearing after
my COW client quits?
This might be a COW problem, but I've had a lot of problems connecting
to servers. Recently, I've commented out the password field in my
.xtrekrc and it seems to be more successful. A problem with the
autologin sequence?
--
Michael Bain System Functional Test Application Support
michae...@boeing.com Seattle
Linux system uptime: 167 days and counting ...
James Cameron
> I find it slower. Most of the time it first comes up with no entries
> and I have to hit the refresh key. Could this be a name server
> problem?
Hmm. Since you run Linux, could you do the following please?
# test the time taken to do the metaserver host name lookups
time host metaserver.us.netrek.org
time host metaserver.eu.netrek.org
# test the time taken for an ordinary TCP query of the metaserver
time telnet metaserver.us.netrek.org 3521
The new code is COW has a verbose mode. Enable it with
metaverbose: 1
in your .xtrekrc file and watch the output. The sequence of operations,
defined in parsemeta.c, is a name server lookup, then a transmission of
a UDP packet, then a delay while it waits for a response. Since you run
Linux, you may wish to use "tcpdump port 3521" to see the packets.
It is strange that the list appears empty first time. This wasn't my
intention. Give it a try with an empty 'rc file too.
--
James Cameron (qu...@us.netrek.org)
Linux, Firewalls, OpenVMS, Software Engineering, CGI, HTTP, X, C, FORTH,
James Cameron
James Cameron
> 3) "Well, continuum solicits, you don't have to list it
> explicitly in the metaserver's .rc files!"
>
> Well, yes. But Tanner has been swamped with work and has
> yet to apply a recent patch to add an RSA flag to the
> metaserver solicits. Quite a few clients depend on that
> flag to connect properly. Once that patch is installed, It
> is reasonable to remove the explicit listing. It isn't
> critical, and he has real work to do. Cameron, willing to
> help?
It's my job, I'll fix it.
[short delay]
Right, I've fixed it ... though the server will have to die a natural
death before the new simulation process is put into place.