NACK is the idea that the client of a request will send to the server a list of packet ids that it has yet to receive. We can do this because a PacketGroup has knowledge of ids not received AFTER we get the final packet. If we do not get the packet marked final, we are unable to tell how many packets are remaining. Either will require special handling of that case or refactoring packet to include extra value indicating total size of packet group.
Would need to have a new method that could gather this information including an argument to say how long the PacketGroup is remaining (in terms of ttl) to get a list of ids.
We'd want to have the InputProcessor be able to process a packet of type NACK as well, which is a special type that does not contribute to a packet group. This should somehow trigger the sending of the missing packets using the OutputProcessor, which would need to cache them for some TTL to ensure that they could be resent.
NACK is the idea that the client of a request will send to the server a list of packet ids that it has yet to receive. We can do this because a PacketGroup has knowledge of ids not received AFTER we get the final packet. If we do not get the packet marked final, we are unable to tell how many packets are remaining. Either will require special handling of that case or refactoring packet to include extra value indicating total size of packet group.
Would need to have a new method that could gather this information including an argument to say how long the PacketGroup is remaining (in terms of ttl) to get a list of ids.
We'd want to have the InputProcessor be able to process a packet of type NACK as well, which is a special type that does not contribute to a packet group. This should somehow trigger the sending of the missing packets using the OutputProcessor, which would need to cache them for some TTL to ensure that they could be resent.