none
[MS-OXOABK] PidTagAddressBookContainerId hash algorithm RRS feed

  • Question

  • Good afternoon,

    [MS-OXOABK] specifies in section 2.2.2.3 page 18:

    This value is used in other NSPI calls (such as NspiResolveNamesW) to identify which container the NSPI call applies. If the value is non-zero, it is only a valid representation of the specific container while the connection to the NSPI server lasts or, after disconnection and reconnection to the same or other NSPI server using NspiBind, as long as the new server identifies itself as having the same GUID in its return value for pServerGuid, as specified in [MS-NSPI].


    As far as I understand this paragraph, it sounds like the NSPI server needs to implement some kind of hash mechanism computing the GUID server value and the container and this computed value be the same if two distinct NSPI servers use the same GUID.

    However I don't find any references about the mechanism behind this. Would it be possible to have more information about it? What is the algorithm used and which container attribute is used to generate this uint32_t identifier?

    Best Regards,
    Julien.


    Friday, September 19, 2008 4:44 PM

Answers

  • Also in a follow-up on the second part of the your question is a Minimal Entry ID (MId) that is received from a specific server with a given server GUID (from section 3.1.4.1) is valid only to a server that responds to an NspiBind with same server GUID.

    Section 3.1.4.1 states that a single server can use different GUID every time someone binds to it.  You have to treat MIds as very short lived and lasting only during the context of a single RPC connection.   There is no restriction from the protocol perspective on how the value of a MId is calculated by the server.  This is also true to how a server comes up with its’ server GUID. 

    It should be noted that clients should not calculate a MId.


    Developer Consultant
    Tuesday, September 23, 2008 4:56 PM
    Moderator

All replies

  • Julien,

    In reading the paragraph I would agree that the wording is a bit confusing.  Let me ask the technical content owner for some clarification.


    Developer Consultant
    Friday, September 19, 2008 9:14 PM
    Moderator
  •  

    Julien,

     

    The GUID must be unique. 

    This GUID is permanent in the context that its value is stored and will survive NSPI server reboots.  The GUID will be reset when you for example restore the server from a backup or auth-restore an object on the server.  Performing either of these actions will break any NSPI RPC connections.  After the restore operation a client that reconnects to the NSPI server will get a new GUID due to the above actions being performed. 

    This is why the documentation states that it can change over time.


    Developer Consultant
    Monday, September 22, 2008 5:41 PM
    Moderator
  • Also in a follow-up on the second part of the your question is a Minimal Entry ID (MId) that is received from a specific server with a given server GUID (from section 3.1.4.1) is valid only to a server that responds to an NspiBind with same server GUID.

    Section 3.1.4.1 states that a single server can use different GUID every time someone binds to it.  You have to treat MIds as very short lived and lasting only during the context of a single RPC connection.   There is no restriction from the protocol perspective on how the value of a MId is calculated by the server.  This is also true to how a server comes up with its’ server GUID. 

    It should be noted that clients should not calculate a MId.


    Developer Consultant
    Tuesday, September 23, 2008 4:56 PM
    Moderator