You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is tracking the connection implementation behind RakNet.
Checklist
Implement Reliable Queues
Implement dynamic dispatch for each connection
Details
Reliable queues: Are for internal packet handling, similar to the v2 version you can see that here. However the newer queues are more robust in the fact that they will handle the repetition of ordering packets and ACKING as needed. For instance, the SendQueue will hold an ack of all packets we've sent, also known as the recovery queue, while the RecvQueue will hold an ack of all packets we're expecting, as well as handle reassembling of frames and out of order packets with an ordered queue.
Dynamic Dispatch: The main thread should be able to notify each connection of it's state regardless of the current processing state. EG: If we terminate a client, there's no reason it should need to wait until the next tick to figure that out, or if we need to send a packet immediately, there's no reason why we should need to queue this when we can dispatch it immediately to the server.
The text was updated successfully, but these errors were encountered:
This issue is tracking the connection implementation behind RakNet.
Checklist
Implement Reliable Queues
Implement dynamic dispatch for each connection
Details
Reliable queues: Are for internal packet handling, similar to the v2 version you can see that here. However the newer queues are more robust in the fact that they will handle the repetition of ordering packets and ACKING as needed. For instance, the
SendQueue
will hold an ack of all packets we've sent, also known as the recovery queue, while theRecvQueue
will hold an ack of all packets we're expecting, as well as handle reassembling of frames and out of order packets with an ordered queue.Dynamic Dispatch: The main thread should be able to notify each connection of it's state regardless of the current processing state. EG: If we terminate a client, there's no reason it should need to wait until the next tick to figure that out, or if we need to send a packet immediately, there's no reason why we should need to queue this when we can dispatch it immediately to the server.
The text was updated successfully, but these errors were encountered: