On 15/05/2014 8:58 PM, John Leiseboer wrote:
An observation: I assume that there is no
guarantee or requirement for separate Locate requests to,
even with identical match criteria, return the matched
objects in the same order.
There is no requirement on a KMIP server to return objects in any
specified (or event consistent order) so a server is free to elect
to be non-predicable if it so wishes. That has always been the case.
Most sensible servers however do have a well defined order mechanism
in place (the mechanism does vary between vendors).
So a Locate require with a maximum items value repeated may return
the same set of managed objects or a different set depending on the
particular server vendors choice. New objects added between requests
may appear or may not appear.
So then if, for example, there are say 100
objects on a server that match a Locate request, and if the
client issues, say 10 sequential requests with offsets of 0,
10, 20, etc. respectively, each with a maximum object count
of 10, there is no guarantee that the client will actually
be returned the full set of 100 objects. In fact, worst
case, although probably unlikely, but possible, the client
could see the same 10 objects returned in each request.
If a server elects to implement with a non-consistent order in
responses then this mechanism won't be much use for that type of
server - although that type of server will have a pile of other
issues entirely separate from supporting an offset items value.
Does anyone disagree that this is
possible given the current specification? Is this an issue
for anyone?
The specification does not preclude a server vendor from
implementing items in a manner that makes Locate responses less
useful to a client then it should be. I recollect a discussion long
ago on ordering of responses from Locate but no requirement was
added into the specification to mandate a particular order.
If you are suggesting that the order of objects returned from Locate
should be made to be required to be deterministic then you should
perhaps raise that as a separate proposal.
Tim.
