Menu
▾
▴
Network update status
|
From: Frank S. <fm...@th...> - 2000-12-13 01:36:35
|
I am sorry but for now I cannot put all this into a library as I build it
into the ServerLink. The code itself is quite structured and I think later it
could be embedded into such a library, but for the time being it is monolithic.
Right now I have embedded the changed mostly in
include/Protocol.h - New Messages to establish an UPD up and downlink
src/bzflag/playing.cxx - minor changes for the new messages
src/bzflag/ServerLink.cxx - all new send and receive stuff in herein
src/bzflag/PlayerLink.cxx - minor changes
src/bzfs/bzfs.cxx - also all new send and receive stuff herein
(unfortunately most code is here in 'dual'
because the current bzfs implementation makes
it hard to put the new stuff into a common
library)
The method is that the client creates a UPD receive port (bound to a socket)
upon entering the game and sends a MsgUDPLinkRequest message containing the
client port number to the server.
The server will log the remote port and establishes an own receive port for
each client. To make BZFlag more Firewall-happy ports are created beginning at
17200 upward (depending on the availability higher numbers are used). The
server now sends a MsgUDPLinkGranted back to the client also containing now
the server port number where it is listening for the incoming UDP traffic.
Up to this point not a single UDP packet has traveled, all communication is
done strictly over the old TCP link. This link is always established 'side-by-
side' to the new UDP link and can be used as alternate (however it won't in
the current implemenation).
With the receipt of the MsgUDPLinkGranted message the client will transmit
over the UDP link, also the server will transmit to the client over this link
now, the MsgUDPLinkGranted is always the last message you will see from a
TCP server link.
The way of transmitting is quite elaborated as we must not assume that it will
reach their destination. I have worked out some kind of way I called BZAEP
(BZFlag Advanced Escalating Protocol - the baby was in need of a name and it
sound so nice as spoken as 'b-zap'). This protocol will grant that each packet
will reach its destination, in time, in order and correctly while not needed
any form of direct acknowledge. Early Test have shown that
- it won't block anymore for any reason, there are no timers or waits
in the protocol.
- Tank movement is very smooth and snappy.
- it can live with a 75% packet drop rate, however movement of a tank
will get quite jerky. Up to 15% drop rate (loss of packets during flow)
the games goes on without much effect. Higher drop rates won't affect
other players but the affected player world tend to go out of sync as
the updates will be received a bit late.
- it can (optional) compress the data (right now I use LZO which is mighty
fast and GPL), so the protocol may need actually much less bandwidth
than the old method. However bandwidth is usually not an issue with BZFlag
and the protocol it not tuned to minimize it. It is however tuned to
minimize latency.
- it is self stabilizing and healing, so a temporary glitch in the link
is automatically repaired as soon as the link quality goes up again.
- it has a direct measure of the network link quality and will reliable
find if a connection has dropped by itself. This network quality metric
is implemented for both ends, so a server can always determine how 'good'
a client is and a client can do likewise. No timing packets or ping packets
are needed for this - is part of the protocol.
What I need to do is now to test it in a larger network area. The packet drop
right now were forced upon a ISDN 64k Link by deliberately droping packets.
Also I have only tried with three clients yet (the current implementation is
on SGI/IRIX and that is the number of SGIs I have at my disposal)
These tests will be conducted in the next days. I will keep you posted on the
development.
- Frank "Onkel Frank"
|
