MS Office 2010 + SharePoint 2010 Joint Authorship: protocols and packets
The co-authorship mechanism was introduced with the release of MS Office 2010 and SharePoint 2010. The new functionality has been called "long-awaited" by many, and there is no point undervaluing its convenience. However, this article refers to functional details of the mechanism and to possible benefits. After all, this is a whole new area!
For the User
First, operation of the joint authorship mechanism should be considered. By surfing the Internet it becomes clear that this is already done in reasonable detail. I will not repeat what already has been found and suggest you get familiar with it yourself.
For the Designer
My interest was to understand how the user’s actions relate to the resulting packets and in learning how actions can be determined based on the packets sent. This would allow collecting user activity information (employees, in my case) at the corporate portal by coding the HTTP Module. This information may come in handy when increasing the number of conversions or tracing the documentation development performance. Moreover, practice proved that it is more effective and secure to monitor incoming packets rather than outgoing.
Due to document caching, the task is complicated by controversial determination of users’ activities in some cases by the information on the MS-FSSHTTP level. For example, on occurrence of the first document opening event the document is downloaded. This can be easily determined by the packet description. When the document is opened for the second time, its cached version is compared with the server document without downloading it, though semantically these two events mean the user is working with document.
The joint authorship can be used successfully in Word 2010, Excel 2010, OneNote 2010, SharePoint Workspace 2010 with SharePoint Foundation 2010 or SharePoint Server 2010 as stated in the specifications.
Protocols and packets
All communication between SharePoint and the MS Office 2010 user is made by means of MS-FSSHTTP (File Synchronization via SOAP over HTTP Protocol Specification) and MS-FSSHTTPB (Binary Requests for File Synchronization via SOAP Protocol Specification) protocols.
The following protocol description links are given for further convenience:
When exchanging packets, the MS-FSSHTTP protocol transfers information on the entity, which is the starting point (the URL), on the author beginning to work with the entity, and on operational modes (Read Only and Edit modes require different priority levels). The MS-FSSHTTP part of the packet is in XML format which is not an advantage of the protocol. XML subdivisions in the packet are numbered by the SubRequestToken parameter. The DependsOn parameter enables packet integrity checking. The entity itself is called “cell” within MS-FSSHTTP and MS-FSSHTTPB protocols. The MS-FSSHTTP request structure has the following pattern:
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<RequestVersion …> //Information about the used protocol versions
<RequestCollection …> //The CorrelationID, guid used
for the server logs and synchronizing packets is being specified,
<Request …> //Contains document URL
<SubRequest …/> //Packet identification
</SubRequest>
…
</Request>
</RequestCollection>
</s:Body>
</s:Envelope>
Some explanations to the MS-FSSHTTP protocol structure:
<Request Url="http://serverName/documentFullPath" RequestToken="1"> - the required structure of the protocol packet indicating the requested document.
<SubRequest Type="Coauth" SubRequestToken="1"> - declaration of the co-authorship mode; the enclosed tag contains indication of the co-authorship type in use.
<SubRequest Type="SchemaLock" SubRequestToken="2" DependsOn="1" DependencyType="OnNotSupported"> - document locking and the locking type are indicated in the enclosed tag. The server indicates in response if you are the first to begin working with the document or joining as a co-author.
<SubRequest Type="Cell" SubRequestToken="3"> - bears direct information on document changes. Contains the MS-FSSHTTPB part of the packet.
<SubRequest Type="WhoAmI" SubRequestToken="2"/> - user information.
Example of the MS-FSSHTTP part of the packet from the user to the server (request):
The packet informs that the 2MB.docx is being addressed at the indicated destination and the user is ready to receive the document. BinaryDataSize indicates the value length within the tag, i.e. the MS-FSSHTTPB part.
<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<RequestVersion Version="2" MinorVersion="0"
xmlns="http://schemas.microsoft.com/sharepoint/soap/"/>
<RequestCollection CorrelationId="{010F340A-ACB5-442C-B11E-95CB877EEBA5}"
xmlns="http://schemas.microsoft.com/sharepoint/soap/">
<Request Url="http://moss14/Something/2MB.docx" RequestToken="1">
<SubRequest Type="Cell" SubRequestToken="1">
<SubRequestData PartitionID="383adc0b-e66e-4438-95e6-e39ef9720122" BinaryDataSize="88">
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</SubRequestData>
</SubRequest>
<SubRequest Type="WhoAmI" SubRequestToken="2"/>
<SubRequest Type="Cell" SubRequestToken="3">
<SubRequestData PartitionID="7808f4dd-2385-49d6-b7ce-37aca5e43602" BinaryDataSize="88">
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</SubRequestData>
</SubRequest>
<SubRequest Type="ServerTime" SubRequestToken="4"/>
<SubRequest Type="Cell" SubRequestToken="5">
<SubRequestData GetFileProps="true" BinaryDataSize="88">
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCC
ACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
</SubRequestData>
</SubRequest>
</Request>
</RequestCollection>
</s:Body>
</s:Envelope>
Packet examination
No hint has been found in the specifications of how the beginning of work with the document might be determined. Therefore, the attributes revealed during the packet analysis should be examined against various document types and sizes, a crash-test must be performed. Otherwise, it will be difficult to consider any attribute a true one and the work will hardly be justified. For this reason, all conventional formats with document size up to 30 Mb were examined.
Analysis results are as follows:
- Maximum size of the packet did not exceed 3 Mb, i.e. a 30 Mb file is transferred by 10 packets.
- Mere MS-FSSHTTP analysis cannot be the solution for determination of the document opening (due to Upload Center with caching function), other activities are distinguished.
- Packets with a MS-FSSHTTP part are addressed by http://moss14/_vti_bin/cellstorage.svc/CellStorageService link, others are of no interest in this context. This will be the filter for the HTTP Request analysis.
It is time to familiarize ourselves with the MS-FSSHTTPB protocol. The data is presented in Base64 coding. It should be converted into HEX and binary code to determine the structure. Moreover, BinaryDataSize equals to 88, i.e. 88 values in length, is an “empty” MS-FSSHTTPB part, blank pattern of the MS-FSSHTTPB request. It contains all sections of the MS-FSSHTTPB request. However, there is no information in the sections.
In the context of the two protocols’ roles, MS-FSSHTTP describes the information visible outside the document, i.e. all that can identified without opening the document, while MS-FSSHTTPB informs about what happens inside the document, what changes were made and where in the document they took place. Thus, information coded in the MS-FSSHTTPB part of the packet allows synchronizing co-authors’ documents by sending changed parts of the document only. This considerably reduces the network load. In my opinion, another implementation would not be logical.
Let us consider the line of 88 values which is sent by MS-FSSHTTB protocol.
Source value from the XML tag of MS-FSSHTTB protocol: DAALAJzPKfM5l
AabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigIC
AADaAgYAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
Decoded HEX code (see MS-FSSHTTB specification, pages 71-73):
0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + Sub-request Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Priority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
41 //Knowledge End
0b 01 ac 02 //Sub-Request End + Data Element Packege Start
00 55 03 01 //Reversed+ Daat Emlement Packege End + Cell Request End
At this stage, new iteration and MS-FSSHTTPB analysis are added to the earlier analysis. Omitting tedious examples, below are the results of the analysis:
- Empty packet is a signal of the readiness to receive the document which means it may help to determine the document opening from the server. The key line for the filtering request module is:
SubRequestData GetFileProps="true" BinaryDataSize="88">
however, if the document was cached in the Upload Center, the BinaryDataSize is over 88, i.e. not an empty pattern, since its validity should be checked. To determine such case, another attribute has been found.
- The packet checking the cached document in the Upload Center also contains the line indicated above in this list. However, the BinaryDataSize parameter value depends on the size of the checked Upload Center document. To make it clear, let us consider the packet.
<SubRequestData GetFileProps="true" BinaryDataSize="443">DAALAJz
PKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigI
CAADaAgYAAwAAygIIAAgAgAOEACYCIAD2NXoyYQcURJaGUekAZnpNpAB4KCn1koJCYUFHqgO
vQEOf2v3CNZY9eCgp9ZKCQmFBR6oDr0BDn9r9rj3iPngoKfWSgkJhQUeqA69AQ5/a/fo+JkB
4KCn1koJCYUFHqgOvQEOf2v0+QGpBeCgp9ZKCQmFBR6oDr0BDn9r9gkGeQngmRlDki07gDrG
jv1Ojie167QDOAngmua8bdLEf8U6jv1Ojie167QBmD1ETASYCIAATHwkQgsj7QJiGZTP5NMI
dbAFw0Qz5C0E3b9GZRKbDJyMu3KcRrXsAOAAyADkAMgBGADUAMgA5AC0ANgAxADQAMgAtADQ
ANwA0ADEALQBBAEEAMAAzAC0AQQBGADQAMAA0ADMAOQBGAEQAQQBGAEQAfQAsADMALAAzAAA
AtRMBJgIgAA7pdjoygAxNud3zxlApQz5MASAoDLmvG3SxH/FOo79To4nteu1mDwClEwFBCwG
sAgBVAwE=</SubRequestData>
Decoded HEX code:
0c 00 0b 00 //Protocol Version + Minimum Version
9c cf 29 f3 39 94 06 9b //Signature
06 02 00 00 //CellRequest Start
ee 02 00 00 //User Agent Start
aa 02 20 00 //User Agent GUID
7e b8 31 e7 45 dd aa 44 ab 80 0c 75 fb d1 53 0e //GUID
7a 02 08 00 //User Agent Version
94 29 a1 0f //Version
77 01 16 02 06 00 //User Agent End + Sub-request Start
03 05 //Request DI + Request Type
00 8a 02 02 00 //Prioority + Query Changes
00 da 02 06 00 //Allow Fragments/Reserved + Query Changes Request Argument
03 00 00 //Include Storage Manifest + Cell ID
ca 02 08 00 //Query Changes Data Constraints
08 00 80 03 //Maximum Data Element
84 00 //Knowledge Start
\\ Please note that up the packet has been fully described above
26 02 20 00 //cell knowledge range
f6 35 7a 32 61 07 14 44 96 86 51 e9 00 66 7a 4d //GUID in cell knowlegde range
a4 00 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
c2 35 96 3d 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
ae 3d e2 3e 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
fa 3e 26 40 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
3e 40 6a 41 78 28
29 f5 92 82 42 61 41 47 aa 03 af 40 43 9f da fd
82 41 9e 42 78 26 46 50 e4 8b 4e e0 0e b1 a3 bf 53 a3 89 ed 7a ed 00
ce 02 78 26 //Pre DATA
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before FROM number
00 66 0f //FROM number
51 13 01 26 02 20 00 13 1f 09 10 82 c8 fb 40 98 86 65 33 f9 34 c2 1d 6c
01 70 d1 0c f9 0b 41 37 6f d1 99 44 a6 c3 27 23 2e dc a7 11 ad
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31
00 34 00 32 00 2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00
33 00 2d 00 41 00 46 00 34 00 30 00 34 00 33 00 39 00 46 00 44 00 41
00 46 00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
b5 13 01 26 02 20 00 0e e9 76 3a 32 80 0c 4d b9 dd f3 c6 50 29 43 3e
4c 01 20 28 0c //DATA changeset
b9 af 1b 74 b1 1f f1 4e a3 bf 53 a3 89 ed 7a ed //GUID before TO number
66 0f 00 //To number
a5 //Cell range End
13 01 //Cell End
from now on the packet corresponds to the blank request pattern 41
41 //Knowledge End
0b 01 ac 02 //Sub-Request End + Data Element Packege Start
00 55 03 //Reversed+ Data Emlement Packege End + Cell Request End
It is not a simple task to consider the contents of the cell knowledge range (see the MS-FSSHTTPB specification, page 37). I have identified the repeated bunch of Data + GUID in the code sent up to variable FROM. However, it does not necessarily appear in the packet if the checked file is small. Consequently, this construction cannot be considered as the attribute. With respect to semantics of this construction, similar construction is described in response packets. We can try to explain why response constructions are used in the request packet. However, it is difficult to explain why these constructions are not described in the request specification. Let us now consider the data between variable FROM and variable TO. This is the cornerstone – between words “7b 00” and “b5 13” the content is described by the regular expression “\w{2}[ 00]”, but it should be noted that spaces are for readability only. This attribute was acknowledged in all document tests. Congratulations!
But we can proceed and try to penetrate into the semantic of such a construction. An expert developer can see that the UTF-16 (hex) encoded data is being presented this way. After converting the string:
7b 00 38 00 32 00 39 00 32 00 46 00 35 00 32 00 39 00 2d 00 36 00 31
00 34 00 32 00 2d 00 34 00 37 00 34 00 31 00 2d 00 41 00 41 00 30 00 33
00 2d 00 41 00 46 00 34 00 30 00 34 00 33 00 39 00 46 00 44 00 41 00 46
00 44 00 7d 00 2c 00 33 00 2c 00 33 00 00 00
into UTF-16 (hex), we have got
{8292f529-6142-4741-aa03-af40439fdafd},3,3
So, we can see that in the investigated construction the following parameters are being passed: GUID and two numerical parameters; expressed this way the construction becomes intelligent, and the developer has an opportunity to understand its semantic. We can also assume that GUID is being used to check cached document validity. This version has withstood all the criticism and seems to be very good.
Conclusions
In this article I have tried to consider the joint authorship mechanism in MS Office 2010 + SharePoint at the protocol level. I hope that I have succeeded in giving a simple explanation of certain peculiarities which have not been earlier considered in protocols’ specifications and elsewhere. It should be noted that after my personal examination of MS-FSSHTTP and MS-FSSHTTPB protocols was finished, the MSDN documentation has been supplemented considerably.
In general, the joint authorship mechanism resembles the basic principles of document editing in Unix systems. Differences are not significant enough to call the joint authorship concept innovative. This is my final observation in this article.
Vitaly Knyazev
SharePoint Programmer
MAPLlab Ltd.
Source: MS Office 2010 + SharePoint 2010 Joint Authorship: protocols and packets (in Russian). | 
Support area
