web-dev-qa-db-ja.com

C ++用のアクターライブラリ/フレームワーク

私が取り組んでいるC++プロジェクトでは、さまざまなマシンにデプロイされたいくつかのプロセスで構成されるアプリケーションがあります。アプリケーションの存続期間中にプロセス(クライアントまたはバックグラウンドサービス)を開始および終了できるため、このプロセスのネットワークは動的です。

RPCを介してネットワークを介して任意のデータを転送できるモジュールがすでにあり、プロセス間で情報(ステータス情報、進捗情報、エラーコードなど)を交換するために使用しています。非同期通信(現在、RPCは同期的に実行されます)を処理し、プロセスを動的に開始および終了し、引き続きお互いを検出できるようにする、より抽象的な層が必要です。

私たちは最近解決策を探しました、そしてScalaactorsremote actors(例 このチュートリアル を参照)Scalaより長く使用されているアクターモデルを使用する別の言語は Erlang です(参照 この質問 )。

アクターはビヘイビアーとメールボックスを持つオブジェクトであり、データを共有しません。アクターは同時に実行され、非同期メッセージ交換を介して通信します。行動の一部として、俳優は他の俳優を作成できます。メッセージもオブジェクトとして表されます。

最も単純なケースは、俳優が同じプロセスに住んでいることです。この場合、ハンドル(参照、ポインタ、一意の識別子)を使用して互いにアドレス指定できます。アクターの実装は、基になるスレッドとその他の詳細を隠します。アクターが異なるプロセス(および場合によってはネットワーク内の異なるマシン)に存在する場合、それらはIPアドレス、ポート、および名前によって識別されます。この場合、リモートアクターについて説明します( このページ の上部にある短い例を参照してください)。

私たちの場合、すべての通信を処理する各プロセスに1人のアクターがいます。つまり、ある種のリモートアクターが必要です。

wikipedia で、C++用のアクターライブラリへのリンクをいくつか見つけ、- Theron を調べ始めました。セロンは非常によく記述され、文書化されたライブラリのようですが、私の理解では、リモートアクターをサポートしていません。すべてのアクターは同じプロセス内に存在する必要があります。複数のアクタープール(frameworks)を作成することは可能ですが、これらすべてのプールは同じプロセス内に存在する必要があります。

だから私は誰かが上でスケッチされたリモートアクターの概念をサポートする他のC++ライブラリを知っているかどうか尋ねたかったのです。

[〜#〜]編集[〜#〜]

この質問は、元の質問に対して、 programmers-metaディスカッション の指示に従って編集されています。

[〜#〜]更新[〜#〜]

私が調べた他のフレームワークは libcppa (リモートアクターをサポートする必要がありますが、まだ開発中ですが、現在バージョン0.1)、 actor-cpp (これも開発中)、および libactor 、これはC言語で記述されています(Webサイトでは、「使用できるが、まだ準備ができていない可能性があります」と記載されています)。

5
Giorgio

バージョン5以降、Theronはリモートアクターをサポートしています。サポートはまだ非常に予備的なものであり、いくつかの制限があります。特に、メッセージのシリアル化は現在、ビット単位のコピーにすぎません(バージョン5.0および2012年10月現在)。しかし、それは出発点であり、私はそれをさらに開発するつもりです。

http://www.theron-library.com/index.php?t=page&p=distributed%20computing

7
Ash

Microsoftの最新の「最新の非同期C++ API設計を使用したネイティブコードでのクラウドベースのクライアントサーバー通信」である Casablanca は、このために設計されています。

俳優

カサブランカのもう1つの側面は、アクタープログラミングモデルの実装です。これは、信頼性が高くスケーラブルなシステムの構築に役立つことが実証されています。 C++実装は、Erlangモデルに近いままです。ポインタを持つ命令型言語で構築されたライブラリ内の純粋な関数型言語のモデルを正確に模倣することは明らかに困難ですが、かなり近づきました。

非常に新しく、MicrosoftはC++がクラウドおよびスケーラブルシステムに適していると最近認識しましたが、彼らはフィードバックを聞いています-彼らは私に1時間話してくれるよう招待しました。ボックスと彼らはあなたにメールを送信します。 MSは新しいものですが、それほど意味はありません。MSはAzureに次の大きなお金のスピナーとして取り組んでいるので、これはなくなることはありません。

2
gbjbaanb

たぶん、QP/C++アクティブオブジェクト(アクター)フレームワークは、法案に適合しますか? QP/C++は、主にリアルタイムの組み込みシステム用に設計されていますが、Linux(Pスレッドを使用)およびWindows(Win32スレッド)で非常にうまく動作します。

QP/C++は成熟したオープンソースフレームワークであり、現在、市場で10年を迎えています。設計上非常に軽量であり、リモートアクティブオブジェクトをサポートしていませんが、この機能は「リモートプロキシ」設計パターンを使用して追加できます。このようにして、ネットワークを介して既存の通信プロトコルを再利用できます。プロキシを使用する利点は、アクティブなオブジェクトがリモートで通信していることを認識しないため、アクティブなオブジェクトを変更せずにシステムを好きなように分割できることです。プロキシを開発するだけで済みます。

QPフレームワークは、イベント駆動型アクティブオブジェクトの動作をモデル化するための階層型ステートマシン(UMLステートチャート)の強力なサポートも提供します。フレームワークは、非常に読みやすいコードでHSMを手動でコーディングする簡単な方法を提供しますが、無料のQMモデリングツールを使用してステートチャートを描画し、QPコードを自動的に生成することもできます。詳細は state-machine.com をご覧ください。

0
Miro Samek