[ENet-discuss] Optimizing ENet Protocol ?

[Lee Salzman]

On Thu, May 24, 2012 at 4:42 AM, Emmanuel Rivoire <manu.n02 at laposte.net>wrote:

>  Hello,
>
>
> At 18:05 24/05/2012, you wrote:
>
> The length is needed because ENet does all sorts of aggregation. The
> packet boundaries are not 1:1. If you have 10 ENet packets in one UDP
> protocol packet, well, there's no way to find the packet boundaries without
> length. This would only be possible for the last ENet packet in a protocol
> packet, but you are still subject to one final caveat with this that makes
> it not really worth it... Packet lengths themselves as reported by UDP are
> not reliable: routers are free to fragment, chop up, etc. packets as will,
> as is the OS itself before it even sends it to the router, and the OS on
> the receiving end even as it hands the packet off to the user. By the time
> the packet gets to you, you have no indication that this packet mangling
> happened without one of two mechanisms: either a checksum or a length. So
> length has multiple useful functions here.
>
>
> I looked everything in enet_protocol_receive_incoming_commands() then
> enet_socket_receive(), and I cannot see anything else than 1 UDP packet = 1
> ENet message for unsequenced messages : there's no concatenation at all,
> only packet dropping if dataLength isn't big enough.
> I guess there's some for ENetProtocolSendFragment , but it should happen
> only if you detect the message size is bigger than MTU, no ?
>
> I assure you, packets are aggregated, even unsequenced ones.


> As far as I can tell, DirectPlay doesn't handle packet length, and I never
> had trouble with packets arriving cut in half...
>
> Well, DirectPlay is DirectPlay, it doesn't need to work on a bunch of
different platforms under wildly different demands. It's not the standard
by which I judge reliability in this context.


>
>
>  Moreover, I'm planning to remove
> ENetProtocolSendUnsequenced::unsequencedGroup which is not mandatory at
> ENet level (this is an arguable opinion ;) ), mainly because I already have
> the attached functionality in the high level part of my network code, but
> using less bits, so it's redundant and less effective at ENet level.
> 2 more bytes saved.
>
> Lastly, if I understood the code correctly
> ENetProtocolSendUnsequenced::header::reliableSequenceNumber isn't needed
> (it's always set to 0), so that's 2 bytes wasted (only for unsequenced
> message case).
>
> Unsequenced is not simply a normal UDP packet, it is unsequenced, but
> still not redundant, not quite what you're thinking. It was done this way
> mainly for uniformity with the other packet types to keep things simple;
> conceivably you could squish the unsequenced group number into the reliable
> sequence number space or if you don't care about redundant just remove both
> somehow. On the other hand, I'm not really interested in breaking protocol
> compatibility for all users at this point over a feature that isn't really
> of central utility to most users. In the future I could maybe implement a
> truly unsequenced/redundant (= truly unreliable) packet type if there was
> ever sufficient demand, but I think the current unreliable type is the main
> backbone packet for most people and is generally the most efficient type to
> use anyway - there is no real efficiency gain from using unsequenced in the
> current protocol, it's just a semantic thing for when you really need to
> violate the packet sequencing restrictions for some reason.
>
>
> It's not the packet which is redundant, but the code, coz I thought I
> already did that in my high level network code... :)   (I call this high
> level because I did this above DirectPlay)
> But I may have understood wrongly what you did. I thought unsequencedGroup
> was used to drop packets that arrive way too late. I guess I'd have to dig
> a bit more in the code to get it all right, but if you tell me I can chop
> it out, it's all I need to know for now..!
>
>
>
> So the main changes you're left with is you could save that one byte of
> space for the peer id, and conceivably up to 4 bytes in the unsequenced
> packet's header by removing the unsequenced group functionality (2) and not
> including the reliable sequence number (2). So between those two if it's a
> substantial use case for you you could save 4-5 bytes per unsequenced user
> packet if it is really an important use case for you. Though I don't think
> I can do this for the general ENet because it would break compatibility
> with older versions and all the hassle that causes. You are of course free
> to make these changes in your own project as that's why I kept the source
> code small, understandable, and open in the first place: I did want it to
> be a library that people could dig in and make whatever personal
> customizations they needed for their project.
>
>
> Thanks for your help.
> I was not asking to do that for me, just the feasibility... ;)
>
> I'm going to do a feature request in a new thread on something different,
> though, just in case..!
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cubik.org/pipermail/enet-discuss/attachments/20120524/05308c15/attachment.html>