Difference between revisions of "Packet Accounting"
Cube Linden (talk | contribs) |
(Correction about sequence number.) |
||
(13 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
== Packet Sequences == | == Packet Sequences == | ||
The packet sequence number is a 32 bit number created at the connection of any circuit. This number is stored | The packet sequence number is a 32-bit number created at the connection of any circuit. This number is stored in the [[Packet Layout#Header|packet header]], and incremented whenever a packet is sent from one end of the circuit to the other. | ||
== Packet Acknowledgment == | == Packet Acknowledgment == | ||
When NodeA sends a message | Reliability is not implicit to a message, rather, it is specified by the sender of a message at the time the message is sent. When NodeA sends a message through the reliable send function, the LL_RELIABLE_FLAG is set in the header of the [[Packet Layout]], and the packet sequence number is stored into a set in NodeA's [[circuit]] info. When NodeB receives the reliable packet, it attaches the packet number of the packet it received to the end of the next packet it sends, and sets the LL_ACK_FLAG bit of the returning packet to show acknowledgment of transfer to NodeA. If NodeB does not have the ability to attach an ACK to a packet in a timely fashion (due to large [[messages]] being sent with no room for ACKs, a large number of ACKs built up, etc...), NodeB can also encase a variable number of ACKs in a [[PacketAck]] [[message]] to specifically take care of the rest of its ACKs and avoid duplicate packets from flooding the network. | ||
Assuming NodeA receives the acknowledgment, it removes the acknowledged packet number from the reliable acknowledgment set. Otherwise, if the acknowledgment is not received in a predetermined amount of time (A minimum of 1 second, or a maximum determined by the average ping delay of the circuit), the packet is resent. If the packet is not acknowledged after 3 resends (default value), it is dropped. | |||
==Packet Throttling== | |||
Bandwidth throttling is calculated on 7 different types of data: | |||
*Resend - Resending of reliable packets with no ACK | |||
*Land - Land layer data | |||
*Wind - Wind layer data | |||
*Cloud - Cloud layer data | |||
*Task - Updates to anything the simulator considers a task (Objects, Agents, etc...) | |||
*Texture - Image files | |||
*Asset - Object Data, Animations, Gestures, Sounds, etc... | |||
These are managed in a "throttle group", where each type is assigned a portion of the overall bandwidth setting (as set in the parameters of the client). The [[Transfer Manager]], [[Texture Pipeline]] and [[Interest List]] then handles the updates for the different bandwidth types as they send data across the [[circuit]]. | |||
== | ==Duplicate Suppression== | ||
Due to the fact that acknowledgments to reliable packets are attached to UDP messages, there is no guarantee they will actually be received by the remote host. In this case, the circuit is responsible for dealing with suppression of the duplicate packets. | |||
The circuit keeps a list of all recently received reliable packets, up through a certain timeout value. If a reliable packet that is already on this list is received again, the circuit replies with another ACK appended to the next packet. |
Latest revision as of 20:05, 11 March 2022
Packet Sequences
The packet sequence number is a 32-bit number created at the connection of any circuit. This number is stored in the packet header, and incremented whenever a packet is sent from one end of the circuit to the other.
Packet Acknowledgment
Reliability is not implicit to a message, rather, it is specified by the sender of a message at the time the message is sent. When NodeA sends a message through the reliable send function, the LL_RELIABLE_FLAG is set in the header of the Packet Layout, and the packet sequence number is stored into a set in NodeA's circuit info. When NodeB receives the reliable packet, it attaches the packet number of the packet it received to the end of the next packet it sends, and sets the LL_ACK_FLAG bit of the returning packet to show acknowledgment of transfer to NodeA. If NodeB does not have the ability to attach an ACK to a packet in a timely fashion (due to large messages being sent with no room for ACKs, a large number of ACKs built up, etc...), NodeB can also encase a variable number of ACKs in a PacketAck message to specifically take care of the rest of its ACKs and avoid duplicate packets from flooding the network.
Assuming NodeA receives the acknowledgment, it removes the acknowledged packet number from the reliable acknowledgment set. Otherwise, if the acknowledgment is not received in a predetermined amount of time (A minimum of 1 second, or a maximum determined by the average ping delay of the circuit), the packet is resent. If the packet is not acknowledged after 3 resends (default value), it is dropped.
Packet Throttling
Bandwidth throttling is calculated on 7 different types of data:
- Resend - Resending of reliable packets with no ACK
- Land - Land layer data
- Wind - Wind layer data
- Cloud - Cloud layer data
- Task - Updates to anything the simulator considers a task (Objects, Agents, etc...)
- Texture - Image files
- Asset - Object Data, Animations, Gestures, Sounds, etc...
These are managed in a "throttle group", where each type is assigned a portion of the overall bandwidth setting (as set in the parameters of the client). The Transfer Manager, Texture Pipeline and Interest List then handles the updates for the different bandwidth types as they send data across the circuit.
Duplicate Suppression
Due to the fact that acknowledgments to reliable packets are attached to UDP messages, there is no guarantee they will actually be received by the remote host. In this case, the circuit is responsible for dealing with suppression of the duplicate packets.
The circuit keeps a list of all recently received reliable packets, up through a certain timeout value. If a reliable packet that is already on this list is received again, the circuit replies with another ACK appended to the next packet.