Reliable UDP without packet ordering.

[barisdoga2]

Hello,

I need reliable UDP communication without packet ordering.

According to the documentation, when using reliable communication, if a packet is dropped, the delivery of packets with higher sequence numbers is delayed until the dropped packet is received and delivered.

I want my application to receive reliable packets as soon as they arrive, even if there is a drop. So, I need reliable communication but without packet ordering.

I looked through the code but couldn't find any flags or options to make ENet work this way. Is there a way to achieve this that I might have missed?

If this functionality is not currently available, I would like to implement it and contribute to the project. I also wonder why this hasn't been implemented yet. Was there no demand for it, or is there an underlying issue?

Also, code references for starting implementation/investigation for this frunctionality greatly appreciated!

Also one irrelavant thing, I couldn't continue without saying. It would be great to have a Discord channel for the ENet community.

Many Thanks.

[mman]

Due to lack of imagination I can not see where it would be useful. One feature that enet is lacking currently is semi-reliable communication where you may want the new reliable packet to discard all previously undelivered reliable packets, that is very useful in for example video streaming where every 10 seconds you send reliable full frame and then you send reliable or unreliable intermediate frames that you want to ignore if undelivered at the moment new full frame is ready.

But unordered reliable? Could you please elaborate where/how you want to use it?

[barisdoga2]

Lets consider a game instance, movement data and chat data is transfered using only one reliable channel. I do not want missing chat packets to delay movement packets. The "movement" and "chat" maybe not reasonable examples but it basically explains the need.

[mman]

Movement is certainly an example of semi reliable, in that once you have new position, you do not need the old one and it should be thrown away. However chat is definitely time based as therefore ordered reliable… imagine a chat with messages out of order… kinda funny 😄

[barisdoga2]

Yeah, You are right there are many downsides, it was just an example. Maybe consider this, lots of big data packets sending. The data of each packet is irrelevant from each other. And the processing of these packets takes long time on the receiver side, also creation of each taking some time on sender side. I do not want any missing packet to interrupt processing.

[mman]

Yeah, kind of an academic discussion. That is what I asked for concrete examples where you want to use it.

But if you have multiple independent large things that should not stall each other and still be reliable, then allocate a new channel for each. The channels are handled independently and do not stall each other. That way you can keep sending independently and receiving independently while still sending unreliable important data (movements) on another channel.

[barisdoga2]

I also considered that. Can you say anything about the effect of using multiple channels on memory(Ignoring packets, just ENet internal).

[mman]

Use the source Luke :) when you allocate ENetHost, you give it number of channels. For each channel there is a data structure. For each packet scheduled to be sent but not yet sent, there is memory allocated. For each reliable packet sent and unconfirmed there is memory allocated. So having 1000 channels will not cost much, but having lot of reliable data sent and unconfirmed will keep memory allocated on the sending side until they are confirmed.

[lsalzman]

ENET_PACKET_FLAG_RELIABLE | ENET_PACKET_FLAG_UNSEQUENCED

[cher-nov]

ENET_PACKET_FLAG_RELIABLE | ENET_PACKET_FLAG_UNSEQUENCED

Well, but...

https://github.com/lsalzman/enet/blob/a356ac0aa90c212903f19c52d7215158ca54cfdb/include/enet/enet.h#L138-L139

[lsalzman]

The comment is out of date. The code definitely supports it