Hi Alexander At the last 6TiSCH bi-weekly call, 4 solutions have been presented to the hash clashes problem. Two based on a rehash table and two based on a new CoAP query parameter carrying the module name or registered module ID. This query parameter is used to select unambiguously the targeted data node(s) assuming that any hash collision within a module have been resolved at design time. You can find this presentation in attachment.
Both of your proposals make sense to me but I still hope that the clash file can be avoided or be optional. Michel Veillette System Architecture Director Trilliant Inc. Tel: 450-375-0556 ext. 237 [email protected] www.trilliantinc.com -----Original Message----- From: core [mailto:[email protected]] On Behalf Of Alexander Pelov Sent: 3 juin 2015 11:01 To: [email protected]; [email protected] Subject: [core] CoMI remote server clash file and YANG hash in URL Hello everyone, I would like to discuss with you to ideas/proposals in this mail, namely: 1) Caching the yang clash file on a remote server 2) Compressing the URL representation of YANG hashes 1) Caching the yang clash file on a remote server Even though hash collisions should happen rarely (if ever), there may be cases when it could be inevitable, and as such, it may be interesting to cache the clash_file somewhere on a remote server to avoid sending it over the constrained wireless interface. It could be used for other cases, where some frequently used resources are re-hashed for performance purposes. Maybe it would be interesting to allow the server to specify a remote location for the clash file? For static collisions or optimizations it could be that the YANG definition includes alternative hash values, which could be used in addition to the normal ones. 2) Compressing the URL representation of YANG hashes Another point (which is unrelated), is to elide the leading "A"s from the base64 representation of the hash in the URL (which corresponds to eliding the leading zeroes from the hash). As specified in section 5.4. a hash value of 0x0000007e will be encoded as AAAA_, but if the leading A’s are elided it will be simply _ This could pose problems only if in the future the size of the hash values is increased from 30 bits to some other (higher) value. This, however, could be very useful when having to frequently access the same resource. In such case, the server/network operator may decide to re-hash the URI to a shorter version, e.g. the /sys:system-state/sys:clock/sys:current-datetime could be remapped from 0x15370408 and VNwQI to 0x1 and _ Best, Alex PS. A typo (?), which may be already corrected, in the example of mod.uri on Page 26: the two responses have different scheme "mod.uri" and "moduri" _______________________________________________ core mailing list [email protected] https://www.ietf.org/mailman/listinfo/core
6TiSCH presentation on CoMI hash clashes r03.pptx
Description: 6TiSCH presentation on CoMI hash clashes r03.pptx
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
