Closed playingoDEERUX closed 2 years ago
During a normal disconnect the packets will be cleaned up before a peer is a reset. On an actual reset without a disconnect, the peer's state will be cleaned up and all the queues packets on it will be destroyed at that time as well.
However, for acknowledgement systems, I don't think this would be relevant. To make an acknowledgement, everything you send from host A to host B should have a packet ID you assign to it. Host B sends a message to host A that it received a given packet ID. If host A gets that ID ack'd, then it will stop trying to resend. If it doesn't get an ack in a certain timeframe, host A then resends that message to host B.
Thanks for the help, ENet is a great library. However, I wanted to say (since I have been doing sone performance tests with ENet lately), that I could profile some slowdown due to ENet's packet sorting, apparently..?!
Have you noticed this too and if so, were there any attempts at optimizing this?
Is ENetPacketFreeCallback called before the peer would ever be reset by ENet? I want to implement my own acknowledges to the peer using this, am I fine or could it be that ENetPeer* may be taken by a different user/client when this callback occurs?
Any response is appreciated.