TCP FS
現代のUnixには存在せず、Unixボックスにファントムを置きたいものがもう1つあります。 mooのように単純であり、なぜ誰もそれをやらなかったのかは理解できません。
#cat /tcp/host/port > local_file
確かに、別のファイル名構文、URLスタイル-tcp：// host：portを使用したいのですが、これはすでに詳細です。 当然、TCPとともにUDPが要求され、通常は問題ありません。
ネタバレ見出し
一般に、Phantomのunixサブシステムは、従来のUnix名/usr/include/stdio.hとURL tcp：//ya.ru：80の両方を「食べます」。
TCPには、明らかな問題があります-リッスンするか接続する必要があるかはわかりませんが、「ファイル」名に特定のサフィックスを指定することで解決できます。
このテーマについて、私たちが止まらずに次の話に移ると言うことはこれ以上ありません。
TRFSは簡単なリモートファイルシステムです。
テスト環境の1つで、Phantomはディスクのないマシンで作業し、ネットワーク上のリモートページングを整理したいと考えていました。 このために、最小限のネットワークFSを作成しました。
参照：
プロトコルはtftpに似ていますが、非同期を許可します-リクエストは同期的に応答を待つ必要はありません。代わりにクライアントは待機せずに恥をかかずにリクエストを送信し、ランダムに応答を受信し、受信されなかったタイムアウトを再要求します。
交換はセクター内です。 実際、Phantom自体はリモートディスクとまったく同じプロトコルを使用します。
ファイルへのアクセスは、セッションIDおよびファイルIDによって行われます。 これにより、必要に応じて逆参照を省略し、固定番号でファイルを操作することができます-繰り返しますが、これはこの実装で行われ、Phantomは常にファイル番号ゼロを要求し、サーバー自体はそれを探す場所を知っています。 しかし、「名前で番号を取得する」という要求があります。
セッション識別子は、サーバーが再起動され、ファイル番号を忘れたという事実のマーカーとして使用されます。 この状況では、セッションIDに不一致が表示され、クライアントは、指定された名前のファイル番号を再度要求することで処理する必要があるエラーを受け取ります。 しかし、私自身はまだ必要ないので、プロトコルのこの部分を書いていません。
このプロトコルは実装に関して非常に軽量であるため、サーバーでさえ弱いマイクロコントローラーにプッシュすることができます。 そして、クライアントはさらにそうです。
プロトコルはUDP上で実行されます。 必要に応じて、健康に使用します。 非同期性と順不同の再送により、プロトコルは非常にシンプルで、非常に効果的です。 リクエストを正常に実行する必要がある場合にのみ、外部を確保する必要があります。 TRFS自体は、ネットワークを介して応答が到着する順序でうまく機能します。