4

Windows（非.net）環境でリモートプロシージャコールを行う良い方法を知っている人はいますか?

それを行う方法に関する多くの情報を見つけることができず、msdn には .net バージョンしかありません。

.

編集：

これまでの回答に感謝します。私が必要とするのは、進行状況レポートを「クライアント」に送り返す同じコンピューター上のサービスと通信することです。私が rpc に興味を持っている理由は、vistas uac と、サービスが rpc またはパイプを使用しない限り、通常のアプリと通信できないためです。パイプを調べると、それらは完全にテキスト ベースのようで、rpc は強く型付けされた値を渡すことができるという印象を受けました。

DCOMも調べてみます。

4

7 に答える 7

6

同じマシン上のプロセス間での会話のみに関心がある場合、boost::interprocessは、それらが会話するためのチャネルを取得するクールな方法です。

その他の Windows 固有のソリューションは、共有メモリ マップ ファイルとシステム グローバル ミューテックス/シグナルまたは名前付きパイプです。

boost::serializeおよび Googleプロトコル バッファは、プロセス間で送信するデータをバイナリ文字列に変換する方法です。バイナリ文字列は、構造パッキングや、実行可能ファイルごとに異なる可能性があるその他のものにあまり依存しません。

boost::interprocess、boost::serialize、およびプロトコル バッファはプラットフォームに依存しない必要があるため、技術的には Linux/Mac でも動作する可能性があります。

于 2009-01-15T12:53:03.767 に答える
5

DCOMには、DCERPCに基づくリモートプロシージャコールメカニズムがあります。システムをCOMコンポーネントとして構築する場合、または公開するAPIにCOMラッパーを配置する場合は、これを使用できます。それを超えて、問題の詳細についての洞察を深めて、質問を拡張することもできます。問題にDCOMの使用を妨げる可能性のある側面があるかどうかについては、私は実際には把握していません。

別のアプローチは、アプリケーションの周りにWebサービスラッパーを配置することです。Webサービス（確かにSOAPまたはXML-RPCに基づくサービス）は、実際には、トランスポートプロトコルとしてHTTPを使用する単なるRPCメカニズムです。

于 2009-01-15T12:23:24.077 に答える
3

ここに詳細があります:
「Windows Server 2003 R2 用の Microsoft プラットフォーム SDK」を入手し、フォルダー ...\Samples\NetDS\RPC にサンプルを表示します。sdk_NetDS_RPC.exe -
ソースサンプル soapsdk.exe - MS サンプル プログラムへの COM+ イベントの呼び出しと通知FastRpc secure rpc XML と HTTP に基づく軽量の RPC ライブラリ。 古いヘルプですが、便利なRPC.HLP [MS-RPCE]: Remote Procedure Call Protocol Extensions [MS-RPCH]: Remote Procedure Call over HTTP Protocol Specification [MS-COM]: Component Object Model Plus (COM+) Protocol Specification DCOM









于 2009-01-20T01:32:19.930 に答える
2

Windows上で100通りの方法でコードをリモートで呼び出すことができます。ソケット、DComなど... Microsoftはある段階でrpcgen（DCE RPCに基づく）をサポートしていました。これにより、リモートAPI呼び出しを定義でき、コンパイラーがグルーコードを記述します。これはDCOMの基礎となるレイヤーでした。

使いやすく、より広い標準であるUNIXONC-RPCとは互換性がありません。DCOMのようなものが適切でない場合は、ONC_RPCツールキットの1つを確認することをお勧めします。

トニー

于 2009-01-15T12:24:37.210 に答える
1

ええ、私は Isalamon に同意します。MIDL に既に組み込まれている実際の RPC を使用してください。DCE RPC に関する O'Reilly の本を入手できます。同じマシン上にいる場合は、ncalrpc のバインディング ホストを使用してください。

于 2009-01-20T01:37:54.117 に答える
0

複雑さ、オーバーヘッド、逆速度で分類すると、次の可能性が思い浮かびます。

  • SOAP (既に除外したもの)
  • コルバ
  • DCOM (DCE)
  • XML メッセージの交換
  • ONC-RPC (SunRPC)
  • HTTP に似たメッセージの交換
  • telnet のようなメッセージの交換 (回線指向)

多かれ少なかれ、ライブラリやパッケージなどをオープンソースとして使用する準備ができています (イライラする準備ができています)。

上記のいくつかは奇妙に聞こえるかもしれませんが、実際には、HTTP または Telnet を RPC に使用することがよくあります。その理由は、テストするのに派手な環境は必要なく、ほとんどのエイリアン ソフトウェアは簡単にそれに適応できるからです。これらにより、WebBrowser、telnet セッション、または単にソケットを開いて要求を送信する別のプログラムから、プログラムのサービスを簡単に使用できるようになります。たとえば、私のプログラムのほとんどには --scripting コマンド ライン引数が含まれています。これにより、JavaScript のような言語を介してアプリケーション オブジェクト モデル全体に​​アクセスできる telnet ポートが開きます。これを使用して、任意のアプリを非常に簡単にリモート コントロールすることもできます。このようなフレームワークを 1 回作成したことがある場合は、すべての新しいアプリで再利用できます (ここでどのように見えるかを参照してください) 。

私のアプリはすべて、上記のすべてが既に含まれており、クライアントとサーバーの両方としてすぐに使用できる環境で作成されていることを認めなければなりません。

要約: 最も単純な方法を使用してください。アプリをそのようなインフラストラクチャに統合する必要がない限り、Corba や SOAP は必要ありません。

于 2009-01-15T13:50:51.170 に答える
0

これは、1996 年に Win NT 上の Cheyenne Software で InocuLAN アンチウイルスに使用していたものです。これは純粋な RPC であり、OO レイヤーではありません。新しいWindowsでまだ利用できることを願っています。

于 2009-01-15T13:26:15.107 に答える