ソケットと共有メモリを介して行われるプロセス間通信の長所と短所は何ですか？
プロセス間通信の多くのオプションのうち2つは次のようになる可能性があることを理解しています。
- 共有メモリ
- ソケット
実際、私はこれらの2つのオプションがJavaアプリケーションをデバッグするためにIntellij Ideaによって公開されていることを確認しました。各アプローチの長所と短所を知りたいのですが。
私の頭の上のそれぞれのいくつかの利点。これらの項目の一部はすべての場合に適用されるわけではないことに注意してください。これらは単なる一般的な観察です。
ソケット
シンプルで管理されています。変更をほとんどまたはまったく行わずに、必要に応じてネットワークソケットに拡張できます。プログラミングモデルではシリアル化が必要です。そのため、AからBに実際に転送されるデータについて考える必要があります。同期は、通信メカニズムに必ず組み込まれています。他の同期は必要ありません。
共有メモリ
必ずしもsyscallを必要としない（したがって、より高速になる可能性がある）。共有する場合、明示的にデータを転送する必要はありません。受信者が取得しないデータを利用できるようにすることができます（受信者が使用しないデータを転送するために帯域幅を無駄にする必要はありません）。シリアライゼーション/デシリアライゼーションのステップがないということは、通信オーバーヘッドに時間を費やさないことを意味します。
ソケットは1対1です。同じものを複数のプロセスに送信する場合は、複数のソケットが必要です。共有メモリを使用すると、複数のリーダーと複数のライターを持つことができます。
ソケットはリソースを大量に消費します。すべてのメッセージがOSを通過します。共有メモリでは、共有メモリをマップしますが、一度アプリケーションのメモリにマップし、それ以降はそれを使用します。ただし、共有メモリを使用した場合でも、OSを経由する必要があります。下記参照。
ソケットは同期されます（UDPを使用しない限り）。共有メモリを使用する場合、共有メモリの読み取りまたは書き込みが可能かどうかを他のプロセスに通知するために、必然的に追加のメカニズムが必要になります。これを行わないでください。破損したメモリで問題が発生します。例：プロセスAがチャンク共有メモリの読み取りを開始したが、読み取りの途中でスワップアウトされたとします。プロセスBは、同じ共有メモリのチャンクに書き込みます。プロセスAが再起動して共有メモリの読み取りを続けると、プロセスAが読み取ったのは、新旧のデータの寄せ集めです。これを防ぐために、共有メモリを使用しているときもOSを使用します。
ソケットベースのアプリケーションのセットをネットワークソケットを使用するアプリケーションに変換するのはかなり簡単です。ラボ内のすべてのマシン、またはさらに遠くまで処理を広げることができます。共有メモリではこれを行うことはできません。共有メモリベースのソリューションを備えた1台のマシンにロックされています。
ソケットは、少量のデータ、大量のデータ用の共有メモリを対象としています。さまざまな問題を解決するために、さまざまなメカニズムが存在します。