From: fadden@uts.amdahl.com (Andy McFadden)
Newsgroups: rec.games.netrek
Subject: Re: UDP and regions
Date: 7 Apr 92 17:34:27 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <rr5gcINN81j@agate.berkeley.edu> tom@ocf.berkeley.edu (Tom Holub) writes:
>In article <88Im02Q7bf0D00@amdahl.uts.amdahl.com> fadden@xserver.uts.amdahl.com (Andy McFadden) writes:
>)Fat UDP, in its current incarnation, will add at most 100 bytes to packets
>)which are 500 bytes or fewer.  This should not be a major problem.  At any
>)rate, the server diety can adjust the values.  Perhaps a future version will
>)have a way for the client to specify how much fat is acceptable (so people with
>)relatively clean connections can request a "lowfat" connection).
>
>I wasn't referring to the net overload of fat UDP, I was referring to
>the added CPU cycles; if I'm not mistaken, fat UDP sends a whole bunch
>of status information with each packet, and the client must check 
>that the information it receives coincides with what it believes the
>game state is.  I have a feeling that on machines that are only 
>marginally able to handle netrek as it is now, this could be backbreaking.
>I may be wrong.

Well, the discussion started around the load at the server end; if the server
is sending extra information, the only added load is in the client (well, the
server has to do an extra bcopy() and some linked list manipulation).  The
reason for limiting the fat to 100 bytes is as much for CPU load as it is
for network load.

The idea is, when your client starts getting loaded down in a dogfight, the
packet size will increase above some limit (currently 500 bytes).  At this
point fat UDP will effectively turn itself off, so you don't get bogged down.
When you retreat from battle (or re-enter the game) your packet size will be
smaller, so you'll get updates on anything you missed during the battle.

So it shouldn't be TOO backbreaking, and it shouldn't hose you during combat.
Ideally the client would have some control over the amount of fat, but I felt
it was more important to get the code distributed (since I'm tired of working
on it and Tedd & Terence are probably tired of integrating it back into their
clients and servers).  Besides, everybody's getting itchy to have it... :-)

A complete discussion of fat UDP can be found in the UDP_README, which will
be distributed with the server source.  Let me say in passing that only semi-
critical data is repeated (torp STATUS, plasma STATUS, #of kills somebody
has, player flags), and it will be repeated a maximum of five times (this is
also adjustable in the server).  In addition, only some of the packets have
to be compared with the existing data; the rest just overwrite what was
already there (stuff like p_ntorp++ and updatePlayer=1 have to be handled
correctly though).

What WILL affect the server is forced UDP, because it sends commands more
often.  Fortunately it sends them all in a batch right after an update is
received, so it won't be too severe.

Anyway.  I'll distribute it once I get the green light from Tedd and Terence
(hey, knock it off with the experiments!)

> -Mojo

-- 
fadden@uts.amdahl.com (Andy McFadden)
[ Above opinions are mine, Amdahl has nothing to do with them, etc, etc. ]
Newsgroups: rec.games.netrek