ローカル IPC (両方とも win-api を使用)、有効性に応じた、リソースに応じた、またはその他のソケットよりも名前付きパイプを優先する理由はありますか?とにかく、ネットワークの目的ですでにソケットを使用している可能性が高いアプリケーションでは?
少なくともアドレス指定の問題を挙げることができます: パイプのファイル名に対するソケットのポート番号。また、ブロックされたアプリケーションはソケット経由でローカルに通信できますが、名前付きパイプ (AFAIK) はファイアウォール (ブロック/ブロック解除ダイアログ) に警告しません。他に考慮すべきことはありますか？
ソケットを使用する場合、ソケットをローカルで使用するときに推奨される winsock 設定/フラグはありますか?
いくつかの微妙な違い：
アダプターが機能していない場合、ローカルIPCではソケットは機能しません。アダプターが機能していないPCを使用することはどのくらい一般的ですか？さて、誰かがネットワークまたは電源に接続されていないラップトップで顧客にソフトウェアをデモンストレーションしようとしたときに（OSが電力を節約するためにネットワークカードを無効にしたため）、ワイヤレスアダプタが無効にされたときに噛まれました（ラップトップユーザーはワイヤレスを使用しませんでした）。ループバックアダプタをインストールすることでこれを回避できますが、これは理想的ではありません。
ファイアウォールソフトウェアは、TCP/IP接続の確立で問題を引き起こす可能性があります。ローカルIPCの問題ではないはずですが、私は確信していません。名前付きパイプにもファイアウォールを設定できます。
名前付きパイプを作成したり、名前付きパイプの新しいインスタンスを作成したりするために必要な権限が原因で問題が発生する可能性があります。たとえば、同じ名前付きパイプを使用して複数のサーバーを実行していましたが（おそらくこれはテスト用でしたが、これはテスト用でした）、パイプを作成した最初のサーバーが管理者モードで実行されていたため（ Visual Studioは管理者モード）、残りは通常のUACレベルでコマンドラインから起動されました。
Rubensが言及した記事は、主にネットワークを介したIPCに関するものですが、「ローカル名前付きパイプはカーネルモードで実行され、非常に高速である」と指摘しています。
考慮すべきもう 1 つの解決策は、名前付き共有メモリ領域です。フロー制御プロトコルを自分で確立する必要があるため、少し手間がかかりますが、速度が最も重要であった過去にこれを使用して成功しました。