A lot of move updates
by DIAG · in Torque Game Engine · 03/09/2004 (7:31 am) · 15 replies
Hello,
Just a quick question. Ive noticed that event when a player is standing still, it fires out update packets to the server at a constant rate, event though no moves have been made. Is there a particular reason for this, as it seems rather wasteful
Cheers
Just a quick question. Ive noticed that event when a player is standing still, it fires out update packets to the server at a constant rate, event though no moves have been made. Is there a particular reason for this, as it seems rather wasteful
Cheers
#2
03/10/2004 (2:30 am)
Thanks for your reply. would reducing the number of packets have any adverse effects? for example, if one checked for redundant packets. i was thinking that if i made a check to see the the current checksum is the same as the last, and if so, dont send that packet.
#3
You could only do what you said and still keep the routers responsive if truly every X data could be removed. This would cause the number of packets sent in an interval to still be constant.
The solution you propose (of removing all redundant packets) would cause a "non-moving" character packets to not be sent and would cause the network to be un-responsive when you did move.
But if you don't believe it, alter the code yourself to proof it.
But maybe we can get to your "need". It seems that you want to remove the packets as a solution to some problem and not just because it seems like a good idea. Are you finding issues in network play in the game you are working on? If so what is it?
Maybe someone can help you with that.
03/10/2004 (4:50 am)
Diag,You could only do what you said and still keep the routers responsive if truly every X data could be removed. This would cause the number of packets sent in an interval to still be constant.
The solution you propose (of removing all redundant packets) would cause a "non-moving" character packets to not be sent and would cause the network to be un-responsive when you did move.
But if you don't believe it, alter the code yourself to proof it.
But maybe we can get to your "need". It seems that you want to remove the packets as a solution to some problem and not just because it seems like a good idea. Are you finding issues in network play in the game you are working on? If so what is it?
Maybe someone can help you with that.
#4
thanks for your reply. Im using torque as part of a research project in university. basically, im looking to implement methods of dealing with latency in networked games, mostly through methods that help to reduce the number of packets sent, and use modelling in between packets.
I was just looking at the code, and noticed that the update rate of the moves was fairly high, and alot were very similiar. so i thought the best place to start would be the reduction of redundant packets.
Thanks again
03/10/2004 (5:01 am)
Hey,thanks for your reply. Im using torque as part of a research project in university. basically, im looking to implement methods of dealing with latency in networked games, mostly through methods that help to reduce the number of packets sent, and use modelling in between packets.
I was just looking at the code, and noticed that the update rate of the moves was fairly high, and alot were very similiar. so i thought the best place to start would be the reduction of redundant packets.
Thanks again
#5
Very interesting! Any chance your results will be posted or enhancements Given to GG to be rolled into Torque? Would be nice to have a "scientific" answer to some of the questions about the network code, such as performance vs # of users, speed of network, etc.
03/10/2004 (9:56 am)
DIAG,Very interesting! Any chance your results will be posted or enhancements Given to GG to be rolled into Torque? Would be nice to have a "scientific" answer to some of the questions about the network code, such as performance vs # of users, speed of network, etc.
#7
03/10/2004 (3:38 pm)
One thing that I've done is to check up in the move->pack() function if the move is a NullMove, if yes it only writes one bit, otherwise write the movement data.
#8
'
If you wait a bit for TNL to come out you can also play with some interesting adaptive rate code that does essentially just this.
03/10/2004 (3:42 pm)
Interesting thought. You may have good luck doing the checksum trick and simply reducing the rate of packet transmission.'
If you wait a bit for TNL to come out you can also play with some interesting adaptive rate code that does essentially just this.
#9
03/10/2004 (4:35 pm)
If there was someway to mark an object as stationary, and then remark it as movable, and if it got fewer or no updates while it was marked this way, this could be useful.
#10
03/10/2004 (7:51 pm)
Already in there. Check out updatemasks.
#11
thanks for your posts guys. i tried out that redundant check sum check. on the most part it works, and ive set up code where this data is not written to the packet. it dosent work all the time however. ive noticed that sometimes when im am standing still doing nothing, the checksum differs from the last one, and other times it is the exact same. any ideas?
cheers
[
03/11/2004 (2:18 am)
Hey,thanks for your posts guys. i tried out that redundant check sum check. on the most part it works, and ive set up code where this data is not written to the packet. it dosent work all the time however. ive noticed that sometimes when im am standing still doing nothing, the checksum differs from the last one, and other times it is the exact same. any ideas?
cheers
[
#12
I was just going through my old posts, and found this one again. Sorry for resurrecting this very old post, but I just have a question regarding what Ben said here:
"Actually, it's done to keep bandwidth usage constant. That way when you _do_ start really moving, it will be responsive, rather than there being a pause as routers and packet flows get adjusted for the data to get through."
In the current day internet, is there really going to be that much of an extra delay? If so, what might the delay be caused by, and how signficant might it be? I've tried looking at info such as route cache invalidation timeouts, and they seem to be pretty large!
Cheers,
Damien
12/05/2007 (11:18 am)
Hi guys,I was just going through my old posts, and found this one again. Sorry for resurrecting this very old post, but I just have a question regarding what Ben said here:
"Actually, it's done to keep bandwidth usage constant. That way when you _do_ start really moving, it will be responsive, rather than there being a pause as routers and packet flows get adjusted for the data to get through."
In the current day internet, is there really going to be that much of an extra delay? If so, what might the delay be caused by, and how signficant might it be? I've tried looking at info such as route cache invalidation timeouts, and they seem to be pretty large!
Cheers,
Damien
#13
If you check out games like Warcraft and Everquest you can see the delays using the above mentioned test. It's quite funny actually. No matter how optimized your entwork code is, when a source and a destination start communicating in TCPip there is an initial "handshake" bunch of packets that pop between the 2 of them. By keeping the datastream constant (or at least open) you eliminate that initial handshake delay.. Sure we are only talking miliseconds but when you add in latency and whatnot the results are clear.
I think that just sending the "ping" type packets to keep the stream alive rather than the updates would be just as effective in keeping the stream open and responsive but I havent done any work with the datastream in ages so you'd want to get a second and third opinion on that :)
Good luck in your work.
12/05/2007 (1:42 pm)
The delay can be significant, although not game breaking generally.. It is quite apparant if you play 2 computers side by each on 2 completely different service provider connections (IS make sure they are completely different backbones so the IP egments are spread waay out. 2 IPs on different segments from the same ISP will still get rerouted at the ISPs router and not have to hit the actuall backbone which wont be a true test of a working environment.If you check out games like Warcraft and Everquest you can see the delays using the above mentioned test. It's quite funny actually. No matter how optimized your entwork code is, when a source and a destination start communicating in TCPip there is an initial "handshake" bunch of packets that pop between the 2 of them. By keeping the datastream constant (or at least open) you eliminate that initial handshake delay.. Sure we are only talking miliseconds but when you add in latency and whatnot the results are clear.
I think that just sending the "ping" type packets to keep the stream alive rather than the updates would be just as effective in keeping the stream open and responsive but I havent done any work with the datastream in ages so you'd want to get a second and third opinion on that :)
Good luck in your work.
#14
I can see now the effect the initial connection negotiation in TCP would have on delay.
Would there be the same effect with UDP packets i.e. would the first packet in a flow of packets be delayed more than subsequent packets (assuming that the packets are transmitted are regular intervals following the first packet)? As there is no handshaking with UDP, I can't immediately see how this would occur with UDP. Is there some network level issue I'm missing out on with UDP flows?
Cheers
Damien
12/06/2007 (2:07 am)
Thanks for your reply. Very helpful.I can see now the effect the initial connection negotiation in TCP would have on delay.
Would there be the same effect with UDP packets i.e. would the first packet in a flow of packets be delayed more than subsequent packets (assuming that the packets are transmitted are regular intervals following the first packet)? As there is no handshaking with UDP, I can't immediately see how this would occur with UDP. Is there some network level issue I'm missing out on with UDP flows?
Cheers
Damien
#15
I can see now the effect the initial connection negotiation in TCP would have on delay.
Would there be the same effect with UDP packets i.e. would the first packet in a flow of packets be delayed more than subsequent packets (assuming that the packets are transmitted are regular intervals following the first packet)? As there is no handshaking with UDP, I can't immediately see how this would occur with UDP. Is there some network level issue I'm missing out on with UDP flows?
Edit: Just had a thought there - I was under the impression that Warcraft et al. used a central server approach. Why would there be handshaking between two clients connected to the server? Surely the server would send the extra data along the existing connections to the server in this case?
Cheers
Damien
12/06/2007 (2:37 am)
Thanks for your reply. Very helpful.I can see now the effect the initial connection negotiation in TCP would have on delay.
Would there be the same effect with UDP packets i.e. would the first packet in a flow of packets be delayed more than subsequent packets (assuming that the packets are transmitted are regular intervals following the first packet)? As there is no handshaking with UDP, I can't immediately see how this would occur with UDP. Is there some network level issue I'm missing out on with UDP flows?
Edit: Just had a thought there - I was under the impression that Warcraft et al. used a central server approach. Why would there be handshaking between two clients connected to the server? Surely the server would send the extra data along the existing connections to the server in this case?
Cheers
Damien
Associate Kyle Carter
Actually, it's done to keep bandwidth usage constant. That way when you _do_ start really moving, it will be responsive, rather than there being a pause as routers and packet flows get adjusted for the data to get through.