Loading article…
UUCP（Unix-to-Unix Copy）[ 1 ]は、コンピュータ間でコマンドのリモート実行やファイル、電子メール、ネットニュースの転送を可能にするコンピュータプログラムとプロトコルのスイートです。
という名前のコマンドuucpは、スイートに含まれるプログラムの1つで、ファイルコピー操作を要求するためのユーザーインターフェイスを提供します。UUCPスイートにはuux、(リモートコマンド実行用のユーザーインターフェイス)、uucico(ファイル転送を実行する通信プログラム)、uustat(最近のアクティビティの統計情報を報告する)、uuxqt(リモートマシンから送信されたコマンドを実行する)、uuname(ローカルシステムのUUCP名を報告する)も含まれています。スイートの一部のバージョンには、uuencode/ uudecode(8ビットバイナリファイルを7ビットテキスト形式に変換し、その逆も行う)が含まれています。
UUCPは元々1970年代と1980年代にUnix上で開発され、 Unixライクなシステムと最も密接に関連していますが、DOS、OS/2、OpenVMS（VAXハードウェアのみ）、AmigaOS、[ 2 ]クラシックMac OS、さらにはCP/Mなど、Unixライクではないオペレーティングシステム向けのUUCP実装も存在します。
UUCPは元々 AT&Tベル研究所でマイク・レスクによって書かれた。[ 3 ] 1978年までに、ベルシステム内の82台のUNIXマシンで主にソフトウェア配布のために使用されていた。1979年にUnixバージョン7の一部としてリリースされた。[ 4 ]
米国からの最初の UUCP メールは 1979 年に英国に到着し、英国、オランダ、デンマーク間のメールは 1980 年に開始され、1982 年にEUnetを介して定期サービスとなった。 [ 5 ] [ 6 ]
オリジナルの UUCP は、 1983 年頃に AT&T の研究者である Peter Honeyman、David A. Nowitz、および Brian E. Redman によって書き直されました。この書き直しはHDBまたはHoneyDanBer uucpと呼ばれ、後に機能強化、バグ修正、およびBNU UUCP ("Basic Network Utilities") として再パッケージ化されました。[ 7 ]
これらのバージョンはそれぞれプロプライエタリソフトウェアとして配布されていたため、イアン・ランス・テイラーは1991年にゼロから新しいフリーソフトウェアバージョンを作成することにしました。 [ 8 ] Taylor UUCPはGNU一般公衆ライセンスの下でリリースされました。Taylor UUCPは、一部のオリジナルのネットワークワームが予期しないシェルコマンドをリモートで実行することを可能にしていたセキュリティホールに対処しました。Taylor UUCPはまた、以前のすべてのバージョンのUUCPの機能を取り入れており、他のどのバージョンとも通信でき、他のバージョンの同様の設定ファイル形式を使用することもできます。
UUCPはUNIX以外のオペレーティングシステム、特にDOSシステムにも実装されました。UUSLAVE/GNUUCP（John Gilmore、Garry Paxinos、Tim Pozar）、UUPC/extended（Kendra Electronic WonderworksのDrew Derbyshire）、FSUUCP（IODesignのChristopher Ambler）などのパッケージは、パーソナルコンピュータに初期のインターネット接続をもたらし、相互接続された大学システムを超えてネットワークを拡大しました。FSUUCPは、 GalacticommのMajor BBSやMustang SoftwareのWildcat! BBSなど、UUCPネットワークに接続して電子メールやUsenetトラフィックを交換する多くの電子掲示板システム（BBS）パッケージの基盤となりました。例として、UFGATE（John Galvin、Garry Paxinos、Tim Pozar）は、 FidoNetとUUCPプロトコルを実行するネットワーク間のゲートウェイを提供するパッケージでした。
FSUUCPは、テイラーが改良した「i」プロトコルを採用した唯一の他の実装であり、ほとんどのUUCP実装で使用されている標準の「g」プロトコルに比べて大幅な改善が図られていた。
インターネットが広く普及する以前は、コンピュータは企業や組織内の小規模なローカルエリアネットワークでのみ接続されていました。また、多くの場合、モデムが搭載されており、ダイヤルアップ電話回線を介して文字モード端末からリモートで使用できました。UUCPは、コンピュータのモデムを使用して他のコンピュータにダイヤルアウトし、それらの間に一時的なポイントツーポイントリンクを確立します。UUCPネットワーク内の各システムには、電話番号、ログイン名、パスワードなどを含む近隣システムのリストがあります。近隣システムに対して作業（ファイル転送やコマンド実行要求）がキューに入れられると、プログラムは通常、そのシステムを呼び出して作業を処理します。プログラムは、近隣システムを定期的にポーリングして、自分の側でキューに入れられている作業を確認することもできます。これにより、ダイヤルアウト機能を持たない近隣システムも参加できます。uucicouucico
時が経つにつれ、ダイヤルアップリンクはインターネット接続に置き換えられ、UUCP には多数の新しいリンク層プロトコルが追加されました。これらの新しい接続により、新しいネットワークを活用する新しいアプリケーション プロトコルが開発されたため、UUCP の必要性自体も減少しました。今日では、UUCP はダイヤルアップリンクではほとんど使用されていませんが、TCP/IP上では時折使用されています。[ 9 ] [ 10 ] 2006 年初頭の時点で、関係するシステムの数は 60 の企業にわたって 1500 ～ 2000 サイトで稼働していました。UUCP の長寿は、低コスト、広範なログ記録、ダイヤルアップへのネイティブフェイルオーバー、および永続的なキュー管理 に起因すると考えられます。
UUCPは通常、ユーザーがターゲットシステムにログインしてからUUCPプログラムを実行することで起動します。ほとんどの場合、転送に使用する既知のユーザーアカウントにログインすることで自動化されますuucico。このアカウントのシェルは に設定されています。したがって、自動転送の場合、別のマシンは呼び出し先のマシンへのモデム接続を開き、既知のアカウントにログインするだけで済みます。
uucicoが実行されると、呼び出し元のマシン上の別のUUCPプログラムからコマンドを受信し、セッションを開始します。セッションには3つの明確な段階があります。
uucico は起動時に識別文字列 を送信して応答します。ここで、\20 ( 8 進数、10 進数 16) は制御文字 P であり、\0 は末尾のヌル文字です。呼び出し元の UUCP は で応答します。ここで、optionsは 0 個以上の Unix ライクなオプションスイッチを含む文字列です。これには、パケットサイズとウィンドウサイズ、サポートされる最大ファイルサイズ、デバッグオプションなどが含まれます。\20Shere=hostname\0\20Scallernameoptions\0
両システムの構成によっては、ここで通話が終了する場合があります。例えば、発信者がシステム名で応答した場合、着信側のシステムは発信者を認識できない場合、RYou are unknown to me\0応答文字列を送信してから切断し、自動的に通話を終了する場合があります。
2つのシステムが正常にハンドシェイクを完了すると、呼び出し元は一連のファイル要求の送信を開始します。ファイル要求には4種類あります。
Hコマンドを送信した後、呼び出し側システムは最終パケット\20OOOOOO\0（制御パケット、6つのオー、ヌル終端文字）を送信し、着信側システムは\20OOOOOO\0（制御パケット、7つのオー、ヌル終端文字）で応答します。一部のシステムは、Hコマンドの受信が成功すると、最終ハンドシェイクを行わずに接続を切断します。
UUCP のプロトコル群の中で、基盤となる g プロトコルは、エラーのない形式で情報を転送する役割を担っています。このプロトコルは、パケット配信のための汎用システムとして開発されたため、UUCP パッケージ全体では使用されていない多くの機能を備えています。これには、ファイル転送と混在するコマンドデータを送信できるセカンダリチャネルや、送信中にパケットサイズとウィンドウサイズを再ネゴシエートする機能などが含まれます。これらの追加機能は、UUCP スタックの実装によっては利用できない場合があります。[ 11 ]
パケット形式は、6 バイトのヘッダーと、0 ～ 4096 バイトのペイロードで構成されます。パケットは、単一の \020 (制御 P) で始まります。これに続いて、1 バイトの「K」が続きます。この K には、パケットサイズが 32 ～ 4096 バイトであることを示す 1 ～ 8 の値、または制御パケットであることを示す 9 が含まれます。多くのシステムは K=2 (64 バイト) のみをサポートしていました。次の 2 バイトは、ヘッダーを含まないペイロードの 16 ビットのチェックサムです。次の 1 バイトはデータタイプで、最後の 1 バイトはヘッダーの XOR であり、ペイロードとは別にチェックできるようにします。[ 11 ]
制御バイトは、TTXXXYYY の形式の 3 つのビットフィールドで構成されます。TT はパケットタイプで、制御パケットの場合は 0 (有効にするには K=9 も必要)、代替データの場合は 1 (UUCP では使用されません)、データの場合は 2、K の意味を再定義する短いパケットの場合は 3 です。データパケットでは、XXX はこのパケットのパケット番号 (0 ～ 7) で、YYY は最後に正しく受信されたパケットです。これにより、ウィンドウ内に最大 8 つのパケットが提供されます。制御パケットでは、XXX はコマンドを示し、YYY はさまざまなパラメータに使用されます。たとえば、転送は、TT=0 (制御)、XXX=7、ウィンドウ内のパケット数 YYY の短い制御パケットを送信することによって開始され、次に XXX=6、パケット長 YYY (K でエンコードされるのと同じように) の別のパケットを送信し、次に最初のパケットと同一ですが XXX=5 の 3 番目のパケットを送信します。[ 11 ]
gプロトコルは、エンドポイント間の潜在的に長い遅延に対処するために、シンプルなスライディングウィンドウ システムを使用します。このプロトコルでは、パケットサイズを32～4096バイト（8ビット）に設定でき、ウィンドウには1～7個のパケットを含めることができます。理論的には、4kパケットと7パケットウィンドウ（4096 × 7）を使用するシステムは、 ZMODEM のような最高のファイル転送プロトコルと同等またはそれ以上のパフォーマンスを提供します。実際には、初期の実装の多くは64x3という単一の設定しかサポートしていませんでした。その結果、gプロトコルはパフォーマンスが低いという不当な評判を得ています。パケットとウィンドウサイズに関する混乱がGプロトコルの開発につながり、Gプロトコルは4096x3を常に使用するという点だけが異なっていました。Taylor UUCPはGをサポートしていませんでしたが、有効な要求ウィンドウまたはパケットサイズはすべてサポートしていたため、Gで始まるリモートシステムはTaylorのgと問題なく動作し、2つのTaylorシステム間ではさらに高速な接続をネゴシエートすることができました。[ 11 ]
Telebitモデムは、プロトコル スプーフィングを使用して、リモート システムに送信されるパケット終了マーカーを検出し、ACKリモート システムが既にパケットを受信して正しく復号したかのように見せかけることで、g プロトコル転送のパフォーマンスを向上させました。これにより、ローカル コンピュータのソフトウェア スタックが次のパケットを非常に速く送信するようにトリガーされ、転送はほぼ連続的になりました。2 つのモデム間のデータは、MNP に基づく独自のプロトコルを使用してエラー訂正されました。このプロトコルは、Gプロトコルが通常行うよりもはるかに優れた方法で Telebit の半二重接続上で動作しました[ 11 ]。これは、一般的な 64x3 の場合、リモート システムが一定のストリームを送信してACK低速の戻りチャネルをオーバーフローさせるためです。モデムの本来高いデータ レート（最大 23 kbps）と組み合わせることで、全体的なスループットが大幅に向上し、一般的に 2400 ビット/秒のモデムの約 7 倍の速度で動作しました。[ 12 ]これらは長距離通話料金の削減によりすぐに元が取れるため、UUCPホストで広く使用されました。
UUCPの実装には、特定のリンクで使用するための他の転送プロトコルも含まれています。
fプロトコルは、7ビットのエラー訂正リンク上で動作するように設計されています。これは元々、1980年代に一時的に普及したX.25リンクで使用することを意図していました。データをパケット化せず、代わりにファイル全体を1つの長い文字列として送信し、その後にファイル全体のチェックサムを続けます。同様のxプロトコルはほとんど、あるいは全く使用されなかったようです。dプロトコルはxに似ていましたが、ベル研究所の多くのオフィスを接続していたデータキットネットワークで使用することを意図していました。[ 11 ]
tプロトコルはBSD版UUCPに端を発し、類似のプロトコルと同様に、8ビットのエラーフリーTCP/IPリンク上で動作するように設計されています。エラー訂正機能は一切なく、コマンドデータとファイルデータを512バイトまたは1024バイトのパケットに分割して、一般的なTCPフレームに容易に収まるようにするだけのシンプルなプロトコルです。
eプロトコル（「e」はイーサネットの略）はMASSCOMPのClem Coleによって開発され、後のHoneyDanBerバージョンでBrian Redmanによって広くリリースされました。tプロトコルよりも前に開発およびリリースされましたが、BSD版のUUCPが主流の実装であったため、tプロトコルの方が一般的に使用されました。eプロトコルとtプロトコルの違いは、コマンドがパケット化されず、通常の文字列として送信される点と、ファイルが最も近い20バイトにパディングされる点のみです。[ 11 ] [ 13 ]
とuucpのuuxqt機能は、適切なメール ユーザー インターフェイスと配信エージェント プログラムを使用して、マシン間で電子メールを送信するために使用できます。シンプルな UUCP 電子メール アドレスは、隣接するマシン名、感嘆符(しばしばbangと発音されます)、隣接マシンのユーザー名で構成されます。たとえば、アドレスbarbox!user は、隣接マシンbarboxのユーザーuserを参照します。[ 14 ]
さらに、メールはネットワークを経由してルーティングされ、宛先に到達するまでに任意の数の中間ノードを経由することができました。当初は、中間ホスト名を感嘆符で区切った完全なパスを指定する必要がありました。たとえば、マシンbarbox がローカルマシンに接続されていないが、 barboxがローカルマシンと通信するマシンfoovaxに接続されていることがわかっている場合、メールを送信する適切なアドレスはfoovax!barbox!userになります。
ユーザーbarbox!user は通常、UUCP メールアドレスを…!bigsite!foovax!barbox!user のような形式で公開します。これにより、メールはマシンbigsite (おそらく誰もがアクセスできる、よく知られていて接続性の高いマシン) を経由してマシンfoovaxからbarbox上のユーザーuserのアカウントにルーティングされます。送信者の場所によってパスが異なるため、完全なパスを公開しても意味がありません (たとえば、あるサイトの Ann はパスgway!tcol!canty!uoh!bigsite!foovax!barbox!user を介して送信する必要があるのに対し、別の場所の Bill はパスpdp10!router22!bigsite!foovax!barbox!user を介して送信する必要があります)。多くのユーザーは、さまざまな大規模でよく知られたサイトから複数のルートを提案し、メール送信者からの接続サービスをさらに改善し、場合によってはより高速な接続サービスを提供します。
このような形式の電子メールアドレスは「バンパス」と呼ばれていました。1981年当時、8台から10台のマシン（またはホップ）を経由するバンパスは珍しくなく、深夜のダイヤルアップUUCPリンクでは送信に1週間かかることもありました。バンパスは、メッセージが失われることが多かったため、送信時間と信頼性の両方を考慮して選択されることが多かったのです。ホストによっては、より「高速な」ルートでメールを送信するためにパスを「書き換える」ことさえ試みましたが、この方法は好ましくないと考えられていました。
.uucpという「擬似ドメイン」は、ホスト名が UUCP ネットワークで到達可能であることを示すために使用されることがありましたが、これは正式にはドメイン ネーム システム(DNS)にトップ レベル ドメインとして登録されることはありませんでした。uucp コミュニティは独自に管理を行っており、DNS を管理する方法や規則とはうまく調和しませんでした。.uucp は必要な場所で機能します。一部のホストは、受信 SMTP 接続で .uucp アドレスが認識された場合、SMTP キューからメールをゲートウェイ マシン上の uucp キューに転送します。
Usenet のトラフィックは、当初は UUCP プロトコルを介して、通常はダイヤルアップ モデムを介して送信されていました。各受信ノードでは、Usenet 記事のPathヘッダー行に、パスの前に現在のノード名が「!」で区切られて追加されます。たとえば、Path: utzoo!henryでノードutzooからノードdecvaxに届いた記事の場合、その行はPath: decvax!utzoo!henryに変更されます。Usenet ソフトウェアは、記事が投稿されたニュース グループを受信するように設定されているすべての隣接ノードに各記事のコピーを送信します。ただし、その隣接ノードが既にPath行に含まれている場合は除きます。このように、これらのパスは、記事が既に記事を持っているノードに「ループバック」しないようにするために使用されました。
一般的に、他の古い電子メールアドレス形式と同様に、バンパスは現在では「@表記」に置き換えられており、UUCPを使用しているサイトでも使われています。UUCP専用サイトはDNSドメイン名を登録し、そのドメインを処理するDNSサーバーにMXレコードを提供させることで、そのサイト宛のインターネットメールをインターネット上のUUCPホストに配信し、そこからUUCPサイトにメールを配信することができます。
UUCPNETとは、UUCPを介して接続されたコンピュータネットワーク全体の総称でした。このネットワークは非常に非公式なもので、数千もの民間企業や大学などが所有するシステム間の相互協力の精神に基づいて維持されていました。特に民間部門では、UUCPリンクは企業の上層部の正式な承認なしに確立されることがよくありました。UUCPネットワークは、新しいシステムやダイヤルアップリンクが追加されたり、削除されたりするなど、常に変化していました。
UUCPマッピングプロジェクトは、オープンメールリレーとして機能するマシン間の接続マップを作成し、管理されたネームスペースを確立することを目的とした、ボランティアによる概ね成功した取り組みでした。各システム管理者は、自分のマシンが接続するシステムのリストと、それぞれの接続に対するランキングを電子メールで送信しました。送信されたマップエントリは、ネットワーク内のすべての接続を記述する単一のファイルセットに統合する自動プログラムによって処理されました。これらのファイルは、この目的のために専用のニュースグループで毎月公開されました。UUCPマップファイルは、「pathalias」などのソフトウェアで使用して、あるマシンから別のマシンへのメールの最適な経路を計算し、その経路を自動的に提供することができました。UUCPマップにはサイトの連絡先情報も記載されていたため、UUCPNETへの参加を希望するサイトは、将来の隣人を簡単に見つけることができました。
UUCPホストの多くは、特に大学のホストは、インターネット黎明期にはインターネットにも接続されており、インターネットのSMTPベースのメールとUUCPメール間の電子メールゲートウェイが開発されました。UUCP接続を持つシステムのユーザーは、インターネットユーザーとメールをやり取りできるようになり、インターネット回線を利用することで、低速なUUCPネットワークの大部分を迂回することが可能になりました。こうしたインターフェースを容易にするため、インターネットドメインネームスペース内に「UUCPゾーン」が定義されました。
このインフラストラクチャが整備されたことで、UUCPの強みは、ダイヤルアップモデムで別の協力コンピュータに接続するだけで、インターネット電子メールとUsenet接続が可能になった点にありました。当時は、真のインターネットアクセスには、インターネット接続ポイント（PoP）への接続を提供する専用データ回線が必要で、どちらも費用がかさみ、手配も困難でした。それに対し、UUCPネットワークへの接続は、近隣システムの管理者に数回電話をかけるだけで通常は確立できました。近隣システムは多くの場合、電話料金のほとんどがかからないほど近距離にありました。
uuxはUUCP上でのリモートコマンド実行です。uuxコマンドは、リモートシステム上でコマンドを実行したり、リモートシステムからのファイルを使用してローカルシステム上でコマンドを実行したりするために使用されます。このコマンドはデーモンによって実行され、デーモンは、次ホップノードが利用可能になったときに、リモート実行要求を単に別の種類のファイルとして扱い、リモートシステムに一括送信します。その後、リモートシステムは要求されたコマンドを実行し、元のシステムが利用可能になったときに結果を返します。これらの転送はどちらも、マルチホップパスを介して間接的に行われ、利用可能なウィンドウは任意です。常に利用可能なネイバー上でコマンドを実行する場合でも、uuxは即時ではありません。uucico
UUCPの利用は、安価なSLIPおよびPPPサービスを提供するインターネットサービスプロバイダーの台頭とともに衰退し始めた。UUCPマッピングプロジェクトは2000年末に正式に終了した。
UUCPプロトコルは現在、インターネットのTCP/IPベースのプロトコルであるSMTP（メール用）とNNTP（ Usenetニュース用）にほぼ置き換えられている。
2012年7月、オランダのインターネットプロバイダーXS4ALLはUUCPサービスを閉鎖し、「おそらく世界でまだUUCPを提供している最後のプロバイダーの1つ」だと主張した。当時、同社のユーザーはわずか13人だった（閉鎖前は数年間、新規ユーザーからのリクエストを拒否していた）。[ 15 ]
UUCPの残存機能の一つとして、チャットファイル形式があり、これはExpectソフトウェアパッケージにほぼそのまま引き継がれている。
UUCP は、他の場所では姿を消した後も、特殊用途の高コストリンク (例えば、海上衛星リンク) で長期間使用され続けており、[ 16 ]現在もレガシー ユースとして残っています。レガシー ユースに加えて、2021 年に、特にHF帯域での電気通信において、新しい革新的な UUCP ユースが拡大しており、例えば、アマゾンの熱帯雨林のコミュニティでの電子メールの交換やその他の用途に使用されています。Ian の UUCP へのパッチが UUCP Debian Linux パッケージ[ 17 ]に提供され、UUCP HF 接続を提供する HERMES (High-Frequency Emergency and Rural Multimedia Exchange System) プロジェクトに適合しました。[ 18 ]
2000年代半ば、ファビアン・ペンソとヤン・ヒロウは、固定IPアドレスを持たないコンピュータでもSendmailやPostfixのような標準的なメール転送エージェント（MTA）を実行したい場合に使うために、 TCP / IP上のUUCP（多くの場合、SSHプロトコル[ 10 ]を使用して暗号化される）を提案した。
バンのようなパスは、ルーティングのためではなく、メッセージの次の送信先を指定するのではなく、メッセージのヘッダーにそのメッセージが通過したノードを記録するために、Usenetネットワーク内で今でも使用されています。 [ 19 ] 「バン パス」は、ネットワーク ホスト間の明示的に指定されたルーティングパスを表す表現としても使用されます。この使用法は、必ずしも UUCP、IP ルーティング、電子メール メッセージング、または Usenet に限定されるものではありません。
遅延耐性ネットワークプロトコルの概念は、2000年代初頭に再検討されました。[ 20 ] UUCPで使用されるものと同様の技術は、遅延や重大な障害が発生する他のネットワークにも適用できます。
実際のスループットは約 14400 bps です。