Vanilla Netrek Server Development Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[VANILLA-L:1046] Re: [VANILLA-L:1014] Client to Metaserver Recoding

Hi, back from holidays... here are my comments.

On Aug 10, 10:50, James Cameron wrote:

>The client will expect to receive a
>reply from each metaserver, and present the resulting merged list to the
>user.

How exactly are you going to merge the lists? I'm asking because the
packet format you propose below doesn't include any timing aspect
(age of information). Different metaservers could give different player
numbers: you have no way to decide which one is the most up to date.

>metaserver to client, UDP packet, from port 3521 to client's port
>
>	"r,count-of-servers\n"
>        "name-of-server,port-number,player-count,queue-size,type\n"
>        "name-of-server,port-number,player-count,queue-size,type\n"
>

>Effect of Packet Loss
>---------------------
>
>If the packet loss is confined to the client side of the network, then
>chances are they won't want to play anyway.
>
>We have three metaservers.  Loss to any one of the three will simply
>cause a two second delay for the client.  Loss to all three would
>indicate a pathological situation that would typically affect the
>client's connection to servers as well.

There's still a (small) chance that that will happen with normal loss also:
suppose 5% random loss to all three metaservers. Then there is a 0.95*0.95
chance that both UDP packets (c->m and m->c) will get through. So chances
that no results come back from _one_ metaserver will be 1-0.95*0.95 = 0.0975.
The chance that there is no result from all three metaservers will be
0.0975**3 = 0.00093 ~= 0.1%. 

As people will probably try to connect two or more times, we can ignore
this possibility I think.


>Effect of Packet Fragmentation
>------------------------------
>
>If the server list grows considerably from it's current size, then the
>UDP reply packet may reach the magic 1460 value that corresponds to the
>10mb/s Ethernet fragmentation point.
>
>When this happens, the chances of packet loss are increased, because
>there are two packets in flight instead of one.

My figures from above become in this situation: 0.95*0.95*0.95 = 0.86
(1-0.86)**3 = 0.0029 ~= 0.3%

Still no big deal.


>Default Behaviour of Clients
>----------------------------
>
>Once we have this working fine on all the metaservers, I'll be proposing
>the patch to the COW list, along with a default to use the new protocol,
>but with a fallback to the old protocol.  This fallback can also be
>forced with a new -M flag.

In addition, I regularly use telnet to connect to the metaserver and I 
suspect many (unix-)people do this too, so that's another reason to keep
the old TCP protocol.

My compliments on your good work, James.

Cheers, Frank

______________________________________________________________________________
Many worlds have now banned their act altogether, sometimes for artistic
reasons, but most commonly because the band's public address system 
contravenes local strategic arms limitations treaties.
	-- Douglas Adams, 'The Restaurant at the End of the Universe'
+
++ Vanilla-l Mailing List ++
To unsubscribe: send "unsubscribe vanilla-l" to majordomo@real-time.com
For more information: http://archives.real-time.com
Follow-Ups: References: