それらは何で、どのように機能しますか?
コンテキストはたまたま SQL Server です
Windows システムと POSIX システムの両方で、名前付きパイプは、同じマシンで実行されているプロセス間でプロセス間通信を行う方法を提供します。名前付きパイプが提供するものは、ネットワーク スタックが関与することによるパフォーマンスの低下なしにデータを送信する方法です。
サーバーが着信要求の IP アドレス/ポートをリッスンしているように、サーバーは要求をリッスンできる名前付きパイプをセットアップすることもできます。いずれの場合も、クライアント プロセス (または DB アクセス ライブラリ) は、リクエストを送信するための特定のアドレス (またはパイプ名) を認識している必要があります。多くの場合、一般的に使用される標準のデフォルトが存在します (HTTP のポート 80 と同様に、SQL サーバーは TCP/IP のポート 1433 を使用します。名前付きパイプには \\.\pipe\sql\query を使用します)。
追加の名前付きパイプを設定することで、それぞれが独自のリクエスト リスナーを持つ複数の DB サーバーを実行できます。
名前付きパイプの利点は、通常ははるかに高速であり、ネットワーク スタック リソースを解放できることです。
-- ところで、Windows の世界では、リモート マシンへの名前付きパイプを使用することもできますが、その場合、名前付きパイプは TCP/IP 経由で転送されるため、パフォーマンスが低下します。ローカル マシンの通信には名前付きパイプを使用します。
Unix と Windows にはどちらも「名前付きパイプ」と呼ばれるものがありますが、動作が異なります。Unix では、名前付きパイプは一方通行であり、通常は 1 つのリーダーと 1 つのライターしかありません。ライターが書き込み、リーダーが読み取ります。
Windows では、「名前付きパイプ」と呼ばれるものは、TCP ソケットに似た IPC オブジェクトです。物事は双方向に流れることができ、いくつかのメタデータがあります (相手側で物事の資格情報を取得できるなど)。
Unix の名前付きパイプは、ファイルシステム内の特別なファイルとして表示され、シェルを含む通常のファイル IO コマンドでアクセスできます。Windowsのものはそうではなく、特別なシステムコールで開く必要があります(その後、通常のwin32ハンドルのように動作します)。
さらに紛らわしいことに、Unix には「Unix ソケット」または AF_UNIX ソケットと呼ばれるものがあり、これは win32 の「名前付きパイプ」のように (完全にはそうではありませんが) 動作し、双方向です。
Linux Pipes
First In First Out (FIFO) プロセス間通信メカニズム。
名前
のないパイプ コマンド ラインでは、"|" で表されます。2 つのコマンドの間。
名前付きパイプ
FIFO 特殊ファイル。パイプを作成すると、通常のファイルと同じようにパイプを使用できます (開く、閉じる、書き込み、読み取りなど)。
コマンドラインから「myPipe」と呼ばれる名前付きパイプを作成するには ( man ページ):
mkfifo myPipe
c から名前付きパイプを作成するには、ここで「パス名」はパイプに付けたい名前で、「モード」にはパイプに付けたいパーミッションが含まれます ( man ページ):
#include <sys/types.h>
#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);
ウィキペディアによると:
[...]従来のパイプは、匿名で存在し、プロセスが実行されている間だけ存続するため、「名前なし」です。名前付きパイプはシステムに永続的であり、プロセスの存続期間を超えて存在するため、使用されなくなったら「リンク解除」または削除する必要があります。プロセスは通常、IPC(プロセス間通信)を実行するために名前付きパイプ(通常はファイルとして表示されます)に接続します。
比較
echo "test" | wc
に
mkdnod apipe p
wc apipe
wcはまでブロックします
echo "test" > apipe
実行します
パイプは、アプリケーション間でデータをストリーミングする方法です。Linuxでは、これを常に使用して、あるプロセスの出力を別のプロセスにストリーミングします。宛先アプリはその入力ストリームがどこから来ているのかわからないため、これは匿名です。する必要はありません。
名前付きパイプは、既存のパイプにアクティブに接続し、そのデータをフーバーアップする方法にすぎません。これは、プロバイダーがどのクライアントがデータを消費するかを知らない状況向けです。
Windowsアプリケーションのプロセス間通信(主に)。Unixのアプリケーション間で通信するためにソケットを使用するのと似ています。
シェルは他のシェルと何も共有できないため、unix/linux コンテキストの名前付きパイプを使用して、2 つの異なるシェルを通信させることができます。
さらに、同じシェルで 2 回インスタンス化された 1 つのスクリプトは、2 つのインスタンスを介して何も共有できません。start() および stop() 関数を含むデーモンをコーディングするときに名前付きパイプの使用法を見つけ、同じスクリプトを使用して 2 つのアクションを実行したいと考えました。
名前付きパイプ (またはあらゆる種類のセマフォ) がなければ、バックグラウンドでスクリプトを開始しても問題ありません。問題は、それが終了すると、バックグラウンドでインスタンスにアクセスできなくなることです。
したがって、彼に停止コマンドを送信したい場合は、できません。名前付きパイプを使用せずに同じスクリプトを実行し、stop() 関数を呼び出しても、実際には別のインスタンスを実行しているため、何もしません。
解決策は、デーモンを開始するときに、1 つの READ ともう 1 つの WRITE の 2 つのパイプを実装することでした。次に、他のタスクの中で、彼に READ パイプをリッスンさせます。次に、Stop() 関数には、パイプにメッセージを書き込むコマンドが含まれています。このコマンドは、終了 0 を実行するバックグラウンド実行スクリプトによって処理されます。このようにして、同じスクリプトの 2 番目のインスタンスは実行するタスクのみを持ちます。最初のインスタンスに停止を指示します。
このようにして、1 つのスクリプトだけが開始および停止できます。
もちろん、たとえばタッチでストップをトリガーするなど、さまざまな方法があります。しかし、これは素晴らしく、コーディングするのに興味深いものです。
名前付きパイプは、プロセス間通信用のWindowsシステムです。SQLサーバーの場合、サーバーがクライアントと同じマシン上にある場合は、TCP / IPではなく、名前付きパイプを使用してデータを転送することができます。