Collaboration mechanism in MS Office 2010 + SharePoint 2010: protocols and packages
The co-authorship mechanism appeared with the release of MS Office 2010 and SharePoint 2010. Many people describe the emerging functionality as “long awaited”; indeed, there is no sense in diminishing its usability. But this article will discuss how this mechanism functions and what benefits can be derived from this. New field for action in the end!
First of all, it is necessary to pay attention to how the work of the co-authorship mechanism looks. Exploring the Internet, it turned out that it had already been done in sufficient detail, so I will not repeat myself and suggest that you familiarize yourself.
It was interesting for me to understand how the actions of the user correlate with the packages that are formed. Learn to identify actions for forwarding packets. This would allow collecting information on users' work (and in my case, employees) on the corporate portal by writing an HTTP Module. Such information becomes useful, for example, for increasing the number of conversions or tracking the intensity of work on the preparation of documentation. Moreover, practice has shown that it is more efficient and safer to listen to incoming packets to the server, rather than outgoing ones.
Because of the caching of documents, the task is complicated by the fact that the information at the MS-FSSHTTP protocol level ambiguously determines the actions of the user in some cases. For example, when an open document event occurs for the first time — the document is downloaded and described by the package description is easy to determine, and when the document is opened a second time, it does not download the document, but compares it in the cache with the document on the server when it is opened, although semantically these two events mean starting a document.
The collaboration mechanism works successfully in Word 2010, Excel 2010, OneNote 2010, SharePoint Workspace 2010 with SharePoint Foundation 2010 or SharePoint Server 2010. This is specified in the specifications.
')
All communication between the SharePoint server and the MS Office 2010 user takes place using the MS-FSSHTTP (File Synchronization via SOAP over HTTP Protocol Specification) and MS-FSSHTTPB (Binary Requests for File Synchronization via SOAP Protocol Specification) protocols.
For more convenience, I will immediately provide links to the protocol description:
- MSDN about MS-FSSHTTP or download MS-FSSHTTP specification
- MSDN about MS-FSSHTTPB or download MS-FSSHTTPB specification
When exchanging packets, the MS-FSSHTTP protocol transmits information about the entity with which the work begins (its Url), the author who starts working with the entity, the mode of operation (Read Only and Edit require different levels of privileges). The MS-FSSHTTP portion of the packet is XML, which does not add any grace to this protocol. The XML subsections in the package are numbered by the SubRequestToken parameter. It becomes possible to check the integrity of the package using the DependsOn parameter. The very same entity within the MS-FSSHTTP and MS-FSSHTTPB protocols is called a cell.
The MS-FSSHTTP request structure fits into the following pattern:
Some explanations for the structure of the MS-FSSHTTP protocol:
Example of MS-FSSHTTP part of the packet from the user to the server (request):
The package informs you that the 2MB.docx document is being accessed at the specified address and the user is ready to receive the document. BinaryDataSize indicates the length of the value inside the tag, i.e. MS-FSSHTTPB part.
Studying the specifications and did not find the answer to how to determine the beginning of work with the document. Therefore, it is necessary to check the signs of various types and sizes of documents detected during the analysis of packages, arrange a crash-test, otherwise it is difficult to call any sign true, but the work is justified. Therefore, all traditionally used formats were analyzed with document sizes up to 30Mb.
Results of the analysis:
It's time to get acquainted with the MS-FSSHTTPB protocol. The data is presented in Base64 encoding, and to determine the structure, it is necessary to translate into HEX and binary code. Moreover, BinaryDataSize equal to 88 is the “empty” MS-FSSHTTPB part, a pure MS-FSSHTTPB request pattern. It contains all sections of the MS-FSSHTTPB request, but there is no information in the sections.
If we talk about the distribution of roles between the two protocols, MS-FSSHTTP describes information that is visible outside the document, i.e. all that we can find out without opening the file, and MS-FSSHTTPB informs about what is happening inside the document, what changes have been made, where in the document. Thus, the information encoded in the MS-FSSHTTPB parts of the package allows you to synchronize the state of the documents from the co-authors, transferring only the changed parts of the document, thereby significantly reducing the load on the network. True, another implementation, from my point of view, would not be logical.
Consider the MS-FSSHTTB transmitted string, where the value of BinaryDataSize is 88.
Original value from the MS-FSSHTTP XML tag:
Decoded HEX code (see MS-FSSHTTPB Specification p. 71-73):
Now a new iteration and MS-FSSHTTPB analysis is added to the analysis performed earlier. Depriving the reader of the pleasure of tedious examples, I cite the results of the analysis:
For clarity, I will give an example of parsing such a package.
Decoded HEX code:
It is not so easy to analyze the content of the cell knowledge range (see MS-FSSHTTPB p. 37). I selected the repeated Data + GUID binding as part of the code transmitted to the variable FROM, but it is not necessarily present in the package with small sizes of the file being checked, therefore such a construction cannot be considered as a sign. As for the semantics of such a construction, a similar construction is described in the responce packages. We can try to explain why the request packet uses constructs from the responce, but why the description of these constructs is not in the request specification, it is difficult to explain the request. Now pay attention to the data concluded between variable FROM and variable TO. It is here that the cornerstone is located, namely, between the word “7b 00” and “b5 13” content fits into the regular expression “\ w {2} [00]”, but you should not forget that spaces are set only to increase readability. This sign confirmed itself on all tests with documents. Hurray comrades! But you can not stop and try to penetrate the semantics of such a structure. An experienced developer may notice that data in this form is UTF-16 (hex) encoded. Converting stock
in UTF-16 (hex) we get
As a result, it is found that in the design under study the parameters are transferred: GUID and two numerical parameters, which makes the construction meaningful and even allows the developer to try to understand its semantics. It can be assumed that the GUID is used to check the cached document for validity. This version has so far withstood all possible criticism and seems very successful!
In this article I tried to highlight the mechanism of co-authorship in MS Office 2010 + SharePoint 2010 at the level of the protocols. I hope I have managed to lucidly explain some features that are not covered in the specifications of the protocols and which have not been previously paid attention to. It should be noted that since the end of my personal investigation into the work of the MS-FSSHTTP and MS-FSSHTTPB protocols, the documentation on MSDN has been greatly enhanced.
In general, the work of co-authors is very similar to the basic principles of editing documents in Unix-systems. The differences are not so significant as to call the co-authorship mechanism innovative. I would like to finish this article with this thought.
I wish you interesting research!
Source Code Highlighter .
Interesting to the user
First of all, it is necessary to pay attention to how the work of the co-authorship mechanism looks. Exploring the Internet, it turned out that it had already been done in sufficient detail, so I will not repeat myself and suggest that you familiarize yourself.
Interesting to the developer
It was interesting for me to understand how the actions of the user correlate with the packages that are formed. Learn to identify actions for forwarding packets. This would allow collecting information on users' work (and in my case, employees) on the corporate portal by writing an HTTP Module. Such information becomes useful, for example, for increasing the number of conversions or tracking the intensity of work on the preparation of documentation. Moreover, practice has shown that it is more efficient and safer to listen to incoming packets to the server, rather than outgoing ones.
Because of the caching of documents, the task is complicated by the fact that the information at the MS-FSSHTTP protocol level ambiguously determines the actions of the user in some cases. For example, when an open document event occurs for the first time — the document is downloaded and described by the package description is easy to determine, and when the document is opened a second time, it does not download the document, but compares it in the cache with the document on the server when it is opened, although semantically these two events mean starting a document.
The collaboration mechanism works successfully in Word 2010, Excel 2010, OneNote 2010, SharePoint Workspace 2010 with SharePoint Foundation 2010 or SharePoint Server 2010. This is specified in the specifications.
')
Protocols and Packages
All communication between the SharePoint server and the MS Office 2010 user takes place using the MS-FSSHTTP (File Synchronization via SOAP over HTTP Protocol Specification) and MS-FSSHTTPB (Binary Requests for File Synchronization via SOAP Protocol Specification) protocols.
For more convenience, I will immediately provide links to the protocol description:
- MSDN about MS-FSSHTTP or download MS-FSSHTTP specification
- MSDN about MS-FSSHTTPB or download MS-FSSHTTPB specification
When exchanging packets, the MS-FSSHTTP protocol transmits information about the entity with which the work begins (its Url), the author who starts working with the entity, the mode of operation (Read Only and Edit require different levels of privileges). The MS-FSSHTTP portion of the packet is XML, which does not add any grace to this protocol. The XML subsections in the package are numbered by the SubRequestToken parameter. It becomes possible to check the integrity of the package using the DependsOn parameter. The very same entity within the MS-FSSHTTP and MS-FSSHTTPB protocols is called a cell.
The MS-FSSHTTP request structure fits into the following pattern:
< s:Envelope xmlns:s ="http://schemas.xmlsoap.org/soap/envelope/" >
< s:Body >
< RequestVersion … > //
< RequestCollection … > // CorrelationID, guid
// .
< Request … > // URL
< SubRequest … /> //
</ SubRequest >
…
</ Request >
</ RequestCollection >
</ s:Body >
</ s:Envelope >
Some explanations for the structure of the MS-FSSHTTP protocol:
< Request Url ="http://serverName/documentFullPath" RequestToken ="1" >
< SubRequest Type ="Coauth" SubRequestToken ="1" >
< SubRequest Type ="SchemaLock" SubRequestToken ="2" DependsOn ="1" DependencyType ="OnNotSupported" >
< SubRequest Type ="Cell" SubRequestToken ="3" >
< SubRequest Type ="WhoAmI" SubRequestToken ="2" />
Example of MS-FSSHTTP part of the packet from the user to the server (request):
The package informs you that the 2MB.docx document is being accessed at the specified address and the user is ready to receive the document. BinaryDataSize indicates the length of the value inside the tag, i.e. 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 inspection
Studying the specifications and did not find the answer to how to determine the beginning of work with the document. Therefore, it is necessary to check the signs of various types and sizes of documents detected during the analysis of packages, arrange a crash-test, otherwise it is difficult to call any sign true, but the work is justified. Therefore, all traditionally used formats were analyzed with document sizes up to 30Mb.
Results of the analysis:
- The maximum packet size does not exceed 3MB, that is, a 30MB file is transferred in 10 packets.
- Only by analyzing MS-FSSHTTP you cannot solve the problem of determining the opening of a document (due to the work of the Upload Center with the caching function), the remaining actions are determined.
- Packages with MS-FSSHTTP-parts refer to the link moss14 / _vti_bin / cellstorage.svc / CellStorageService , the rest are not interesting in this task. That is, it will be a filter for analyzing HTTP Request.
It's time to get acquainted with the MS-FSSHTTPB protocol. The data is presented in Base64 encoding, and to determine the structure, it is necessary to translate into HEX and binary code. Moreover, BinaryDataSize equal to 88 is the “empty” MS-FSSHTTPB part, a pure MS-FSSHTTPB request pattern. It contains all sections of the MS-FSSHTTPB request, but there is no information in the sections.
If we talk about the distribution of roles between the two protocols, MS-FSSHTTP describes information that is visible outside the document, i.e. all that we can find out without opening the file, and MS-FSSHTTPB informs about what is happening inside the document, what changes have been made, where in the document. Thus, the information encoded in the MS-FSSHTTPB parts of the package allows you to synchronize the state of the documents from the co-authors, transferring only the changed parts of the document, thereby significantly reducing the load on the network. True, another implementation, from my point of view, would not be logical.
Consider the MS-FSSHTTB transmitted string, where the value of BinaryDataSize is 88.
Original value from the MS-FSSHTTP XML tag:
DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAg<br>YAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==
Decoded HEX code (see MS-FSSHTTPB Specification p. 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 + SubRequest 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 //SubRequest End + Data Element Packege Start
00 55 03 01 //Reversed + Data Emlement Packege End + Cell Request End
Now a new iteration and MS-FSSHTTPB analysis is added to the analysis performed earlier. Depriving the reader of the pleasure of tedious examples, I cite the results of the analysis:
- 1. An empty packet is a signal of readiness to receive a document, and therefore helps to determine the event of opening a document from the server. The key line for the filtering request module becomes:
< SubRequestData GetFileProps ="true" BinaryDataSize ="88" >
however, if the document was cached in the Upload Center, then the BinaryDataSize is greater than 88, i.e. It will not be an empty template, because you need to check the document for validity. To identify such a case was found another sign. - 2. The package verifying the cached document in the Upload Center also contains the string specified in item 1 of this list. However, the value of the BinaryDataSize parameter is the greater, the larger the reconcilable document from the Upload Center.
For clarity, I will give an example of parsing such a package.
< SubRequestData GetFileProps ="true" BinaryDataSize ="443" > DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+
9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEACYCIAD2NXoyYQc
URJaGUekAZnpNpAB4KCn1koJCYUFHqgOvQEOf2v3CNZY9eCgp9ZKCQmFBR6oDr0BDn9r9r
j3iPngoKfWSgkJhQUeqA69AQ5/a/fo+JkB4KCn1koJCYUFHqgOvQEOf2v0+
QGpBeCgp9ZKCQmFBR6oDr0BDn9r9gkGeQngmRlDki07gDrGjv1Ojie167QDOAngmua8bdL
Ef8U6jv1Ojie167QBmD1ETASYCIAATHwkQgsj7QJiGZTP5NMIdbAFw0Qz5C0E3b9GZRKbD
JyMu3KcRrXsAOAAyADkAMgBGADUAMgA5AC0ANgAxADQAMgAtADQANwA0ADEALQBBAEEAMA
AzAC0AQQBGADQAMAA0ADMAOQBGAEQAQQBGAEQAfQAsADMALAAzAAAAtRMBJgIgAA7pdjoy
gAxNud3zxlApQz5MASAoDLmvG3SxH/FOo79To4nteu1mDwClEwFBCwGsAgBVAwE= </ 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 + SubRequest 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
\\ ,
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
//
41 //Knowledge End
0b 01 ac 02 //SubRequest End + Data Element Packege Start
00 55 03 //Reversed + Data Emlement Packege End + Cell Request End
It is not so easy to analyze the content of the cell knowledge range (see MS-FSSHTTPB p. 37). I selected the repeated Data + GUID binding as part of the code transmitted to the variable FROM, but it is not necessarily present in the package with small sizes of the file being checked, therefore such a construction cannot be considered as a sign. As for the semantics of such a construction, a similar construction is described in the responce packages. We can try to explain why the request packet uses constructs from the responce, but why the description of these constructs is not in the request specification, it is difficult to explain the request. Now pay attention to the data concluded between variable FROM and variable TO. It is here that the cornerstone is located, namely, between the word “7b 00” and “b5 13” content fits into the regular expression “\ w {2} [00]”, but you should not forget that spaces are set only to increase readability. This sign confirmed itself on all tests with documents. Hurray comrades! But you can not stop and try to penetrate the semantics of such a structure. An experienced developer may notice that data in this form is UTF-16 (hex) encoded. Converting stock
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 <br>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 <br>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 00in UTF-16 (hex) we get
{8292f529-6142-4741-aa03-af40439fdafd},3,3As a result, it is found that in the design under study the parameters are transferred: GUID and two numerical parameters, which makes the construction meaningful and even allows the developer to try to understand its semantics. It can be assumed that the GUID is used to check the cached document for validity. This version has so far withstood all possible criticism and seems very successful!
Conclusion
In this article I tried to highlight the mechanism of co-authorship in MS Office 2010 + SharePoint 2010 at the level of the protocols. I hope I have managed to lucidly explain some features that are not covered in the specifications of the protocols and which have not been previously paid attention to. It should be noted that since the end of my personal investigation into the work of the MS-FSSHTTP and MS-FSSHTTPB protocols, the documentation on MSDN has been greatly enhanced.
In general, the work of co-authors is very similar to the basic principles of editing documents in Unix-systems. The differences are not so significant as to call the co-authorship mechanism innovative. I would like to finish this article with this thought.
I wish you interesting research!
Source Code Highlighter .
Source: https://habr.com/ru/post/101859/
All Articles