<br><br><div class="gmail_quote">On Thu, May 24, 2012 at 4:42 AM, Emmanuel Rivoire <span dir="ltr"><<a href="mailto:manu.n02@laposte.net" target="_blank">manu.n02@laposte.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>
Hello,<div class="im"><br><br>
At 18:05 24/05/2012, you wrote:<br>
<blockquote type="cite">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.</blockquote><br></div>
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.<br>
I guess there's some for ENetProtocolSendFragment , but it should happen
only if you detect the message size is bigger than MTU, no ?<br><br></div></blockquote><div>I assure you, packets are aggregated, even unsequenced ones. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
As far as I can tell, DirectPlay doesn't handle packet length, and I
never had trouble with packets arriving cut in half...<div class="im"><br></div></div></blockquote><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="im"><br>
<br>
<blockquote type="cite">
<dl>
<dd>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.<br>

</dd><dd>2 more bytes saved.<br><br>

</dd><dd>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).<br>
<br>

</dd></dl>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.  </blockquote><br></div>
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)<br>
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..!<div class="im"><br><br>
<br>
<blockquote type="cite">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.</blockquote><br></div>
Thanks for your help.<br>
I was not asking to do that for me, just the feasibility... ;)<br><br>
I'm going to do a feature request in a new thread on something different,
though, just in case..!<br>
</div>

<br></blockquote></div>