[ENet-discuss] Optimizing ENet Protocol ?

[Stefan Lundmark]

Hello Emmanuel,

Interesting thoughts! I'm not worried at all about the overhead in ENet, 
but things like peerID have caught my attention earlier as I didn't 
understand why it was there.
I still don't understand why it's there as (like you said) we could just 
map each Peer to the source address and be fine with it - but maybe 
there's more to it than that that I haven't noticed yet.

dataLenght I'm not so sure about - what if we compress the data? We need 
to keep the datalength for the uncompressed size in ENet.

Are you sure that reliableSequenceNumber always is 0?

Sincerely,
Stefan

On 2012-05-24 11:48, Emmanuel Rivoire wrote:
> Hello,
>
> I have been using DirectPlay from DirectX9 since 6 years in my games 
> and have been pretty happy with it since then, except I cannot use it 
> on Mac OSX.
>
> So I've decided to give Enet a try and I just had a deep look at 
> Protocol.c & .h .
>
> DirectPlay gives a packet overhead of 4 bytes for unreliable & 
> unsequenced messages.
> ENet overhead is 10 bytes (without the optional stuff) for this kind 
> of messages.
>
> In a general way, ENet protocol header always contains : peerID (on 9 
> bits) and dataLength on 16 bits.
> As far as I know, dataLength is already in the UDP header ( 
> http://en.wikipedia.org/wiki/User_Datagram_Protocol ) and incomplete 
> packets are dropped, so there's no need to have it within ENet header.
> peerID should be deducted from packet's sender IP & Port which are in 
> ENetHost::receivedAddress .
>
> That'd be already 3 bytes saved on each packet in all cases of use of 
> ENet.
>
> 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).
>
> So we're now down to an overhead of 3 bytes = 1 byte for flag (in 
> upper part of peerID, with 1 bit free) + 1 for command number (with 4 
> bits free) + 1 byte for channel ID.
> So I'm going to stuck the channel ID in the 4 free bits of the command 
> bytes, and the overhead will be of only 2 bytes.
>
> I'm not a network specialist, so maybe I got something wrong, so 
> please let me know if I did something incorrect, especially if I 
> overlooked something.
>
> And globally, does it sound doable in a timely fashion ..? I hope to 
> spend only a couple of days to do all of that.
>
> But for now, I'm going to begin by converting my mid-level network 
> code from DirectPlay to ENet, as it's the 1st step on the road..! ;-)
>
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
>