I can't see that it would save several hundreds bytes if the offsets are fixed. A packet is pretty much always parsed sequentially and adding a variable to a variable instead of a constant to a variable isn't going to make that much difference, surely?
Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com <http://www.gridmerge.com/> On 25/06/2010 1:50 PM, Daniel Gavelle wrote:
If there were a fixed number of options with a fixed length and order, the packet would be very simple to parse as the data fields would be at the same offset in the buffer each time.The receiver could check the option type, length and other unchanging bytes at their fixed offsets and if anything doesn't match the fixed values, reject the packet.I think this would save several hundred bytes and make testing simpler.There would need to be two types of e.g. NS, host to LR and LR to LBR but it would be easy to distinguish these.Any future options could be added after the ones that are mandated in the current specification.Daniel. Richard Kelsey wrote:From: Ralph Droms <[email protected]> Date: Thu, 24 Jun 2010 15:52:07 -0400How, exactly, would specifying the order make any difference to an implementation in terms of:* code size and complexityIf two options interact in any way, the code to process them is simpler if they appear in a fixed order. The degree to which a fixed order simplifies the code depends on the degree of interaction between the various options.* processing timeNo appreciable difference.* interoperabilitySending the options in the right order, and testing that they are sent in the right order, is trivial. Testing that the order in which they appear in incoming messages is irrelevant is much harder.Seems to me such a requirement would reduce interoperability with existing implementations.Absolutely. This only makes sense if there are there no existing deployments. Given the freshness of 6LoWPAN NDI am not sure that this is an issue. -Richard Kelsey _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
