問題タブ [named-pipes]

*nix では、引数としてファイル名を受け入れる多くのコマンド ライン アプリケーションがパイプも受け入れます。例：

また、

そして、「anotherApplication」の結果は、ファイルだったので「anApplication」にリダイレクトされます

これに相当する Windows が「名前付きパイプ」であることを知りました。コマンド ライン アプリケーションは、それを理解するために名前付きパイプを認識している必要があるのか​​、それとも、ファイルを引数として受け入れるコマンド ライン アプリケーションが代わりに名前付きパイプで動作するのか疑問に思います。

名前付きパイプを介してセットアップしているサーバーがあります。ドメインの管理者には問題なく機能しますが、通常のユーザーでクライアントをテストすると、「パスへのアクセスが拒否されました」という例外が発生します。ドメイン内のすべての認証済みユーザーにアクセス権を付与するためのアクセス許可を設定しようとしているのは次のとおりです。ここで何が間違っていますか？

サーバ：

クライアント：

サーバー名とドメインは明らかに異なりますが、サーバー上で pipeServer.SetAccessControl 関数に到達すると、「UnauthorizedAccessException」という例外が発生します。

どんな助けでも大歓迎です

名前付きパイプを作成したのは誰（どのプロセス）かを教えてくれるWinAPI呼び出しはありますか？

注：この質問をすると、どういうわけか「においがする」と感じます。適切な設計では、他の手段を使用してプロセスID /ハンドルを伝達しますが、パイプ自体からこの情報を取得する方が簡単です。そのようなAPI、私はおそらくまだそれを使用します。

.net 3.5 で NamedPipes を介してオブジェクトを送信する最良の方法を教えてください。

名前付きパイプを使用しており、サーバー上で同じパイプを再利用して、元のクライアントが切断された後に別のクライアントを接続できるようにしたいと考えています。私がすることは：

• サーバーは使用してパイプを作成しますCreateNamedPipe
• サーバーは を使用してデータを書き込みWriteFile、エラーが返される限り再試行しますERROR_PIPE_LISTENING(これはクライアントが接続される前です)。
• クライアントは次を使用して接続しますCreateFile
• クライアントがデータを読み取る
• クライアント クローズ パイプ ハンドルを使用してCloseHandle
• この時点で、サーバーがERROR_NO_DATAさらにデータを書き込もうとするとエラーが発生します
• サーバーは を使用してパイプを切断します。これによりDisconnectNamedPipe、再び解放されるはずです
• サーバーはデータの書き込みを試み、エラーを取得し、エラーERROR_PIPE_NOT_CONNECTEDがなくなるまで再試行します
• ただし、新しいクライアントが接続CreateFileし、パイプで試行すると、取得されますERROR_PIPE_BUSY

したがって、私の質問は次のとおりです。クライアントをパイプから適切に切断して、新しいクライアントが接続できるようにするために必要な他の手順は何ですか?

名前付きパイプを使用して他のプロセスと通信する小さな Linux プログラムに、ハンドシェイク タイプのプロトコルを実装する必要があります。名前付きパイプを使用する場合のハンドシェイク型プロトコルの一般的な実装パターンを検索しましたが、何も上げることができませんでした...

これを行うパターンがないとは信じられません。誰かが可能なリソースを教えてくれますか?

完全な開示では、これは宿題ですが、このパターンを実装することは宿題ではありません。宿題コード内の問題を解決する必要があり、これが可能な解決策であると信じています。宿題は C++ で実装されていますが、言語は私には関係ありません。私は車輪を再発明したくないだけです....

更新:これは信号で実装される可能性があると感じています。

ハンドシェイクとは、子プロセスが親プロセスに、作業の準備ができていることを報告しますが、親が go シグナルを出すまで (パイプに何かがあったとしても) 先に進まないことです。私の作業理論では、多くの子プロセスが準備完了を報告し、親プロセスからの go シグナルを待つ必要があります。

名前付きパイプはソケット IPC よりも高速であると誰もが言うようです。彼らはどれくらい速いですか？ソケットは双方向通信が可能で非常に柔軟であるため、私はソケットを使用することを好みますが、柔軟性よりも速度がかなり大きい場合は速度を選択します。

何らかの理由でマストとスレーブの両方が失敗しましたが、それらがどのように機能するかについての良い例を見つけることができたので、どこで間違ったのかわかりません.

マスターは ConnectNamedPipe の後に WaitForSingleObject を終了することはなく、スレーブは最初の boost::asio::read 呼び出しで例外をスローします。「プロセスがパイプのもう一方の端を開くのを待っています」。マスターの ConnectNamedPipe と一緒に待ちますか?

マスター.cpp

スレーブ.cpp

明らかに、私は何か完全に間違っていましたが、ネット上で自分のコードを比較するものを見つけることができませんでした。

WindowsServer2003マシンの単一のWindowsサービスでホストされている2つのWCFサービスがあります。WindowsサービスがいずれかのWCFサービスにアクセスする必要がある場合（時限イベントが発生した場合など）、公開されている5つの名前付きパイプエンドポイントの1つを使用します（異なるサービスコントラクト）。このサービスは、2つのサービスそれぞれのHTTP MetadataExchangeエンドポイントと、サーバー外部のコンシューマーのnet.tcpエンドポイントも公開します。

通常はうまく機能しますが、ときどき次のようなエラーメッセージが表示されます。

System.ServiceModel.EndpointNotFoundException：メッセージを受け入れることができるnet.pipe：// localhost/IPDailyProcessingでリッスンしているエンドポイントがありませんでした。これは多くの場合、誤ったアドレスまたはSOAPアクションが原因で発生します。詳細については、InnerException（存在する場合）を参照してください。---> System.IO.PipeException：パイプエンドポイント'net.pipe：// localhost/IPDailyProcessing'がローカルマシンで見つかりませんでした。---内部例外スタックトレースの終了---サーバースタックトレース：System.ServiceModel.Channels.PipeConnectionInitiator.GetPipeName（Uri uri）at System.ServiceModel.Channels.NamedPipeConnectionPoolRegistry.NamedPipeConnectionPool.GetPoolKey（EndpointAddress address、Uri via）at System.ServiceModel.Channels.ClientFramingDuplexSessionChannelでのSystem.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection（TimeSpanタイムアウト）。

それは確実に起こらないので、やりたいときに繰り返すことができないので、それは腹立たしいことです。私のWindowsサービスには、いくつかの時限イベントといくつかのファイルリスナーもありますが、これらはかなりまれなイベントです。なぜ私が問題に遭遇するのか、誰かが何か考えを持っていますか？どんな助けでも大歓迎です。

名前付きパイプを使用して、C# .Net サービスとネイティブ C++ アプリケーション間の通信を行っています。サービスはメッセージ モード パイプを作成し、タイマーを開始します。

タイマー ティック ルーチンには、次のようなメイン サービス ループがあります。

読み取りおよび書き込み完了ルーチンは次のようになります。

クライアント側のコードは既知の適切なコードであり、再利用されます。ここで問題です。クライアントは正常に接続できます。次に、クライアントをシャットダウンします。すべて問題ありません。起動して、再度接続します。すべて問題ありません。それから閉じて、もう一度開始します。ブーム - エラー 231、パイプがビジーです。サーバーは、地獄がフリーズするか、サービスを再起動するまで、接続試行時にパイプ ビジー エラーを生成するようになりました。その後、再び 2 つの接続に戻ります。

私はこのコードを 3 日間連続して見つめてきましたが、なぜこれが行われるのかわかりません。木を見て木が見えないようで、新鮮な目を1つか3つ使うことができました。問題は、チームの誰もが C# の多くを知っていないことです。

アップデート

これが 3 回目の接続試行で失敗する理由は、最初の切断で PipeReadComplete が返され、0 バイトが読み取られるため、パイプを切り離すとすべてがうまくいくためです。しかし... 2回目の切断では、PipeReadCompleteは呼び出されないため、強制的に切断しません。変。