Механизм соавторства появился с выходом MS Office 2010 и SharePoint 2010. Появившуюся функциональность многие называют как «давно ожидаемую», действительно, приуменьшать удобство её использования смысла нет. Но в данной статье речь пойдет о том, как этот механизм функционирует и какую пользу из этого можно извлечь. Новое поле для деятельности в конце концов!

Интересное пользователю

В первую очередь необходимо уделить внимание тому, как выглядит работа механизма соавторства. Исследуя просторы интернета, оказалось, что достаточно подробно это уже сделали, поэтому я не буду повторяться и предлагаю ознакомиться самим.

Интересное разработчику

Мне было интересно разобраться в том, как соотносятся действия пользователя и формируемые при этом пакеты. Научиться определять действия по пересылаемым пакетам. Это позволило бы собирать информацию по работе пользователей (а в моем случае – сотрудников) на корпоративном портале, написав HTTP Module. Такая информация становится полезной, к примеру, для увеличивая количество конверсий или отслеживании интенсивности работ по подготовки документации. Причем практика показала, что эффективнее и безопаснее прослушивать входящие на сервер пакеты, а не исходящие.

Из-за кэширования документов, задача усложняется тем, что информация на уровне протокола MS-FSSHTTP неоднозначно определяет действия пользователя в некоторых случаях. Например, когда происходит событие открытия документа впервые — идет скачивание документа и по описанию пакета это легко определить, а когда документ открывается вторично, то происходит не скачивание документа, а сравнение его в кэше с документом на сервере при его открытии, хотя семантически эти два события означают начало работы с документом.
Механизм соавторства успешно работает в Word 2010, Excel 2010, OneNote 2010, SharePoint Workspace 2010 c SharePoint Foundation 2010 или SharePoint Server 2010. Это указанно в спецификациях.

Протоколы и пакеты

Все сообщение между сервером SharePoint и пользователем MS Office 2010 происходит по средству использования протоколов MS-FSSHTTP (File Synchronization via SOAP over HTTP Protocol Specification) и MS-FSSHTTPB (Binary Requests for File Synchronization via SOAP Protocol Specification).
Для большего удобства сразу приведу ссылки на описание протоколов:
— MSDN о MS-FSSHTTP или скачать спецификацию по MS-FSSHTTP
— MSDN о MS-FSSHTTPB или скачать спецификацию по MS-FSSHTTPB

При обмене пакетами протокол MS-FSSHTTP передает информацию о сущности, с которой начинается работа (её Url), авторе, который приступает к работе с сущностью, режиме работы (Read Only и Edit требуют разного уровня привилегий). MS-FSSHTTP-часть пакета представляет собой XML, что не добавляет этому протоколу какого-то изящества. Подраздлы XML в пакете нумеруются параметром SubRequestToken. Становится возможна проверка целостности пакета при помощи параметра DependsOn. Сама же сущность в рамках протоколов MS-FSSHTTP и MS-FSSHTTPB называется cell.
Структура запроса MS-FSSHTTP укладывается в следующий шаблон:

<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>

Некоторые пояснения к структуре протокола MS-FSSHTTP:

<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">

— несет непосредственную информацию о изменениях в документе. Содержит в себе MS-FSSHTTPB часть пакета.

<SubRequest Type="WhoAmI" SubRequestToken="2"/>

— информация о пользователе.

Пример MS-FSSHTTP части пакета от пользователя к серверу (request):
Пакет сообщает о том, что идет обращение к документу 2MB.docx по указанному адресу и пользователь готов получить документ. BinaryDataSize указывает длинну значения внутри тега, т.е. MS-FSSHTTPB часть.

<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>

Исследование пакетов

Изучая спецификации так и не нашелся ответ на то, как определять начало работы с документом. Поэтому необходимо выявленные при анализе пакетов признаки проверить при различных типах и размерах документов, устроить crash-test, иначе трудно назвать любой признак правдивым, а работу оправданной. Поэтому были проанализированы все традиционно используемые форматы при размерах докуметов до 30Мб.
Итоги анализа:

Максимальный размер пакета не превышает 3Мб, то есть 30Мб файл передается за 10 пакетов.
Только анализируя MS-FSSHTTP нельзя решить задачу определения открытия документа (из-за работы Upload Center с функцией кэширования), остальные действия определяются.
Пакеты с MS-FSSHTTP-частью обращаются по ссылке moss14/_vti_bin/cellstorage.svc/CellStorageService, остальные не интересны в данной задаче. То есть это будет фильтром для анализа HTTP Request’а.

Пора знакомиться с протоколом MS-FSSHTTPB. Данные представленны в кодировке Base64, а для определения структуры необходимо переводить в HEX и бинарный код. Причем BinaryDataSize равная 88 – это «пустая» MS-FSSHTTPB-часть, чистый шаблон MS-FSSHTTPB запроса. В нем присутствуют все разделы MS-FSSHTTPB запроса, но в разделах нет никакой информации.
Если говорить о распределении ролей между двумя протоколами, то MS-FSSHTTP описывает информацию которая видна снаружи документа, т.е. все что мы сможем узнать не открывая файл, а MS-FSSHTTPB информирует о том, что происходит внутри документа, какие изменения сделаны, в каком месте документа. Таким образом, информация закодированная в MS-FSSHTTPB части пакета позволяет синхронизировать состояния документов у соавторов, передавая только измененные части документа, тем самым значительно снижая нагрузку на сеть. Правда другая реализация, с моей точки зрения, была бы и не логична.
Рассмотрим передаваемую по протоколу MS-FSSHTTB строку, где значенеи BinaryDataSize равно 88.
Исходное значение из XML тега протокола MS-FSSHTTP:

DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAg<br>YAAwAAygIIAAgAgAOEAEELAawCAFUDAQ==

Декодированный HEX-код (см. Спецификацию MS-FSSHTTPB стр. 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

Теперь в анализ, проведенный ранее добавляется новая итерация и анализ MS-FSSHTTPB. Лишая читателя удовольствия нудных примеров, привожу результаты анализа:

1. Пустой пакет является сигналом о готовности получать документ, а значит помогает определять событие открытия документа с сервера. Ключевой строчкой для фильтрующего request модуля становится:

<SubRequestData GetFileProps="true" BinaryDataSize="88">

однако если документ был закэширован в Upload Center, то BinaryDataSize больше 88, т.е. будет не пустым шаблоном, потому что необходимо проверить документ на валидность. Для определения такого случая был найден другой признак.
2. Пакет проверяющий кэшированный документ в Upload Center также содержит строку, указанную в п.1 данного списка. Однако значение параметра BinaryDataSize тем больше, чем больше сверяемый документ из Upload Center.

Для наглядности приведу пример разбора такого пакета.

<SubRequestData GetFileProps="true" BinaryDataSize="443">DAALAJzPKfM5lAabBgIAAO4CAACqAiAAfrgx50XdqkSrgAx1+ 9FTDnoCCACUKaEPdwEWAgYAAwUAigICAADaAgYAAwAAygIIAAgAgAOEACYCIAD2NXoyYQc URJaGUekAZnpNpAB4KCn1koJCYUFHqgOvQEOf2v3CNZY9eCgp9ZKCQmFBR6oDr0BDn9r9r j3iPngoKfWSgkJhQUeqA69AQ5/a/fo+JkB4KCn1koJCYUFHqgOvQEOf2v0+ QGpBeCgp9ZKCQmFBR6oDr0BDn9r9gkGeQngmRlDki07gDrGjv1Ojie167QDOAngmua8bdL Ef8U6jv1Ojie167QBmD1ETASYCIAATHwkQgsj7QJiGZTP5NMIdbAFw0Qz5C0E3b9GZRKbD JyMu3KcRrXsAOAAyADkAMgBGADUAMgA5AC0ANgAxADQAMgAtADQANwA0ADEALQBBAEEAMA AzAC0AQQBGADQAMAA0ADMAOQBGAEQAQQBGAEQAfQAsADMALAAzAAAAtRMBJgIgAA7pdjoy gAxNud3zxlApQz5MASAoDLmvG3SxH/FOo79To4nteu1mDwClEwFBCwGsAgBVAwE=</SubRequestData>

Декодированный HEX-код:

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

Подробнее разобрать содержание cell knowledge range (см спецификацию MS-FSSHTTPB стр. 37) не так просто. Я выделил в составе кода, передоваемого до variable FROM повторяющуюся связку Data + GUID, но она не обязательно присутствует в пакете при небольших размерах проверяемого файла, поэтому такую конструкцию за признак считать нельзя. Что касается семантики такой конструкции, то похожая конструкция описывается в пакетах responce. Можно попытаться объяснить почему в request пакете используются конструкции из responce, но почему описания этих конструкций нет в спецификации request запроса объяснить трудно. Теперь обратим внимание на данные заключенные между variable FROM и variable TO. Именно тут находится краеугольный камень, а именно между словом «7b 00» и «b5 13» содержимое укладывается в регулярное выражение “\w{2}[ 00]”, но не стоит забывать что пробелы поставлены только для повышения читабельности. Этот признак подтвердил себя на всех тестах с документами. Ура товарищи! Но можно не останавливаться и попробовать проникнуть в семантику такой конструкции. Опытный разработчик может заметить, что в таком виде представляются данные с кодировкой UTF-16 (hex). Преобразовав стоку

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 00

в UTF-16 (hex) получаем

{8292f529-6142-4741-aa03-af40439fdafd},3,3

В результате обнаруживается, что в исследуемой конструкции передаются параметры: GUID и два численных параметра, что делает конструкцию осмысленной и даже дает возможность разработчику попытаться понять её семантику. Можно предположить, что GUID используется для проверки закэшированного документа на валидность. Такая версия пока выдержала всю возможную критику и кажется весьма удачной!

Заключение

В этой статье я постарался осветить механизм соавторства в MS Office 2010 + SharePoint 2010 на уровне работы протоколов. Надеюcь у меня получилось доходчиво объяснить некоторые особенности, которые не освещены в спецификациях протоколов и которым ранее не уделялось внимания. Нужно отметить, что с момента конца моего личного расследования в работе протоколов MS-FSSHTTP и MS-FSSHTTPB документация на MSDN существенно дополнилась.

В целом работа соавторства очень напоминает базовые принципы работы по редактированию документов в Unix-системах. Различия не столь существенные, чтобы назвать механизм соавторства инновационным. Этой мыслью и хотелось бы закончить статью.

Желаю вам интересных исследований!

Source code in this article was highlighted with Source Code Highlighter.

Механизм соавторства в MS Office 2010 + SharePoint 2010: протоколы и пакеты