Статья:
RPC своими руками, или макросы наносят ответный удар

Автор(ы): Andrew Solodovnikov, Mike Kostuyhin
Дата: 28.12.2008
Мы не проводили социологических исследований, но и без них очевидно, что C++-программисты в большинстве случаев предпочтут написать все, начиная чуть ли не с ОС. Библиотеки, которые широко используются, можно пересчитать по пальцам одной руки. Поэтому неудивительно, что в интернете можно найти целую кучу реализаций RPC, похожих на Microsoft DCOM. Данная статья, на первый взгляд, выглядит еще одной реализацией библиотеки удаленного доступа к объектам, однако данная библиотека обладает рядом особенностей, делающих ее описание заслуживающим внимания. Ее отличают от других высокая производительность, возможность легкой смены транспортного уровня, реализация без использования внешних утилит и совместимость со старыми компиляторами, например, VC++ 6.

Авторы:
Andrew Solodovnikov, Mike Kostuyhin

Аннотация:
Мы не проводили социологических исследований, но и без них очевидно, что C++-программисты в большинстве случаев предпочтут написать все, начиная чуть ли не с ОС. Библиотеки, которые широко используются, можно пересчитать по пальцам одной руки. Поэтому неудивительно, что в интернете можно найти целую кучу реализаций RPC, похожих на Microsoft DCOM. Данная статья, на первый взгляд, выглядит еще одной реализацией библиотеки удаленного доступа к объектам, однако данная библиотека обладает рядом особенностей, делающих ее описание заслуживающим внимания. Ее отличают от других высокая производительность, возможность легкой смены транспортного уровня, реализация без использования внешних утилит и совместимость со старыми компиляторами, например, VC++ 6.

Здравствуйте, Andrew Solodovnikov, Mike Kostuyhin

Заметил в тексте следующие опечатки:
"Это позволит вам понять, во _сто_ преобразуется приведенное выше абстрактное описание." -- во что
"используется метапрограммирование на шаблонах C++, перегруженные функции и сами по _сбе_ шаблоны" -- сами по себе

E>Заметил в тексте следующие опечатки:
E>"Это позволит вам понять, во _сто_ преобразуется приведенное выше абстрактное описание." -- во что
E>"используется метапрограммирование на шаблонах C++, перегруженные функции и сами по _сбе_ шаблоны" -- сами по себе

Спасибо за отклик. Вероятно, указанные вами ошибки в варианте на сайте уже поправлены. В оригинальном (то бишь, том финальном тексте, коий я имею возможность лицезреть у себя) первой фразы вообще нет А вторая выглядит у меня так:

В данном случае нет никаких причин не использовать в качестве основного средства реализации маршаллинга/демаршаллинга параметров стандартные средства метапрограммирования – шаблоны и перегрузки функций.

Сравните с тем, что там сейчас:

Для реализации маршаллинга/демаршаллинга параметров в нашей библиотеке используется метапрограммирование на шаблонах C++, перегруженные функции и сами по себе шаблоны.

Как обычно у программеров — исправляем одну багу, вносим две
Как по мне — исправленный вариант "звучит" не очень, да и в грамматике ошибочка — там должно быть тире, а не запятая. Да и зачем было таким образом исправлять оригинальную фразу... К сожалению, об этом и других изменениях меня не уведомили .

PS
А по поводу наших ошибок — их там есть, куда ж без них Например, фраза "реализация требования (2) " должна быть "реализация требования (3) ". Вот это действительно надо бы поправить.

Здравствуйте, Andrew S, Вы писали:

AS>Спасибо за отклик.

Не за что. Было очень интересно увидеть, что вам удалось сделать с помощью макросов и шаблонов. Так что спасибо за статью.

В качестве небольшой критики: вы в заключении говорите, что ваш RPC показывает достаточно хорошую производительность. Значит вы делали замеры. И было бы интересно увидеть их результаты. Например, в сравнении с CORBA-реализациями (тем же TAO и OmniORB). Имхо, от этого статья бы выиграла.

E>В качестве небольшой критики: вы в заключении говорите, что ваш RPC показывает достаточно хорошую производительность. Значит вы делали замеры. И было бы интересно увидеть их результаты. Например, в сравнении с CORBA-реализациями (тем же TAO и OmniORB). Имхо, от этого статья бы выиграла.

Замеры есть, правда, не с орбами, а с комом, пайпами, MMF. Corba довольно сильно сливает кому при межпроцессном взаимодействии в пределах одной машины. Более того, большинство замеров было сделано _до_ принятия решения о необходимости реализации собственного велосипеда. Об этом в статье пара строк есть в самом начале. Приводить результаты в статье я смысла не увидел, поскольку подобные замеры при желании доступны из отдельных источников. Навскидку, например, тут: http://www.rsdn.ru/article/baseserv/lpc.xml

Автор(ы): Леошкевич Илья
Дата: 23.06.2006
Данная статья является обзором недокументированного механизма LPC, в ней продемонстрированы основные моменты, необходимые для реализации простейших LPC-клиента и LPC-сервера. LPC как механизм передачи сообщений не всегда превосходит свои аналоги – именованные каналы, сокеты, синхронизированный доступ к разделяемой памяти, и т.д. И всё же, могут возникнуть ситуации, когда его использование выглядит достаточно привелекательным – идеальным примером явлется передача данных по инициативе драйвера пользовательскому приложению.

(понятно, что результаты там для одного паттерна, но на самом деле, как оказалось, в плане латентности результат характерен).

Возможно, хорошая мысль написать отдельную статью по поводу производительности механизмов RPC, включая и DRPC в том числе. Тем более статистика у нас есть. Нет только времени

PS
По поводу различных орб — пришлось тут тестировать в различных нагруженных паттернах TAO и OMNIOrb. В компании с ними еще и ICE был. Если интересно, могу рассказать.

Здравствуйте, Andrew S, Вы писали:

AS>Навскидку, например, тут: http://www.rsdn.ru/article/baseserv/lpc.xml

Автор(ы): Леошкевич Илья
Дата: 23.06.2006
Данная статья является обзором недокументированного механизма LPC, в ней продемонстрированы основные моменты, необходимые для реализации простейших LPC-клиента и LPC-сервера. LPC как механизм передачи сообщений не всегда превосходит свои аналоги – именованные каналы, сокеты, синхронизированный доступ к разделяемой памяти, и т.д. И всё же, могут возникнуть ситуации, когда его использование выглядит достаточно привелекательным – идеальным примером явлется передача данных по инициативе драйвера пользовательскому приложению.

(понятно, что результаты там для одного паттерна, но на самом деле, как оказалось, в плане латентности результат характерен).

Это статью я не читал.

AS>PS
AS>По поводу различных орб — пришлось тут тестировать в различных нагруженных паттернах TAO и OMNIOrb. В компании с ними еще и ICE был. Если интересно, могу рассказать.

Насколько я помню, при обсуждении проблем библиотеки ACE

Автор: Andrew S
Дата: 22.03.08

вы упоминали, что TAO сливает по производительности OMNIOrb. Но увидеть конкретные цифры было бы интересно.

AS>>Навскидку, например, тут: http://www.rsdn.ru/article/baseserv/lpc.xml

Автор(ы): Леошкевич Илья
Дата: 23.06.2006
Данная статья является обзором недокументированного механизма LPC, в ней продемонстрированы основные моменты, необходимые для реализации простейших LPC-клиента и LPC-сервера. LPC как механизм передачи сообщений не всегда превосходит свои аналоги – именованные каналы, сокеты, синхронизированный доступ к разделяемой памяти, и т.д. И всё же, могут возникнуть ситуации, когда его использование выглядит достаточно привелекательным – идеальным примером явлется передача данных по инициативе драйвера пользовательскому приложению.

(понятно, что результаты там для одного паттерна, но на самом деле, как оказалось, в плане латентности результат характерен).

E>Это статью я не читал.

AS>>PS
AS>>По поводу различных орб — пришлось тут тестировать в различных нагруженных паттернах TAO и OMNIOrb. В компании с ними еще и ICE был. Если интересно, могу рассказать.

E>Насколько я помню, при обсуждении проблем библиотеки ACE

Автор: Andrew S
Дата: 22.03.08

вы упоминали, что TAO сливает по производительности OMNIOrb. Но увидеть конкретные цифры было бы интересно.

Да, было такое. Конкретные цифры — я узнаю, можно ли опубликовать данные исследования, и если да, приведу точные цифры. Если без точных цифр — то действительно, TAO очень сильно уступала omniORB. Как в тестах латентности, так и в нагрузочной способности. В разы... При этом загрузка CPU на серверной машине была тоже в разы выше. В свою очередь, omniORB и ICE в сходных режимах использования примерно сравнимы, обычно даже omniORB чуточку выигрывала...

Здравствуйте, Andrew S, Вы писали:

AS>Как обычно у программеров — исправляем одну багу, вносим две
AS>Как по мне — исправленный вариант "звучит" не очень, да и в грамматике ошибочка — там должно быть тире, а не запятая.

Я бы двоеточие поставил.

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

Если что -- это не я
Я бы уведомил обязательно.

А таки все же. Вы опубликуете результаты тестов сравнительной производительности (CORBA, ICE etc)?

T>А таки все же. Вы опубликуете результаты тестов сравнительной производительности (CORBA, ICE etc)?

Пока что думаю над этим отностительно DRPC
А результаты латентности пустого вызова для RPC фреймоворков приведу сейчас:

mmf: 1.15953e-005
pipe: 1.97627e-005
com1: 2.9115e-005
com2: 2.68456e-005
tcp: 4.32281e-005
rpclib: 9.94192e-006

Итого — rpclib _быстрее_ raw реализации на MMF (правда, к ней есть вопросы — там можно и поэффективнее сделать). Но и быстрее raw реалзации на пайпах — вот что значит правильная буферизация

Пояснения.
rpclib — транспорт MFC archive + pipes.
com1 — стаблесс прокси (/Oicf)
com2 — прокси-стаб.

Секурити настраивался следующим образом:

CoInitializeSecurity(NULL, 
                                -1, 
                                NULL, 
                                NULL,
                                RPC_C_AUTHN_LEVEL_NONE, 
                                RPC_C_IMP_LEVEL_IMPERSONATE, 
                                NULL, 
                                EOAC_NONE, 
                                0
                               )

хотя на производительность это и не сильно влияло.

По поводу DRPC.
Если интересно, zeroc выпустили интересный документ http://www.zeroc.com/articles/IcePerformanceWhitePaper.pdf
В нем, в частности, подтверждаются наши выводы относительно производительности С++ реализации пула потоков в ICE (в том смысле, что она никакая). Для сравнения — в TAO мы получили даже еще худшие результаты, особенно в плане масштабируемости. Повторюсь, что лучшее в плане латентности и масштабируемости для С++ "из ремотинга нахаляву" — это omniORB. Но там неудачная модель взаимодействия с С++, впрочем, это проблемы стандарта, а не реализации... Когда/если айсовцы выпустят 3.4, где уже будет IOCP — тогда ICE будет весьма вкусной альтернативой ремотингу под вындовс.

Свежую версию библиотеки сейчас и далее можно будет взять по адресу http://files.rsdn.ru/8583/RPCLib.ZIP

T>А таки все же. Вы опубликуете результаты тестов сравнительной производительности (CORBA, ICE etc)?

Вдогонку. По поводу корбы — вот более-менее похожие на правду тесты: http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare_ipc.html

Здравствуйте, Andrew S, Вы писали:

AS>Пока что думаю над этим отностительно DRPC
AS>А результаты латентности пустого вызова для RPC фреймоворков приведу сейчас:
...skipped...
AS>Итого — rpclib _быстрее_ raw реализации на MMF (правда, к ней есть вопросы — там можно и поэффективнее сделать). Но и быстрее raw реалзации на пайпах — вот что значит правильная буферизация

А Вы не задумывались над тем, что довольно бессмысленно сравнивать задержки на пустом вызове?

1. Если вызов делает что-то полезное больше чем перемножение двух чисел, то задержка на время работы тела такого метода будет более существенной, чем затраты на его вызов. Иначе, код просто должен быть перенесен на клиента, чтобы не вносить ненужных задержек.
   
2. Задержка на передачу данных по сети опять-таки будет перекрывать Ваши оптимизации по маршалингу, если Вы конечно сделаете эти оптимизации.
   
3. Ваша реализация RPC пойдет прахом прямо сейчас при попытке связать две машины разных архитектур (x86<=>x64, BigEndian<=>LittleEndian, etc.).
   
4. Простой обычный COM позволяет передавать правильно описанные буфера памяти, при этом маршалит их наиболее оптимально в зависимости от "расстояния" между клиентом и сервером (внутри одного процесса — одна и та же память, передает указатель; между процессами — либо передает указатель на разделяемую память, либо автоматически аллокирует/деаллокирует буфера; между машинами — автоматически аллокирует/деаллокирует буфера).

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

AS>>Пока что думаю над этим отностительно DRPC
AS>>А результаты латентности пустого вызова для RPC фреймоворков приведу сейчас:
A>...skipped...
AS>>Итого — rpclib _быстрее_ raw реализации на MMF (правда, к ней есть вопросы — там можно и поэффективнее сделать). Но и быстрее raw реалзации на пайпах — вот что значит правильная буферизация

A>А Вы не задумывались над тем, что довольно бессмысленно сравнивать задержки на пустом вызове?

Я много над чем задумывался Далее по пунктам.

A>

Если вызов делает что-то полезное больше чем перемножение двух чисел, то задержка на время работы тела такого метода будет более существенной, чем затраты на его вызов. Иначе, код просто должен быть перенесен на клиента, чтобы не вносить ненужных задержек.

Прочитайте статью. Там мотивация описана.

A>

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

Прочитайте статью. Там про межпроцессное взаимодействие в основном в пределах одной машины.

A>

Ваша реализация RPC пойдет прахом прямо сейчас при попытке связать две машины разных архитектур (x86<=>x64, BigEndian<=>LittleEndian, etc.).

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

A>

Простой обычный COM позволяет передавать правильно описанные буфера памяти, при этом маршалит их наиболее оптимально в зависимости от "расстояния" между клиентом и сервером (внутри одного процесса — одна и та же память, передает указатель; между процессами — либо передает указатель на разделяемую память, либо автоматически аллокирует/деаллокирует буфера; между машинами — автоматически аллокирует/деаллокирует буфера).

И здесь ровно то же самое. Только еще более оптимально.

A>Ваша библиотека создана для работы сферического коня в вакууме.

Это не так. Библиотека используется в нескольких проектах, где важна минимальная задержка при взаимодействии процессов.

A>Это неразумно по меньшей мере.
A>И вообще, я удивлен и обескуражен количеством людей, занимающихся изобретением велосипедов.

Это ваши проблемы. Используйте com, corba и т.п. Кто вам мешает? Для меня это было неприемлемо — тащит за собой кучу хлама, работает медленно, использовать неудобно. RPCLib решает совсем другие задачи, чем существующие "тяжелые" фреймворки.

В общем, спасибо за отзыв, но, имхо, вы вне контекста задачи...

AS>Это ваши проблемы. Используйте com, corba и т.п. Кто вам мешает? Для меня это было неприемлемо — тащит за собой кучу хлама, работает медленно, использовать неудобно. RPCLib решает совсем другие задачи, чем существующие "тяжелые" фреймворки.


насчет хлама... библиотека не выживет без mfc?
хотел заиспользовать, но надо оценить затраты на фасад, чтобы выключить MFC

AS>>Это ваши проблемы. Используйте com, corba и т.п. Кто вам мешает? Для меня это было неприемлемо — тащит за собой кучу хлама, работает медленно, использовать неудобно. RPCLib решает совсем другие задачи, чем существующие "тяжелые" фреймворки.


Ovl>насчет хлама... библиотека не выживет без mfc?
Ovl>хотел заиспользовать, но надо оценить затраты на фасад, чтобы выключить MFC

Выживет, конечно. MFC в примерах используется только в качестве средства бинарной сериализации, просто потому, что std-ные стримы в несколько раз медленнее. Т.е. если у вас есть средство бинарной сериализации, то его прикрутить очень просто. Вот тут http://files.rsdn.ru/8583/RPCLib_ios.ZIP пример использования без mfc, на ios. Это только пример, и работает оно _очень_ медленно (именно поэтому я решил не публиковать этот пример официально). Я _настоятельно_ рекомендую использовать другие фреймворки сериализации, дабы не получить ботлнек в совершенно тривиальном месте.

благодарю