Dear all,
Trying to work out all your recommendations, I fail to understand the
need for the solution.
Large clients and small servers is not tru any more.
The assumption is that clients and servers are small, they are not
dynamically augmented with new modules. They only know about hash values
and have no knowledge what so ever of the corresponding names.
Let's concentrate on the one module clash first.
Apparently, it is envisaged to load modules that already contain hash
clashes inside.
For me that is an unsolvable problem: There is one hash value that
points to different names (memory stores) in the server.
Servers only know about hash values, they have no name tables. Suppose
one of the names has been rehashed (where? certainly not within the
server).
We might add a statement in the server that the old hash value goes to
the new rehashed value.
It is not clear to me how the server can decide which memory location
goes with the old hash value and which with the new value.
Apparently, something needs to be done before the module is loaded into
the server. For me that means that only modules can be loaded without
hash clashes.
Suppose in a given server two names from two modules clash. The solution
is then that the module ID distinguishes between the two clashing
values.
It is then proposed that module names are hashed. That solution is the
same as saying that you need more than 32 bits for a hash value to
reduce clash probability.
The only valid remaining approach is a registry that maps module name to
a 32 bit? ID. Transporting the module ID means additional transport
costs.
I can imagine though that in a given installation the servers and their
module combinations are known.
Any clashes can be solved before load time. The appropriate code can be
loaded in the small clients and servers.
The problem arrives when a new server with a set of modules (including a
new module) finds a clash.
This clash does not affect the old clients and servers (they are not
aware of the new module)
Consequently, the clash can be solved by renaming the clashing name in
the newly added module.
All clients, and servers which have to use the clashing name of the new
module will use the hash value of the renamed name, and do not need to
be aware of the rehashing.
At the operational level, there are only unique hashes within an
installation.
At the organization level, the rehash value of the new module needs to
be registered and used when code for new clients or servers are
generated.
Consequently, I do not see a need for module IDs.
Any mistakes in the above?
Peter
Michel Veillette schreef op 2015-04-02 20:37:
If I summarize:
Reducing the scope of uniqueness of YAND hash values to each module
allows detection of hash collision(s) at design time instead of at run
time.
To reduce this scope, we need to:
- Create a unique module identifier (e.g. 20 bits organization ID
registered at IANA, 10 bits module ID)
- Add this module identifier to the URI (e.g. one to five base64
characters)
- Add a map at the root of the CBOR objects carry within the CoAP
payload to associate module IDs with modules data nodes (e.g. one to
five byes per module)
The problem that still need to be resolved is how we document data
nodes rehash offline.
- One option is to use the description statement of the YANG module or
a new YANG statement specifically added for this purpose.
- Another option is create a IANA registry for these rehash values.
Hash collisions within YANG modules are very unlikely to happen and
the solution don't need to be highly scalable. In that respect, using
a IANA registry might be a good solution since it can be used for
already published yang modules and can be use after the fact with any
future YANG modules.
Michel Veillette
System Architecture Director
Trilliant Inc.
Tel: 450-375-0556 ext. 237
[email protected]
www.trilliantinc.com
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email protected]]
Sent: 2 avril 2015 13:09
To: Carsten Bormann; Andy Bierman
Cc: Michel Veillette; [email protected]; [email protected];
[email protected]
Subject: RE: [6tisch] [core] COMI hash values globally unique vs.
unique within a module
Yes, we asked about that as well.
It help to have a registry that guarantees the uniqueness of the first
element in the path, so as to make it easier to check for collision
within one path only.
Cheers,
Pascal
-----Original Message-----
From: 6tisch [mailto:[email protected]] On Behalf Of Carsten
Bormann
Sent: jeudi 2 avril 2015 18:41
To: Andy Bierman
Cc: Michel Veillette; [email protected]; [email protected];
[email protected]
Subject: Re: [6tisch] [core] COMI hash values globally unique vs.
unique within a module
I think I'm losing track of what "this" is.
Assigning numbers when doing a (version of a) module should be doable,
even if it requires some additional tooling.
Assigning numbers to modules would require a registry.
No rehashing (or hashing at all) required.
(Now, that registry could be filled using a hash...)
BTW, I'm not sure that the "rehashing" in the current spec is the
easiest way to handle collisions -- I also don't understand how
multiple paths that arrive at the same hash value are handled.
Grüße, Carsten
Andy Bierman wrote:
> On Thu, Apr 2, 2015 at 8:25 AM, Andy Bierman <[email protected]>
wrote:
>> Hi,
>>
>> I should make it clear that I was trying to use a module-id so the
>> objects in the module could be given a simple integer OID.
>> The goal was to support identifiers that could fit in 1 or 2 bytes.
>> But this was dropped when we changed to using hashes.
>>
>> It might be a huge effort to create and use numeric module IDs, but
>> YANG module names tend to be long strings. It might be worth it, if
>> a per-module hash is used.
>>
>> If the collisions were coupled to specific modules, then they might
>> be avoided before publication or the client can be hard-wired to
>> use the rehashed values from the start.
>>
>> A client would not need to know the XPath strings for any objects.
>> It could be hard-coded to work with module X, Y, Z, and it would
>> always work, no matter what additional modules were added to the server.
>> This does seem very useful for constrained clients.
>>
>
> A standard, deterministic renaming algorithm would be needed to make
> this viable. If each server is free to choose its own rehash, then
> the client still needs to store all the strings, and resolve the
> collisions at run-time instead of compile-time.
> (So therefore a module-name or module-id would not solve anything).
>
>> Andy
>
> Andy
>
>>
>> On Thu, Apr 2, 2015 at 5:55 AM, Carsten Bormann <[email protected]> wrote:
>>> Michel Veillette wrote:
>>>> strings represents */5323 bytes/*
>>> If we want to free the implementations completely of having to use
>>> these strings, we'll need to assign numbers. This can be done at
>>> the module level, either manually or algorithmically. Using a
>>> per-module hash to do this is suboptimal; it is much better to
>>> fill a small
linear space.
>>>
>>> We then need a way to compose these numbers with numbers assigned
>>> to module IDs. SMIv2 had this way to name modules and their components...
>>>
>>> Grüße, Carsten
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
