Expose a way to know if data has been received by a peer

[Apostolique]

After calling Send on a NetPeer, it would be nice to expose a way to know if the data has been received. Especially for reliable messages.

Edit: Might even be nice to also have this for Connect.

[ghost]

• for that one.

[Krakean]

@RevenantX
Здравствуй Руслан
Этот фич-реквест уже реализован, или ещё пока не дошли руки?

[RevenantX]

@Krakean еще руки не дошли.

[mdsitton]

I posted this on discord a few days ago an never got a response from anyone so might as well post it here as well.

Just had an idea that could be useful and i wanted to see if there is a way to do it or if maybe something could be added. Basically atm i'm running into some issues on highly latent connections with a lot of packet loss with some packets taking a long time to actually get received by the server(this particular case i'm having the client has very bad upload and decent download). Would there be any decent way to have a way from user code of the library to determine when a packet has been acknowledged by the server with reliable channel types? Rather than trying to send extra event ack packets from the server manually?

This is basically the same thing as this feature request so i wanted to give my +1

[NVentimiglia]

If we go ahead, I would recommend something simple like a "ReliableAckCount"

[Apostolique]

I don't think a ReliableAckCount would be precise enough to identify specific messages.

[NVentimiglia]

It would not be, but it could Identify a problem.
I suggested it in part out of fear of callbacks (and their garbage)

[Apostolique]

Personally, I wouldn't use a callback. I'd add a function that can be polled.

[mdsitton]

So i think something like giving each message to be sent an increment value, that could be checked against the latest acknowledged packet's id. That way you know if your packet has been received with a reliable ordered delivery method.

Or hell you don't even need to give each one a value explicitly, but like @Apostolique said you could have a per-channel count of the current # of ack'd "messages", and the total number of messages requested to be sent(didn't want to use the term "packet" here since a single message could be sent multiple times if it doesn't get ack'd), and then you could read the current requested to be sent value before sending your message need then check the ack'd count to verify with it was received. This would probably be simpler to implement.

[mdsitton]

And i did get a short response about this from him on discord, i said i am considering trying to implement this myself if it doesn't happen shortly and he responded saying:

RevenantX - this almost WIP
mdsitton - ah so you are working on it?
RevenantX - @mdsitton in some way

Still considering doing an implementation myself and making a pull request though.

[RevenantX]

Done. Usage example:

EventBasedNetListener listener = new EventBasedNetListener();
NetManager client = new NetManager(listener);
client.Start();
client.Connect("localhost" /* host ip or name */, 9050 /* port */, "SomeConnectionKey" /* text key or NetDataWriter */);
listener.DeliveryEvent += (peer, obj) =>
{
    Console.WriteLine("Message delivered: " + (string)obj);
};
listener.PeerConnectedEvent += peer =>
{
    peer.SendWithDeliveryEvent(NetDataWriter.FromString("Hello server!"), 0, DeliveryMethod.ReliableOrdered, "USER_DATA");
};

//also you can tune NetManager.UnsyncedDeliveryEvent
//If true - delivery event will be called from "receive" thread otherwise on PollEvents call

If you use your INetEventListener implementation - just implement IDeliveryEventListener and it will work
it will work for RelaibleOrdered and ReliableUnordered
and for fragmented messages