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
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
