問題タブ [rpc]

winsock と C++ を使用してサーバー アプリケーションをセットアップしています。私が抱えている問題は、への呼び出しがlisten最初のチャンスの例外になることです。通常、これらは無視できると思いますが (?)、同じ問題を抱えている他の人を見つけました。アプリケーションが時々ハングする原因です。どんな助けでも大歓迎です。

最初の例外は次のとおりです。

MyApp .exeの 0x*12345678* での初回例外: 0x000006D9: エンドポイント マッパーから使用できるエンドポイントはこれ以上ありません。

これがソケットが原因である可能性があるという証拠をいくつか見つけました。私が使用しているコードは次のとおりです。例外はlisten、下から 5 行目の への呼び出しで発生します。

MSVC プロジェクトを VS 2005 から VS 2008 に変換しようとしています。RPC に使用されるヘッダーとスタブを出力する IDL ファイルが含まれています。VS 2005 プロジェクトは、MIDL.exe バージョン 6.00.0366 を使用します。VS 2008 プロジェクトは、MIDL.exe バージョン 7.00.0500 を使用します。

問題は次のとおりです。MIDL v6 は、サーバー コードに実装する次のプロトタイプを出力します。

同じコマンド ラインで MIDL v7 を実行すると、次のプロトタイプが出力されます。

既存のすべての実装に handle_t パラメーターを追加する必要はありません。(さらに、しばらくの間、VS 2005 でコンパイルするための実装が必要です。)

質問: MIDL.exe v7 で v6 と同じ RPC サーバー プロトタイプを出力するにはどうすればよいですか?

私たちのシステムには、Web アプリケーションとその上に開発されたクライアント アプリケーションのドメイン ロジックとデータ アクセスを処理するリモート API レイヤー (SOAP、XML-RPC、REST など) があります。以前とは異なり、Web アプリケーションにビジネス ロジック コードと DB 接続がなく、すべてのユーザー アクションはレイヤーのメソッドを呼び出すように変換されます。

私の懸念は、たとえばページのレンダリングの場合、レポート、最近の履歴、いくつかのポートレットなどを含むユーザー ダッシュボードなど、データを取得するためにかなりの数の呼び出しを行う必要があることです。私の現在の設計 (委任ロジックと DA) ではリモート層へ)、あなたが見ている欠点は何ですか? HTTP経由でテキストベースのデータを確立して送信することは、DBアクセスよりも重く、コストがかかることがわかりました。さらに、代わりにリモート層で最適化を行う必要があります (Web アプリでビジネス ロジックと DA コードを指定すると、最適化の柔軟性が高まります)。

私は現在、すべての呼び出しを 1 つにまとめることができるリモート「ヘルパー」サービスを作成するかどうかを考えています。つまり、複数の呼び出しを行う代わりに、メソッド名と引数のコレクションを含む 1 つの呼び出しを送信します。ちょっと見栄えが悪いので、今でもそうすることにまだ懐疑的です。

このアーキテクチャについてのご意見をお聞かせください。同様の方法で Web アプリケーションを開発したことがある場合、優れたパフォーマンスを保証するために過去にどのようなアプローチをとっていましたか? 私が本当に心配しなければならない他の懸念がある場合は、それも私と共有してください.

ありがとう！

yc

私たちのシステム全体はRESTを中心に設計されており、URLで動詞を使用せずに、意図的にRPCであることが非常に明確なプロセスをRESTfulリソースにマッピングする方法を検討しています。コンテンツリストが他の場所で変更された場合、リモートプロシージャコールを使用して検索インデックスを再構築します。

私たちが考えているのはこれです：

POST / index_updates

<indexUpdate><contentId>123</contentId></indexUpdate>

それ自体は何も問題はありませんが、作成されたこのリソースは、新しく作成されたリソースのURLを返しません。たとえば/ index_updates / 1234は、GETでアクセスできます。

使用しているインデックスエンジンにはログメカニズムがあるため、理論的には、GETがリソースを取得できるようにindex_updateリソースにURLを返すことができますが、正直なところ、これはリソースに関心がありません。変装したRPCにすぎません。

だから私の質問は、RESTfulnessが構造で表現されているのか意図で表現されているのかということです。私が概説したものの構造は落ち着いていると感じますが、意図はそうではありません。

誰かコメントやアドバイスはありますか？

ありがとう、

クリス

RPC を使用する単純な Google Web Toolkit アプリケーションを作成したいと考えています。永続性については、Java Persistence API のようなものを使用したいと考えています。

これは、Glassfish のようなアプリケーション サーバーを使用する必要があるということですか? または、単純な Web コンテナーを使用できますか?

具体的なライブラリに関しては、どのように進めればよいですか? トップリンク? 冬眠？...

同じチームによって開発される 2 つの C++ プロセス間の通信チャネルとして、RPC (xml-rpc ではない) の代わりに Web サービスを使用する正当な理由を誰か提案できますか? 注: Web サービスは、注文した配送を保証するものではありません。

私の会社では、データにアクセスして更新するために Web API に分岐し始めています。最初はパートナー向けですが、将来的には一般公開される可能性があります。現時点では、API の外観 (SOAP、REST、RPC など) は完全にオープンであり、まだ何も決定していません。そのため、人々が優れていると考える Web API の例と、あなたがそう考える理由の両方に興味があります。それ。

私が興味を持っているのは、さまざまな言語を使用している人々 (特に .NET、Java、ActionScript、JavaScript など、さまざまなプラットフォームを使用している人々に API を提供する可能性が高い) からの、優れていると思われる Web API に関する意見です。例、そしてあなたが良い経験をしたこと。

私がカバーしたいいくつかのポイント：

1. SOAP タイプのサービスと REST/RPC スタイルのサービスのどちらが好みですか? プラットフォームをサポートしている人 (.NET、Java など) は SOAP を好み、プラットフォームをサポートしていない言語を使用している人は他の言語を好むと思いますが、その仮定を検証したいと思います。

2. API が実際に RESTful であるかどうか、または単純な古い RPC スタイルの HTTP GET/POST であるかどうかを気にしますか? もしそうなら、なぜあなたは気にしますか？API が実際に 2 つのうちの 1 つであるかどうかよりも、API がそれ自体を正しく記述している (つまり、RPC スタイルの場合は RESTful であると主張しない) ことの方が重要ですか?

3. 誰がサービスを使用しているかを確認する必要があります。私は、パブリック識別子と、リクエストのパラメーターを検証トークンにハッシュするために使用されるプライベートトークンを使用する Amazon S3 認証を見てきました (これも flickr に似ています)。以前にこのタイプの認証を使用したことがありますか? また、どのように使いこなしましたか? 問題がある (つまり、プラットフォームでサポートされていない) ハッシュ アルゴリズムはありますか? ハッシュを HTTP ヘッダーと URI のどちらで送信しますか?

4. バージョン管理はどのように処理する必要がありますか? 将来のバージョンを一緒に追加できるようにタイプのサブディレクトリを用意するのは良い考え/v1/ですか?それとも、リクエストのペイロードまたはクエリにバージョンを含めるなど、別のことを行いますか? 構築した API のバージョンがサポートされる期間はどのくらいだと思いますか (つまり、v2 が導入された場合、v1 の存続期間にどれくらい期待できますか)。

また、カバーする他の意見やポイントは役に立ちます。

実装している API の実際のタイプについては、意図的にあいまいなままです。人々が良い API と実装メカニズムと考えるものに関する一般的なガイダンスを探しているためです。この投稿とその回答は、より多くの人々に役立ちます。将来。

注: 検索したところ、これに関する一般的な質問が見つかりません。これらはすべて、特定の種類の API に固有のようです。ただし、重複している場合はお知らせください。また、それがコミュニティ wiki である必要がある場合 (回答者は回答の功績を認められるべきだと思うので、私はそれを作成していません)、お知らせください。そうするように変更します。

Erlang が最善を期待している RPC セマンティクスでは、少なくとも 1 回の SUN RPC と最大 1 回の Java RMI がありますが、正確に 1 回のセマンティクスを持つ人はいません。

厳密に 1 回のセマンティクスを持つことが実行不可能に思えるのはなぜですか?

たとえば、クライアントが応答を受信するまで一意にタグ付けされたリクエストを再送信し続け、サーバーがリクエストを複製しないように処理されたすべてのリクエストを追跡する場合。それはちょうど一度ではないでしょうか？

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

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

.

編集：

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

DCOMも調べてみます。