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

Edgar Olougouna edgaro at microsoft.com
Tue Dec 11 22:16:43 UTC 2018


Garming,

When we look at MS-ADDM spec, Section 2.1 (https://msdn.microsoft.com/en-us/library/dd357379.aspx) 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://referencesource.microsoft.com/#System.Runtime.Serialization/System/Xml/XmlDictionary.cs) 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://referencesource.microsoft.com/#System.Runtime.Serialization/System/Xml/XmlDictionary.cs
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