удаленные вызовы процедур - PullRequest
4 голосов
/ 15 января 2009

Кто-нибудь знает хороший способ сделать удаленные вызовы процедур в среде Windows (не .net)?

Я не могу найти много информации о том, как это сделать, и у msdn есть только версия .net.

.

Edit:

Спасибо за ответы. Мне нужно это для связи со службой на том же компьютере, которая будет отправлять отчеты о проделанной работе «клиенту». Причина, по которой я заинтересован в rpc, заключается в том, что службы UAC не могут общаться с обычными приложениями, если они не используют rpc или каналы. Глядя на каналы, они кажутся полностью текстовыми, и у меня сложилось впечатление, что rpc может передавать строго типизированные значения через.

Я также посмотрю на DCOM.

Ответы [ 7 ]

6 голосов
/ 15 января 2009

Если вас интересует только общение между процессами на одной машине, boost :: interprocess - это отличный способ получить канал для общения.

Больше решений для Windows - это сопоставленный файл совместно используемой памяти и системные глобальные мьютексы / сигналы или именованные каналы .

boost :: serialize и буфер протокола google - это способы преобразования данных, которые вы отправляете между процессами, в двоичные строки, которые в меньшей степени зависят от упаковки структуры и других вещей, которые могут отличаться между различными исполняемыми файлами.

Буферы boost :: interprocess, boost :: serialize и protocol должны быть независимыми от платформы, поэтому технически это может работать и в Linux / Mac!

5 голосов
/ 15 января 2009

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

Альтернативный подход заключается в размещении оболочки приложения вокруг приложения. Веб-сервисы (безусловно, основанные на SOAP или XML-RPC) на самом деле представляют собой просто механизм RPC, использующий HTTP в качестве транспортного протокола.

3 голосов
/ 20 января 2009

Более подробная информация здесь:
Получите «Microsoft Platform SDK для Windows Server 2003 R2» после установки просмотрите образцы в папке ... \ Samples \ NetDS \ RPC
sdk_NetDS_RPC.exe - исходный пример soapsdk.exe - образцы MS
Больше ссылок:
Отслеживание вызовов RPC и уведомление о событиях COM + в вашей программе
FastRpc
безопасный RPC
Облегченная библиотека RPC на основе XML и HTTP.
старая помощь, но полезная RPC.HLP
[MS-RPCE]: расширения протокола удаленного вызова процедур
[MS-RPCH]: спецификация протокола удаленного вызова по протоколу HTTP
[MS-COM]: спецификация протокола компонента объектной модели Plus (COM +) DCOM

2 голосов
/ 15 января 2009

Вы можете вызывать код удаленно в Windows сотней разных способов; сокеты, DCom и т. д. Microsoft на одном этапе поддерживала rpcgen (на основе DCE RPC), который позволял вам определять удаленные вызовы API, а его компилятор писал бы связующий код. Это был базовый слой в DCOM.

Он не совместим с UNIX ONC-RPC, который проще в использовании и имеет более широкий стандарт. Возможно, вы захотите взглянуть на один из наборов инструментов ONC_RPC , если что-то вроде DCOM не для вас.

Tony

1 голос
/ 20 января 2009

Да, я согласен с Исаламоном - просто используйте реальный RPC, который уже встроен в MIDL. Вы можете получить книгу О'Рейли о DCE RPC. Если вы находитесь на той же машине, просто используйте связывающий хост ncalrpc.

0 голосов
/ 15 января 2009

Ну, отсортированные по сложности, накладным расходам и скорости обратного хода, мне в голову приходят следующие возможности:

  • SOAP (который вы уже исключили)
  • Корба
  • DCOM (DCE)
  • обмен сообщениями XML
  • ONC-RPC (SunRPC)
  • обмен HTTP-подобными сообщениями
  • обмен telnet-подобными сообщениями (ориентирован на линию)

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

Некоторые из вышеперечисленных могут показаться странными, но на самом деле мы часто используем HTTP или Telnet для RPC. Причина в том, что вам не нужны модные среды для тестирования, любое самое чужое программное обеспечение может легко адаптироваться к нему. Это также позволяет легко использовать сервисы вашей программы из WebBrowser, сеанса telnet или другой программы, которая просто открывает ей сокет и отправляет запрос. Например, большинство моих программ содержат аргумент командной строки --scripting, который открывает порт telnet, через который вы можете отправлять доступ ко всей объектной модели приложений через язык, похожий на JavaScript. Это также может быть использовано для удаленного управления любым приложением очень легко - без каких-либо усилий. Если вы однажды написали такой фреймворк, его можно использовать для каждого нового приложения (посмотрите, как это выглядит здесь )

Я должен признать, что все мои приложения написаны в среде, в которой все вышеперечисленное уже включено и готово к использованию как в качестве клиентов, так и в качестве серверов.

Резюме: используйте самую простую вещь, которая делает работу. Вам не нужно Corba или SOAP, если ваше приложение не нужно интегрировать в такую ​​инфраструктуру.

0 голосов
/ 15 января 2009

Здесь - это то, что мы использовали в 1996 году в Cheyenne Software на Win NT для антивируса InocuLAN. Это чистый RPC, а не слой ОО. Я надеюсь, что это все еще доступно в более новой Windows.

...