so_4: Версия 4.2.7. Компрессия SOP-трафика

Двоичный SOP-протокол, который использует stdsn-сериализацию ObjESSty не является самым экономичным с точки зрения объема. Конечно, он эфективнее, чем текстовые представления (например, предшествующий текстовый SOP-протокол или основанные на XML методы сериализации), но все же достаточно избыточный.

Объясняется это двумя факторами:

• особенностью стандартной схемы сериализации ObjESSty в случае наличия множества небольших по объему контейнеров (строк, векторов, множеств и т.д.), т.к. для представления длины контейнера используется 4-х байтовое значение. При небольших объемах контейнера старшие 3 байта значения длины, как правило, равны нулю;
• особенностью самого SOP, где необходимо передавать много текстовой информации: имена агентов, имена сообщений, имена полей и т.д.

В результате, в некоторых случаях, по SOP-протоколу передаются SOP-пакеты, лишь незначительно отличающиеся друг от друга. Например, при выдаче во внешний мир мониторинговой информации. Если мониторинговая информация выдается с большим темпом, то это может привести к передаче большего объема SOP-трафика.

Ситуация могла бы быть значительно улучшена, если бы SOP-трафик сжимался на лету. Поэтому в SObjectizer-е версии v.4.2.7 реализована автоматическая компрессия SOP-трафика (пока только с использованием библиотеки zlib).

Когда два SObjectizer-процесса устанавливают SOP-соединение, клиент инициирует процедуру handshake и сообщает серверу, что он может поддержить компрессию SOP-трафика. Если сервер поддерживает процедуру handshake, то он устанавливает у себя режим компрессии и отсылает клиенту ответ. После получения ответа сервера клиент так же включает у себя компрессию, после чего отсылает на сервер информацию о своем SOP-фильтре. Весь трафик между клиентом и сервером, начиная с сообщения о SOP-фильтре, упаковывается на лету.

Если же сервер не поддерживает handshake (например, написан с использованием предыдущей версии SObjectizer-а), то он отвечает клиенту сообщением об ошибке. Клиент, получив вместо ожидаемого ответа на handshake ошибку, понимает, что сервер не может поддерживать компрессию. Клиент отсылает на сервер сообщение о своем SOP-фильтре. Но весь трафик между клиентом и сервером идет так же, как и в предыдущих версиях SObjectizer-а. Таким образом обеспечивается интероперабельность SObjectizer-а версии 4.2.7 с предыдущими версиями SObjectizer-а.

Пока клиент и сервер выполняют процедуру handshake сообщение so_4::rt::comm::msg_client_connected не рассылается. Т.е. на уровне SObjectizer-а соединение считается еще не установленным. На стороне клиента сообщение so_4::rt::comm::msg_client_connected отсылается после того, как клиент отошлет на сервер сообщение о своем SOP-фильтре. На стороне сервера сообщение so_4::rt::comm::msg_client_connected отсылается после того, как сервер получит сообщение о SOP-фильтре клиента.

Технические детали

Для реализации компрессии SOP-трафика в SObjectizer-е был реализован механизм, позволяющий назначать SOP-каналам т.н. трансформаторы трафика (см. so_4::rt::comm::traffic_transformator_t).

В SObjectizer-е версии 4.2.7 реализован только один транформатор, который осуществляет компрессию с использованием библиотеки zlib (http://www.zlib.org). Но, трансформаторы позволяют в будущих версиях реализовать, например:

• криптографическую подпись трафика (для защиты от повреждения данных во время передачи);
• шифрование трафика (например, в случаях, когда нет возможности использовать такие механизмы, как SSL, SSH, VPN и др.).

Для сообщений процедуры handshake (so_4::sop::handshake_info_t, so_4::sop::handshake_resp_info_t) применены возможности ObjESSty v.1.2.0 по поддержке расширяемости сериализуемых типов. То, что типы so_4::sop::handshake_info_t, so_4::sop::handshake_resp_info_t являются расширяемыми, позволяет в будущих версиях SObjectizer-а передавать в процедуре handshake дополнительную информацию. Например, для выбора алгоритма криптографической подписи, для передачи аутентификационной информации, для выбора более оптимальных способов ObjESSty-сериализации и т.д.

---