[cifs-protocol] 118120419417063 [MS-ADDM] Active Directory Webservices expected lifetime of [MC-NBFSE] StringTable

Edgar Olougouna edgaro at microsoft.com
Wed Dec 19 20:33:44 UTC 2018


Your understanding is correct. Each connection maintains its own dictionary string table. To use .Net jargon, it’s the producer (client) which sends the dictionary strings to the consumer (server). Effectively its one-way in the client-server relationship in this case.

Thanks,
Edgar

-----Original Message-----
From: Garming Sam <garming at catalyst.net.nz> 
Sent: Tuesday, December 18, 2018 7:08 PM
To: Edgar Olougouna <edgaro at microsoft.com>
Cc: cifs-protocol at lists.samba.org; MSSolve Case Email <casemail at microsoft.com>
Subject: Re: 118120419417063 [MS-ADDM] Active Directory Webservices expected lifetime of [MC-NBFSE] StringTable

That's helpful information.

So you say each connection maintains its own dictionary string table? So just to clarify does that mean that there is effectively only one table for both the client and server (and for instance, the server sending back new entries in the table for the client to use, should also add these entries to its own XML dictionary?).

I'm mostly only interested in the NetTcpBinding, but that's some interesting information in regards to the HTTP endpoints. These 'reliable sessions' seem interesting, although they don't seem to be used for the Active Directory commands.

Cheers,

Garming

On 12/12/18 11:16 AM, Edgar Olougouna wrote:
> Garming,
>
> When we look at MS-ADDM spec, Section 2.1 (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmsdn.microsoft.com%2Fen-us%2Flibrary%2Fdd357379.aspx&data=02%7C01%7Cedgaro%40microsoft.com%7C26c47b60d64e437fe73708d6654e6427%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636807784701076065&sdata=0HE6i9vUCOqv9jaO834SjPE4MhdBhy8MOLakJVUrapw%3D&reserved=0) says “All endpoints use the "net.tcp" URI binding type.” For ADWS specific usage, the lifetime of the StringTable will be an individual socket connection between the client and the server. For two connections to different flavors of the same endpoint, each connection maintains its own dictionary string table. This is better understood when we look at ADWS as an application which leverages classes/namespaces of .Net Framework. (See link of source code reference). 
>
> From spec standpoint, [MC-NBFSE] 2.1 StringTable “... maintain this mapping until there are no further documents to process” means the scope is whatever both application ends agree to. From a .NET implementation standpoint, the mapping is maintained by the class XmlDictionary  (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freferencesource.microsoft.com%2F%23System.Runtime.Serialization%2FSystem%2FXml%2FXmlDictionary.cs&data=02%7C01%7Cedgaro%40microsoft.com%7C26c47b60d64e437fe73708d6654e6427%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636807784701076065&sdata=3iwAry5MuHNV8K%2BHW46dmx13hIePFeNsMuu%2BBvYETFs%3D&reserved=0) so the mapping lifetime is the lifetime of an instance of that class.
>
> From a practical standpoint when using WCF, the lifetime/scope depends what the binding is doing and can be summarized as follows. If you are using the NetTcpBinding, each channel maintains its own table for the lifetime of the connection. If you are using reliable sessions, then the session lifetime exists beyond the socket connection as it can reconnect a dropped connection and resume the session. 
> If you are using the NetHttpBinding (SOAP 1.2 with the binary message encoder), there is no persistent session, the session is effectively the lifetime of a single request. This means any string not in the default table will need to be sent again with every request. While this sounds inefficient, it’s usually still more efficient than using plain text as you are either sending small messages which benefits from the default string table, or you are sending large messages and there’s a lot of repetition of strings so it’s still worth sending the table each time. 
> If you are using WSHttpBinding, although it’s using HTTP, it establishes a persistent session which lives across multiple requests.
>
> .Net Framework Source Reference:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Frefe
> rencesource.microsoft.com%2F%23System.Runtime.Serialization%2FSystem%2
> FXml%2FXmlDictionary.cs&data=02%7C01%7Cedgaro%40microsoft.com%7C26
> c47b60d64e437fe73708d6654e6427%7C72f988bf86f141af91ab2d7cd011db47%7C1%
> 7C0%7C636807784701076065&sdata=3iwAry5MuHNV8K%2BHW46dmx13hIePFeNsM
> uu%2BBvYETFs%3D&reserved=0
> XmlDictionary.cs
> XmlDictionaryString.cs
> XmlBinaryWriter.cs
> XmlBinaryReader.cs
> XmlBinaryWriterSession.cs
> XmlBinaryReaderSession.cs
> BinaryMessageEncoder.cs
>
> Thanks,
> Edgar
>
> -----Original Message-----
> From: Edgar Olougouna
> Sent: Tuesday, December 4, 2018 11:03 PM
> To: Garming Sam <garming at catalyst.net.nz>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
> <casemail at microsoft.com>
> Subject: RE: 118120419417063 [MS-ADDM] Active Directory Webservices 
> expected lifetime of [MC-NBFSE] StringTable
>
> Garming,
> I will review and follow-up.
>
> Thank you,
> Edgar
>
> -----Original Message-----
> From: Sreekanth Nadendla <srenaden at microsoft.com>
> Sent: Tuesday, December 4, 2018 5:55 PM
> To: Garming Sam <garming at catalyst.net.nz>
> Cc: cifs-protocol at lists.samba.org; MSSolve Case Email 
> <casemail at microsoft.com>
> Subject: 118120419417063 [MS-ADDM] Active Directory Webservices 
> expected lifetime of [MC-NBFSE] StringTable
>
> Dochelp in Bcc
> Casemail in Cc
>
> Hello Garming Sam,
> Thank you for your inquiry about Microsoft Open Specifications. We have created the following incidents to investigate your issue. One of the Open specifications team member will contact you shortly and separate e-mail threads will be started to assist you with these questions.
>
>
> 118120419417063  [MS-ADDM] Active Directory Webservices expected 
> lifetime of [MC-NBFSE] StringTable. Question #1
> 118120419417067  [MS-ADDM] Active Directory Webservices expected 
> lifetime of [MC-NBFSE] StringTable. Question #2
>
>
> Regards,
> Sreekanth Nadendla
> Microsoft Windows Open Specifications
>
>
> -----Original Message-----
> From: Garming Sam <garming at catalyst.net.nz>
> Sent: Tuesday, December 4, 2018 6:41 PM
> To: Interoperability Documentation Help <dochelp at microsoft.com>
> Cc: cifs-protocol at lists.samba.org
> Subject: [MS-ADDM] Active Directory Webservices expected lifetime of 
> [MC-NBFSE] StringTable
>
> Hi,
>
> When running AD Powershell commands, the transport is a SOAP-binary XML format. The protocol defining this [MC-NFBSE] allows compression using a dictionary which is appended to at runtime by sending a StringTable at the beginning of the message.
>
> The base dictionary has static entries at every even index, while the runtime entries are added at every odd index. There seem to be some ambiguities in what the lifetime of these entries are:
>
> 1) When you have two endpoints communicating (A, B), are there two dictionaries, one on A and one of B (or is it shared)?
>
> When Endpoint A adds entry at offset 0x1, does this mean that when Endpoint B adds an entry it must be at offset 0x3 of a shared dictionary? The StringTable structure only specifies a sequence of elements to add to 'the dictionary', not its index.
>
> 2) How long are entries in the dictionary meant to live? [MC-NBFSE] 2.1 StringTable says "A consumer of this format MUST maintain this mapping until there are no further documents to process."
>
> It's not entirely clear what is meant by 'no further documents to process'. For instance, the StringTable entry could only live as long as a single SOAP request, but then it doesn't offer much in the way of compression and I would've considered each SOAP request a 'document'.
> Intuitively, I would expect the dictionary to last the session, but what a session is depends on the underlying protocol. With Active Directory Web Services and [MC-NMF], it should mean [Preamble] -> [EndRecord] / disconnect. Alternatively it could be over the TCP connection, but lasting over multiple application level communications (with different security contexts) seems kind of wrong. In fact, a conversation may exist over multiple ADWS endpoints and presumably connections, but I don't think there is any way to tie these together.
>
>
> Cheers,
>
> Garming
>
>


More information about the cifs-protocol mailing list