On Wed, Jun 3, 2015 at 9:05 AM, Michel Veillette
<[email protected]> wrote:
> 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.
>
I agree we should not need the client to retrieve the rehash info
before using a server.
The CoMI authors have discussed a solution which I will try to write up today
where a special "hash-clash" error is returned by CoMI if a rehash is needed.
1) client requests module-A object with hash "1234";
there is no extended-name/local-name,
just the YANG hash, used in any request
2) if '1234' has a collision in this server then a special error
code is returned;
The return payload has the rehash info [old-hash, {
module-name, new-hash }+]
{ "1234": [
"module-A":"4567",
"module-X":"6523"
]
}
3) the client gets the error info, and knows which module its
"1234" is from.
It finds the correct module name in the array and replaces its old-hash
with the new-hash.
4) client re-sends the request, using hash "4567" instead of "1234"
The rehash table goes away, and only this error info is used instead.
> Michel Veillette
> System Architecture Director
> Trilliant Inc.
> Tel: 450-375-0556 ext. 237
> [email protected]
> www.trilliantinc.com
>
Andy
>
> -----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
>
> _______________________________________________
> core mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/core
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
