ユーシーピー

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年に}バージョン7 Unixの一部としてリリースされました。^[4]

米国からの最初のUUCP電子メールは1979年に英国に到着し、英国、オランダ、デンマーク間の電子メールは1980年に開始され、1982年にEUnet経由で通常のサービスになりました。 ^{[5] [6]}

オリジナルのUUCPは、 1983年頃にAT&Tの研究者ピーター・ハニーマン、デビッド・A・ノウィッツ、ブライアン・E・レッドマンによって書き直されました。書き直したものはHDBまたはHoneyDanBer uucpと呼ばれ、後に機能強化され、バグが修正され、BNU UUCP（「Basic Network Utilities」）として再パッケージ化されました。^[7]

これらの各バージョンはプロプライエタリソフトウェアとして配布されたため、イアン・ランス・テイラーは1991年に新しいフリーソフトウェアバージョンをゼロから作成することになった。 ^[8] Taylor UUCPはGNU General Public Licenseの下でリリースされた。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 は、UUCP ネットワークに接続して電子メールやUsenetトラフィックを交換する Galacticomm のMajor BBSやMustang SoftwareのWildcat! BBSなど、多くの電子掲示板システム(BBS) パッケージの基礎となりました。たとえば、UFGATE (John Galvin、Garry Paxinos、Tim Pozar) は、 Fidonetプロトコルと UUCP プロトコルを実行するネットワーク間のゲートウェイを提供するパッケージでした。

FSUUCP は、Taylor の拡張 'i' プロトコルの唯一の実装であり、ほとんどの UUCP 実装で使用される標準 'g' プロトコルを大幅に改良したものです。^{[引用が必要]}

インターネット アクセスが広く普及する前は、コンピュータは会社や組織内の小規模なローカル エリア ネットワークでのみ接続されていました。また、ダイヤルアップ電話回線を介してキャラクタ モード端末からリモートで使用できるように、モデムが装備されていることもよくありました。UUCP はコンピュータのモデムを使用して他のコンピュータにダイヤル アウトし、コンピュータ間に一時的なポイントツーポイント リンクを確立します。UUCP ネットワーク内の各システムには、電話番号、ログイン名、パスワードなどを含む近隣システムのリストがあります。近隣システムのキューに作業(ファイル転送またはコマンド実行要求) が入っている場合、プログラムは通常、そのシステムを呼び出して作業を処理します。プログラムは、近隣システムを定期的にポーリングして、そのシステム側でキューに入っている作業をチェックすることもできます。これにより、ダイヤル アウト機能のない近隣システムも参加できます。 uucicouucico

時間が経つにつれて、ダイヤルアップリンクはインターネット接続に置き換えられ、UUCP はいくつかの新しいリンク層プロトコルを追加しました。これらの新しい接続では、新しいネットワークを利用するための新しいアプリケーションプロトコルが開発されたため、UUCP の必要性はまったくなくなりました。今日、UUCP はダイヤルアップリンクではほとんど使用されていませんが、TCP/IPでは時々使用されます。^{[9] [10] 2006 年初頭の時点で、関係するシステムの数は 60 の企業で 1500 から 2000 のサイトで実行されていました。UUCP が長く使用されてきた理由は、低コスト、広範なログ記録、ダイヤルアップへのネイティブ}フェイルオーバー、および永続的なキュー管理 にあります。

UUCP は通常、ユーザーがターゲット システムにログインして UUCP プログラムを実行することによって開始されます。ほとんどの場合、これは、アカウントのシェルが に設定されている、転送に使用される既知のユーザー アカウントにログインすることによって自動化されますuucico。したがって、自動転送の場合、別のマシンは、呼び出されたマシンへのモデム接続を開き、既知のアカウントにログインするだけです。

uucico が実行される場合、呼び出し側のマシン上の別の UUCP プログラムからコマンドを受信し、セッションを開始します。セッションには 3 つの異なる段階があります。

1. 最初のハンドシェイク
2. ファイルリクエスト
3. 最後の握手

起動時に、uucico は識別文字列 を送信して応答します。ここで、\20 は control-P 文字、\0 は末尾のヌルです。呼び出し元の UUCP は で応答します。ここで、options は0 個以上の Unix 風のオプション スイッチを含む文字列です。これには、パケット サイズとウィンドウ サイズ、サポートされる最大ファイル サイズ、デバッグ オプションなどが含まれます。 \20Shere=hostname\0\20Scallername options\0

2 つのシステムの設定によっては、ここで通話が終了する場合があります。たとえば、発信者がシステム名で応答した場合、着信側システムは発信者を認識しない場合はオプションで電話を切り、RYou are unknown to me\0応答文字列を送信してから切断することがあります。

2 つのシステムが正常にハンドシェイクすると、呼び出し側は一連のファイル要求の送信を開始します。次の 4 つのタイプがあります。

S は、呼び出し側から呼び出されたシステムにファイルを送信します (アップロード)。送信元と送信先の名前が指定されているため、受信側でファイル名を変更できます。呼び出されたシステムで S コマンドが受信されると、成功してファイルを受け入れる準備ができている場合は SY で応答し、失敗した場合は SNx で応答します (x は失敗の理由)。呼び出し側が SY を受信すると、最初のハンドシェイク中に選択されたプロトコルを使用してファイルのアップロードを開始します (以下を参照)。転送が完了すると、呼び出されたシステムは、ファイルを正常に受信した場合は CY で応答し、失敗した場合は CN5 で応答します。

R は、呼び出されたシステムが呼び出し元にファイルを送信する (ダウンロード) ように要求するものです。それ以外は S と同様で、RY と RN を使用してコマンドが受け入れられ、データの送信を開始するか問題が発生したかを示し、転送の最後に呼び出し元から CY と CN5 を期待します。

X は、呼び出されたシステムで実行されるコマンドをアップロードします。これを使用して、そのシステムから別のシステムを呼び出し、ファイルを配信することができます。呼び出されたシステムは、成功した場合は XY を、失敗した場合は XN を応答します。

Hは Hangup の略で、発信者が通話を終了したことを示します。着信側システムは、成功した場合は HY で応答し、失敗した場合は HN で応答します。

H コマンドを送信した後、発信側システムは最終パケット\20OOOOOO\0(control-P、6 オーム、ヌル ターミネータ) を送信し、着信側システムは\20OOOOOO\0(control-P、7 オーム、ヌル ターミネータ) で応答します。一部のシステムでは、H コマンドの受信に成功すると、単にハングアップし、最終ハンドシェイクは行いません。

UUCP のプロトコル群の中で、基礎となる g プロトコルは、エラーのない形式で情報を転送する役割を担っています。このプロトコルは、パケット配信用の汎用システムとして開発されたため、UUCP パッケージ全体では使用されていない機能もいくつかあります。これには、ファイル転送に割り込んでコマンド データを送信できるセカンダリ チャネルや、送信中にパケットとウィンドウ サイズを再ネゴシエートする機能などがあります。これらの追加機能は、UUCP スタックの実装によっては利用できない場合があります。^[11]

パケットのフォーマットは、6 バイトのヘッダーと、それに続く 0 から 4096 バイトのペイロードから構成されます。パケットは 1 つの \020 (制御 P) で始まります。その後に続く 1 バイトは「K」と呼ばれ、パケット サイズが 32 から 4096 バイトであることを示す 1 から 8 の値、または制御パケットを示す 9 が含まれます。多くのシステムでは、K=2 (64 バイト) のみがサポートされていました。次の 2 バイトは、ヘッダーを含まないペイロードの 16 ビット チェックサムです。次のバイトはデータ タイプで、最後のバイトはヘッダーの XOR であり、ペイロードとは別にチェックできます。^[11]

制御バイトは、TTXXXYYY 形式の 3 つのビット フィールドで構成されます。TT はパケットの種類、0 は制御パケット (これも有効にするには K=9 が必要です)、1 は代替データ (UUCP では使用されません)、2 はデータ、3 は K の意味を再定義する短いパケットを示します。データ パケットでは、XXX はこのパケットの 0 から 7 までのパケット番号、YYY は正しく受信された最後のパケットです。これにより、ウィンドウに最大 8 つのパケットが提供されます。制御パケットでは、XXX はコマンドを示し、YYY はさまざまなパラメーターに使用されます。たとえば、転送は、TT=0 (制御)、XXX=7、YYY がウィンドウ内のパケット数である短い制御パケットを送信することによって開始され、次に XXX=6、YYY がパケット長 (K でエンコードされるもの) である別のパケットを送信し、次に最初のパケットと同じだが XXX=5 である 3 番目のパケットを送信します。^[11]

g プロトコルは、エンドポイント間の潜在的に長い遅延に対処するために、単純なスライディング ウィンドウシステムを使用します。このプロトコルでは、パケットのサイズを 64 ～ 4096 8 ビット バイトにすることができ、ウィンドウには 1 ～ 7 個のパケットを含めることができます。理論上は、4k パケットと 7 パケット ウィンドウ (4096x7) を使用するシステムは、ZMODEMなどの最高のファイル転送プロトコルと同等かそれ以上のパフォーマンスを提供します。実際には、多くの実装では 64x3 の単一の設定しかサポートされていませんでした。その結果、g プロトコルはパフォーマンスが低いという不当な評判を得ています。パケット サイズとウィンドウ サイズに関する混乱から、常に 4096x3 を使用するという点だけが異なっている G プロトコルが生まれました。Taylor UUCP は G をサポートしていませんでしたが、有効な要求ウィンドウ サイズまたはパケット サイズをサポートしていたため、G で始まるリモート システムは Taylor の g で問題なく動作し、2 つの Taylor システムはさらに高速な接続をネゴシエートできました。^[11]

テレビットモデムは、リモート システムに送信されるパケット終了マーカーを認識し、リモート システムがすでにパケットを受信して​​正しくデコードしたかのように見せかけて、すぐにローカル ホストにパケットを返信することで、プロトコルACKスプーフィングを使用して g プロトコル転送のパフォーマンスを改善しました。これにより、ソフトウェア スタックが次のパケットを送信するようにトリガーされ、転送がほぼ連続的に行われるほど高速になりました。2 つのモデム間のデータは、テレビットの半二重接続で実行されるMNPに基づく独自のプロトコルを使用してエラー訂正されました。これは、通常の g プロトコルよりもはるかに優れています^[11]。これは、一般的な 64x3 の場合、リモート システムがACK低速の返信チャネルをオーバーフローさせる s の一定のストリームを送信するためです。モデムの本来の高いデータ レートと相まって、全体的なスループットが大幅に改善され、一般に 2400 ビット/秒のモデムの約 7 倍の速度で実行されました^[12] 。長距離料金の削減ですぐに元が取れるため、UUCP ホストで広く使用されました。

UUCP 実装には、特定のリンクで使用するための他の転送プロトコルも含まれています。

f プロトコルは、7 ビットのエラー訂正リンクで動作するように設計されている。これはもともと、 1980 年代に一時期人気があったX.25リンクで使用することを意図していた。データをパケット化せず、ファイル全体を 1 つの長い文字列として送信し、その後にファイル全体のチェックサムを付加する。類似のx プロトコルはほとんど使われなかったか、まったく使われなかったようだ。dプロトコルはx に似ているが、ベル研究所の多くのオフィスを接続するDatakitネットワークで使用することを意図していた。^[11]

t プロトコルは、 BSD バージョンの UUCP から派生したもので、類似のものと同様に、8 ビット エラーのないTCP/IPリンク上で動作するように設計されています。エラー訂正機能はまったくなく、プロトコルは、コマンドとファイル データを 512 バイトまたは 1024 バイトのパケットに分割して、一般的な TCP フレームに簡単に収まるようにするだけです。

e プロトコル("e" は Ethernet の略) はMASSCOMPの Clem Cole によって開発され、その後の HoneyDanBer バージョンで Brian Redman によって広くリリースされました。t プロトコルより前に開発されリリースされましたが、BSD バージョンの UUCP が主流の実装であったため、t プロトコルの方が一般的に使用されました。e プロトコルが t プロトコルと異なるのは、コマンドがパケット化されず、通常の文字列として送信される点と、ファイルが 20 バイト単位でパディングされる点だけです。^{[11] [13]}

uucpおよび の機能uuxqtを使用して、適切なメールユーザーインターフェイスと配信エージェントプログラムを備えたマシン間で電子メールを送信できます。単純な UUCP メール アドレスは、隣接するマシンの名前、感嘆符(多くの場合、バンと発音されます)、および隣接するマシンのユーザー名から構成されます。たとえば、アドレス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 メッセージ形式のパスヘッダー行内で現在も使用されています。これらは現在、情報提供のみを目的としており、ルーティングには使用されていませんが、ループが発生しないようにするために使用できます。

一般的に、他の古い電子メール アドレス形式と同様に、現在では、バン パスは、UUCP をまだ使用しているサイトでも、 「 @ 表記」に置き換えられています。UUCP のみのサイトでは、DNS ドメイン名を登録し、そのドメインを処理する DNS サーバーにMX レコードを提供させることができます。これにより、そのサイトへのインターネット メールがインターネット上の UUCP ホストに配信され、そのホストから UUCP サイトにメールが配信されます。

UUCPNET は、 UUCP を介して接続されたコンピュータ ネットワーク全体を指す名前でした。このネットワークは非常に非公式で、何千もの民間企業、大学などが所有するシステム間の相互協力の精神で維持されていました。特に民間部門では、UUCP リンクは企業の上層部の正式な承認なしに確立されることがよくありました。UUCP ネットワークは、新しいシステムやダイヤルアップ リンクが追加されたり、他のリンクが削除されたりして、常に変化していました。

UUCPマッピング プロジェクトは、オープン メール リレーであるマシン間の接続マップを作成し、管理された名前空間を確立するという、ボランティアによる、おおむね成功した取り組みでした。各システム管理者は、自分のマシンが接続するシステムのリストと、各接続の順位を電子メールで送信しました。送信されたマップ エントリは、ネットワーク内のすべての接続を記述する 1 セットのファイルにまとめられる自動プログラムによって処理されました。これらのファイルは、この目的専用のニュース グループで毎月公開されました。UUCP マップ ファイルは、"pathalias" などのソフトウェアで使用して、あるマシンから別のマシンへのメールの最適なルート パスを計算し、このルートを自動的に提供できます。UUCP マップにはサイトの連絡先情報も記載されているため、UUCPNET に参加しようとしているサイトは、近隣の候補を簡単に見つけることができます。

多くの UUCP ホスト、特に大学のホストも、初期のインターネットに接続されており、インターネットのSMTPベースのメールと UUCP メール間の電子メール ゲートウェイが開発されました。UUCP 接続のあるシステムのユーザーは、インターネット ユーザーとメールを交換でき、インターネット リンクを使用して、低速の UUCP ネットワークの大部分をバイパスできました。これらのインターフェイスを容易にするために、インターネット ドメイン名前空間内に「UUCP ゾーン」が定義されました。

このインフラストラクチャが整備されたことで、UUCP の強みは、ダイヤルアップ モデム リンクを別の連携コンピュータに接続するだけで、サイトがインターネット電子メールや Usenet に接続できるようになったことです。当時は、真のインターネット アクセスには、インターネットポイント オブ プレゼンスへの接続を提供する専用データ回線が必要でしたが、どちらも高価で手配が困難でした。対照的に、UUCP ネットワークへのリンクは、通常、近隣のシステムの管理者に数回電話をかけるだけで確立できました。近隣のシステムは、電話の最も基本的な料金を除いて、ほとんどかからないほど近い場所にある場合が多かったのです。

uux は、UUCP を介したリモート コマンド実行です。uux コマンドは、リモート システムでコマンドを実行したり、リモート システムのファイルを使用してローカル システムでコマンドを実行したりするために使用されます。このコマンドはデーモンによって実行され、デーモンは、次のホップ ノードが使用可能になるたびに、リモート実行要求を別の種類のファイルとして扱い、リモート システムに一括送信します。リモート システムは、元のシステムが使用可能になると、要求されたコマンドを実行し、結果を返します。これらの転送は両方とも、マルチホップ パスを介して間接的に実行され、使用可能なウィンドウは任意です。常に使用可能なネイバーでコマンドを実行する場合でも、uux は即時ではありません。 uucico

UUCP の使用は、安価なSLIPおよびPPPサービスを提供するインターネット サービス プロバイダーの台頭とともに衰退し始めました。UUCP マッピング プロジェクトは、2000 年後半に正式に終了しました。

UUCP プロトコルは現在、メール用のSMTPや Usenet ニュース用のNNTPといったインターネット TCP/IP ベースのプロトコルにほとんど置き換えられています。

2012年7月、オランダのインターネットプロバイダーXS4ALLは、 UUCPサービスを閉鎖し、「おそらく世界でまだUUCPを提供している最後のプロバイダーの1つ」であると主張した。当時のユーザーはわずか13人だった（閉鎖前の数年間、新規ユーザーからのリクエストを拒否していた）。^[15]

UUCP の残存する機能の 1 つはチャット ファイル形式であり、これは主にExpectソフトウェア パッケージに継承されています。

UUCPは、他の場所で姿を消した後も、特殊用途の高コストリンク（海洋衛星リンクなど）で使用されており、^[16]現在でもレガシー用途として残っています。^[要出典]レガシー用途に加えて、2021年には、特にHF帯域での通信、たとえばアマゾンの熱帯雨林のコミュニティでの電子メール交換などの用途で、新しい革新的なUUCPの用途が増えています。IanのUUCPへのパッチは、UUCP HF接続を提供するHERMES（高周波緊急および農村マルチメディア交換システム）プロジェクトに適応するために、 UUCP Debian Linuxパッケージ^{[17]に寄贈されました。 [18]}

2000年代半ばには、コンピュータに固定IPアドレスがないが、SendmailやPostfixなどの標準のメール転送エージェント（ MTA ）を実行したい場合に使用するために、TCP/IP上のUUCP（多くの場合、 SSHプロトコル^[10 ]を使用して暗号化される^）が提案されました^{[誰によると}？ ]

バンのようなパスは、ルーティング用ではないものの、Usenetネットワーク内では今でも使用されています。メッセージのヘッダーに、メッセージが次にどこに行くかを示すのではなく、メッセージが通過したノードを記録するために使用されます。 ^{[19] 「バンパス」は、ネットワーク ホスト間で明示的に指定された}ルーティングパスを表す表現としても使用されます。この使用法は、必ずしも UUCP、IP ルーティング、電子メール メッセージング、または Usenet に限定されるわけではありません。

遅延耐性ネットワークプロトコルの概念は、2000年代初頭に再検討されました。^[20] UUCPで使用されるものと同様の技術は、遅延や重大な中断が発生する他のネットワークにも適用できます。

• ルーティング
• サイト名
• メッシュネットワーク
• バークネット
• ビットネット
• フィドネット
• 電子メールの歴史
• インターネットの歴史

• UUCP の使用と管理。Ed Ravin、Tim O'Reilly、Dale Doughtery、Grace Todino。1996 年、O'Reilly & Associates、Inc. ISBN 1-56592-153-4 
• Mark Horton (1986)。RFC 976: UUCP メール交換フォーマット標準。インターネット エンジニアリング タスク フォースのコメント要求。
• Taylor UUCP ドキュメント – UUCP 全般およびさまざまな UUCP プロトコルに関する有用な情報。
• UUCP プロジェクト: Wayback Machineの歴史(2014 年 1 月 6 日アーカイブ)