Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: COM/DCOM/ActiveX/ATL/CORBA > [RPC, IDL] перенос клиента на linux

Автор: Alexander8 6.7.2010, 13:51

Здравствуйте!

Подскажите, пожалуйста, как поступить в такой ситуации.

Есть ПО: windows-сервер и windows-клиенты, общающиеся по RPC-протоколу.
RPC-часть сгенерированна при помощи MIDL-компилятора.
Появилась необходимость портировать клиента на linux (хотя бы часть функционала),
сервер останется на windows. Более того, значительные изменения сервера нежелательны,
тем более перевод его на какую-нибудь кроссплатформенную реализацию rpc-технологию.

Вопрос в том, как с линукс-платформы клиентом вызвать нужную rpc-функцию с windows-сервера?
В принципе, везде написано, что такие вещи возможны, но как это сделать нигде не уточняется. smile

Я смотрел в сторону rpcgen-а, но он только для линукса.

В сторону FreeDCE, сначала думал, что нашел то, что надо, но, к сожалению проект мертв, документации мало.
Удалось dceidl-ом скомпилировать интерфейс, даже "прибиндиться" к серверу, но вот при вызове rpc-функций клиент падает.
Да и dceidl не поддерживает некоторые вещи (хотя и не это главное).

Также посмотрел и widl (эмуляция rpc от wine). Wine клиента, кстати, без проблем гоняет. Но нужен родной линуксовый.

В общем, нужна технолгия, которая позволит подружить rpc-часть linux-клиента и уже существующего win-сервера.

Чтобы конкретизировать вопрос, пусть есть вымышленный интерфейс, по которому общаются виндовый сервер и клиенты:

Код


import "oaidl.idl";
import "ocidl.idl";

[
   uuid(51D82444-6400-4a55-A20E-72123QQF08D),

   version(1.0)
]

interface CONNECTION
{
   typedef [context_handle] void* CONTEXT_HANDLE;

   const int BUFSIZE = 128;

   // Открыть соединение с сервером.
   CONTEXT_HANDLE Open(

        [in] handle_t hBinding,

        // Имя клиента
        [in, string] const char clientName[BUFSIZE],

        // Здесь можно получать что-то в ответ от сервера.
        [out, string] char data[BUFSIZE]);


   // Получить что-то от сервера.
   void GetData(

        // Имя файла, который нужно получить.
        [in, string] const char fileName[BUFSIZE],

        [in] CONTEXT_HANDLE hContext,

        // Размер получаемых данных.
        [out] int *size,

        [out, size_is(,*size)] char **data,

        // Код возможной ошибки.
        [out] int *error);


   // Закрыть соединение с сервером.
   void Close(
        [in, out] CONTEXT_HANDLE* phContext);
}

Как мне и с линукса общаться с вин-сервером по данному интерфейсу?

Буду очень благодарен за помощь.

Автор: icecrashldr 8.7.2010, 11:34

google.ru -> DCOM Linux

http://freedce.sourceforge.net/

А вообще лучше быдо делать на CORBA ...

Автор: Alexander8 8.7.2010, 16:27

Ну так я же написал про все это.

FreeDCE - это мертвый проект, нет ни документации, ни форумов. Я пробовал его:

Цитата

В сторону FreeDCE, сначала думал, что нашел то, что надо, но, к сожалению проект мертв, документации мало.
Удалось dceidl-ом скомпилировать интерфейс, даже "прибиндиться" к серверу, но вот при вызове rpc-функций клиент падает.
Да и dceidl не поддерживает некоторые вещи (хотя и не это главное).

В сети из информации одни только баг-репорты.

По поводу CORBA:
Конечно, если писать проект с нуля, то можно взять ее или ACE, или еще что-нибудь.
Но в моей ситуации сервер и клиенты виндовые уже написаны и работают не один год.
Поэтому вариант переписать сервер и клиентов отпадает.

Автор: icecrashldr 8.7.2010, 17:57

Alexander8 тогда вам остается google.ru

Автор: jonie 8.7.2010, 18:16

CORBA-а зло, поверьте мне! Есть куда как более привлекательные протоколы (soap например)... насколько я знаю, даже в java от нее отказались почти...

В общем я предлагаю вам написать proxy (читать про паттерн в гугле), который будет транслировать SOAP запросы (gSOAP можно взять) в запросы виндового rpc и обратно. Конечно, этот самый прокси будет стоять на винде, но это вам будет проще как с т.з. отладки, так и со стороны разработки.

Автор: Alexander8 9.7.2010, 04:03

Спасибо за ответы.

Цитата

В общем я предлагаю вам написать proxy (читать про паттерн в гугле), который будет транслировать SOAP запросы (gSOAP можно взять) в запросы виндового rpc и обратно. Конечно, этот самый прокси будет стоять на винде, но это вам будет проще как с т.з. отладки, так и со стороны разработки.

Это действительно хорошая идея и она уже была реализована несколько раньше. Только там был не SOAP-протокол, но все остальное точь в точь.
Конечно, прокси создает дополнительную нагрузку, но работает все это хорошо.

Дело вот в чем:
Компании, где я работаю, для охвата заветных 100% рынка нужно получить 2-3% линукс-клиентов (специфика работы такова, что их именно столько).
Т.е. скорее маркетинговый ход, чем реальная необходимость.
С моей сторону нужно либо сделать это, либо доказать, почему это сделать нельзя.
Сделать хочется, это интересно, да и опыт хороший. Но вот с информацией пока тяжело. smile

Автор: jonie 9.7.2010, 08:30

Alexander8, доказывать проще простого. Говорите менеджерам сколько вы еще потратите время на совсем не нужные вещи и сколько им это будет стоить - остальное они сами додумают 8)

Автор: Alexander8 12.7.2010, 06:06

jonie, как вариант.
Вообщем, я решил потратить еще какое-то время (может недельку) на изучение этого вопроса,
благо срочной работы сейчас немного.

===================

Просто мысли вслух.
Честно говоря, вот что удивляет.
RPC - идея, которая задумывалась для обеспечения удаленного вызова процедур, не сильно волнуясь о том,
какие компьютеры это делают.
Т.е. не очень важно, что за платформа, какая система, скольки битная, какие соглашения о вызовах там используются.
А получается, что это очень существенно.
И если не использовать специальные реализации типа CORBA и т.д.,
то не выходит даже по простейшему интерфейсу сконнектиться разными системами.
Получается, как бы "вещь в себе", работает в рамках одной и той же реализации.

Автор: borisbn 12.7.2010, 06:57

Alexander8, а с каких пор мелкоМягкие задумывают очередную технологию, которая
>> не очень важно, что за платформа, какая система, скольки битная, какие соглашения о вызовах там используются.
?
Ни одной не припомню ( не значит, что не было, просто не помню )

Автор: Alexander8 12.7.2010, 07:23

borisbn, я и сам не могу назвать сходу такой технологии.
Если не считать различные ухищрения типа C# и Mono, Pascal и Lazaurus, но это все-таки уже не то.
Потому что это делается не майкрософт, а третьими лицами.

Но rpc - это ведь не их технология.
Из вики:

Цитата

MSRPC is derived from the DCE 1.1 reference implementation.

Хотя, по большому счету, Вы правы. Их реализация получилась не совместимой с остальными.

Жалко, что нет единого стандарта на все это дело.

Автор: Alexander8 15.7.2010, 12:25

Вы знаете, похоже, что я незаслуженно обидел FreeDCE. smile

Потратив на него два дня, я смог добиться достаточно неплохих результатов.
Было много проблем, главные: "out" переменные и size_is.
К сожалению, конструкции вида

Код


[out] int *size,
[out, size_is(,*size)] char **data

недопустимы по целому ряду причин:
1) size_is во freedce не поддерживает формата size_is(a, b)
2) для параметров size_is применимы только "in" параметры данной функции (это, конечно, как минимум странно).

Но все их удалось обойти.
Есть у меня такой тестовый интерфейс:

Код


/* idl файл */
[ uuid(51D98111-6400-4a55-B20E-7242F709F08D), 
  version(1.0),
  pointer_default(ptr) 
]

interface CONNECTION {

  typedef [ptr, string] char * string_t;

  typedef struct {
          unsigned32 argc;
          [size_is(argc)] string_t argv[];
              } args;

  boolean ReverseIt(    
    [in] handle_t             h,
    [in] args *              in_text,
    [out] args **               out_text,
    [out,ref] error_status_t *    status
    );

    long Sum([in] handle_t h, [in] long a, [in] long b, [out] long *c);
    
    void ManyStringsOut([in] handle_t h, [out] args **str); 
    
     typedef struct {
          int length;
          string_t data;
              } output;
              
     void OneStringAndLengthOut([in] handle_t h, [out] output **data_out);

     /* и даже вот так тоже работает */
     void StrOut3([in] handle_t h, [out] long *len, [out] string_t *str);
}

Код


/* acf файл */
[ explicit_handle ] 
interface CONNECTION {

    ReverseIt([comm_status, fault_status] status);
}

Все прекрасно работает в паре с win-сервером.
Если интересно, то код линукс-клиента тоже могу привести.

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