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" |