Thread: [Opentnl-general] Two issues related with GhostConnection.
Brought to you by:
mark_frohnmayer,
s_alanet
From: Norbert H. <nh...@gm...> - 2004-05-23 18:53:44
|
Hi. First of all, thank you GarageGames, for putting TNL under GPL. I have spent the last two days working around with it. This is really a fine piece of code. I tried to compile TNL & Zap with Metrowerks CodeWarrior 8. I had to make a couple adjustments (maybe more to that in another e-mail), but in the end, Zap seemed to run fine. However the TNLTest didn't work. I tracked down two issues. I am not completely sure if the description below is 100% correct, so it would be great if somebody could look into to verify it: Bug #1: When TNLTest is started as a client, GhostConnection::mGhostZeroUpdateIndex is never properly initialised. The VC++ DEBUG build initialises it to a non-zero default value of 0xcdcdcdcd for example. Now, somewhere down the road, the method NetConnection::checkPacketSend() uses the isDataToTransmit() to check if a package should be sent. This is however always the case, since GhostConnection::isDataToTransmit() checks if mGhostZeroUpdateIndex != 0. This leads to empty packages (besides header) being sent all the time. The weird thing is, that this covers a second bug, which makes the app just run fine when built with VC++. I noticed this, because CodeWarrior initialises mGhostZeroUpdateIndex to 0 instead of 0xcdcdcdcd. So it 'unfortunately' (read below, why) behaved correctly. Bug #2: Now, let's say mGhostZeroUpdateIndex is correctly initialised to 0 and no further empty packages are being sent. However, the only time the TNLTest client sends a package to the server is when the user sets a new position of his player, (rpcSetPlayerPos() and rpcPlayerWillMove() is called). So if the user doesn't do anything, there are no packages sent at all, and no ACK's are ever sent back to the server. When I turn on the LogConnectionProtocol logging, I see that no Notifies are received by the server. I think this causes the server to stop sending packages after a short time. This was not a problem up to now, because the empty packages carried the ACKs in their header. The behaviour can also be observed when making a release build of TNLTest with VC++ (where mGhostZeroUpdateIndex = 0). I guess the solution would be to also check on pending Notfies in isDataToTransmit(). I am not sure though. I have barely understood the underlaying network mechanisms. Thanks, Norbert. |
From: Mark F. <ma...@ga...> - 2004-05-24 19:09:13
|
Norbert Harrer wrote: >This was not a problem up to now, because the empty packages carried >the ACKs in their header. The behaviour can also be observed when >making a release build of TNLTest with VC++ (where >mGhostZeroUpdateIndex = 0). > >I guess the solution would be to also check on pending Notfies in >isDataToTransmit(). I am not sure though. I have barely understood the >underlaying network mechanisms. > > >Thanks, >Norbert. > > Hey Norbert - good find! I actually have this on my short list as "figure out isDataToTransmit() bug" - I ran into the same thing on a release build of Zap, but fixed it by putting an override function in GameConnection. I'll take a look at the code. * Later * GhostConnection::setGhostFrom initializes mGhostZeroUpdateIndex, but this only happens if that side of the connection is sending ghost updates. So your analysis was correct - the client is never sending packets back to the server since has an empty event queue and the ghostZeroUpdateIndex is 0. The solution that I will implement is to have the NetConnection also send packets - Ack packets, if it has received packets that it has not sent acknowledgements for. This will not advance the window on the clients, since Ack packets don't use a new sequence number, but it will allow the server to send new packets. This should not be a part of isDataToTransmit, however, since that would create a new data packet - which would need to be ack'd by the server. - Mark |
From: Mark F. <ma...@ga...> - 2004-05-27 17:24:35
|
> GhostConnection::setGhostFrom initializes mGhostZeroUpdateIndex, but > this only happens if that side of the connection is sending ghost > updates. So your analysis was correct - the client is never sending > packets back to the server since has an empty event queue and the > ghostZeroUpdateIndex is 0. The solution that I will implement is to > have the NetConnection also send packets - Ack packets, if it has > received packets that it has not sent acknowledgements for. This will > not advance the window on the clients, since Ack packets don't use a > new sequence number, but it will allow the server to send new > packets. This should not be a part of isDataToTransmit, however, > since that would create a new data packet - which would need to be > ack'd by the server. > > - Mark > Ok, I checked in the fix for this. There were actually two bugs - one was the window filling bug, and one was an unsigned integer underflow comparison issue. Both have been fixed. - Mark |