Optimizing packet headers
From VbGORE Visual Basic Online RPG Engine
Contents |
[edit] Packet headers
Packets must include a header telling it where to go. For UDP, this header is around 8 bytes, while TCP headers are from 20 to 24 bytes (depending on what options are used in the packet). TCP, though slightly slower and bulkier, gives a lot more reliability. With UDP, you have to assume a packet may be dropped at any given time.
Combined with the 20 byte TCP header, there is the IPv4 header, which is 20 bytes. When IPv6 comes out, it will use 40 bytes instead of 20. So we are looking at a 40 byte header in a best case scenario, and 64 bytes in worst case (though IPv4 is more popular then IPv6 at the moment). These values add up quick, and tower over most any vbGORE packet in size.
[edit] The solution
So what is there to do to fight against these packets? Well lets use a nice little analogy first. Compare throwing ten 1-pound rock or one 10-pound rock. You have the constant force required to move your arm for the throwing, so throwing 10 rocks, although each throw is easier, requires more force in the long run. The same is for packets - it puts more stress on the server to send a large packet, but overall is less in comparison to the multiple small packets.
So what is the solution? The most obvious one - send less packets. Smash together as much as possible then throw it to the client all at once. Problem with this, though, is it takes time to get the information to pack together. You cant just send one big packet to the client every second - that is what we like to call 1000ms of intensively annoying lag. It can be quite confusing walking around, and seeing all the NPCs jump around once every second. But on the other hand, theres some packets we really don't care about. That is where the priorities comes in. But first off, the buffering.
[edit] Packet Buffering
vbGORE uses a custom buffering algorithm to smash together all those little packets under one header and send it all at once, making the most out of the header size (along with it is just overall faster). When you use Data_Send, it is actually going into a buffer of the users you specify for it to send to. It is not until the end of the update loop for the user that the data is actually sent.
In v0.2.1, there is a "global wait" constant that can be set which will forcibly buffer for a certain period of time. Such as if your server was running at 1000FPS, sending packets every millisecond is a total waste, so you can set the value to 50, so it is like your packets are running at 20 FPS. That may sound low, but think of any time you have played a game and you had a ping of 50. Did you complain? Hell no! You were probably as giddy as a schoolgirl for such a low ping!
[edit] Packet Priorities
The packet priority system was invented (well maybe not invented, but have never heard or seen such a system before) to combine those low-priority packets with those important packets. Just because they are low-priority, it doesn't mean we don't want to send them, though - we are just not worried about the time it takes for them to get there. It can be very tricky to decide what you want to use, and using PP_None can be dangerous. Though this may help a bit:
Note that PP_None will always, as a last resort, end up attaching to the ping packet just since the way it is structured (since the ping packet is PP_High). Be very careful with PP_None if you remove the ping or lower the time!
- PP_High
- Use this for most all the packets. Try and think of what it'd be like if the packet got there about a second later. What would it be like? If it was the server telling the client to play a sound or that a character attacked, it wouldn't look good if it took over a second to show up, would it? No... no it would not.
- PP_Low
- This will be your most commonly used "unimportant" packet state. Try to think when making a packet, does it need to get to the user as soon as possible? Can they wait at least a second? Such as if they were to equip new armor, is it really vital if they can see the stat change within a second?
- PP_None
- This is the hard one. How vital is the information? Can it wait for a few seconds? Will the user notice if it takes a while to get to them? The best example is the receiving new mail message - unless you are told that you were just sent mail by the user, you wont notice if it takes an extra 1-10 seconds to get to you. Use this with extreme caution.
The packet priorities in vbGORE is made very simple for the user. In the Data_Send routine, there is an optional parameter at the end to set the packet priority. You can just ignore this value and it will automatically be set to PP_HIGH.
