On Thu, May 24, 2012 at 4:42 AM, Emmanuel Rivoire <[email protected]>wrote:
> 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 ? > > I assure you, packets are aggregated, even unsequenced ones. > As far as I can tell, DirectPlay doesn't handle packet length, and I never > had trouble with packets arriving cut in half... > > 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. > > > 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
