[ENet-discuss] Optimizing ENet Protocol ?

[Emmanuel Rivoire]

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 ?

As far as I can tell, DirectPlay doesn't handle packet length, and I 
never had trouble with packets arriving cut in half...


>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/7d3e3632/attachment.html>