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