UUCP

UUCP
UUCP
원저작자마이크 레스크
개발자AT&T 벨 연구소
초기 릴리즈1979년; 43년 전 (1979년)
운영 체제Unix 및 Unix 유사, DOS, OS/2, OpenVMS, AmigaOS, 클래식 Mac OS, CP/M
유형명령어

UUCP는 Unix-to-Unix [1]Copy의 약자입니다.이 용어는 일반적으로 컴퓨터 간에 원격으로 명령을 실행하고 파일, 이메일 및 넷뉴스를 전송할 수 있는 일련의 컴퓨터 프로그램과 프로토콜을 의미합니다.

라는 이름의 명령어uucp는 스위트 내의 프로그램 중 하나로 파일 복사 작업을 요청하기 위한 사용자 인터페이스를 제공합니다.UUCP 스위트에는 다음과 같은 것도 포함됩니다.uux(리모트 명령 실행을 위한 사용자 인터페이스),uucico(파일 전송을 실행하는 통신 프로그램),uustat(최근 활동에 대한 통계 수집),uuxqt(리모트 머신에서 송신된 명령어).uuname(로컬 시스템의 UUCP 이름을 보고합니다).스위트의 일부 버전에는 /가 포함됩니다.uudecode(8비트 바이너리 파일을 7비트 텍스트 형식으로 변환하거나 그 반대도 마찬가지).

UUCP는 원래 1970년대와 1980년대에 Unix에서 개발되었으며 Unix와 유사한 시스템과 가장 밀접하게 관련되어 있지만, UUCP는 DOS, OS/2, OpenVMS(VAX 하드웨어 전용), AmigaOS,[2] 클래식 OS/CP를 포함한 여러 비 Unix와 유사한 운영 체제에 구현되어 있습니다.

역사

UUCP는 원래 Mike [3]Lesk에 의해 AT&T Bell Laboratories에서 작성되었습니다.1978년까지 Bell 시스템 내의 82개의 UNIX 머신에서 주로 소프트웨어 배포용으로 사용되었습니다.1979년 버전 7 [4]유닉스의 일부로 출시되었습니다.

미국에서 온 첫 번째 UUCP 이메일은 1979년에 영국에 도착했고, 영국, 네덜란드, 덴마크 간의 이메일은 1980년에 시작되어 [5][6]1982년에 EUnet을 통해 정규 서비스가 되었다.

원래의 UUCP는 AT&T 연구원 Peter Honeyman, David A에 의해 다시 쓰여졌다.노비츠, 그리고 브라이언 E.1983년 경의 레드맨.이 개서는 HDB 또는 HoneyDanBer uucp라고 불리며 나중에 확장되어 버그를 수정하고 BNU UUCP('기본 네트워크 유틸리티')[7]로 재패키지 됩니다.

이 버전들은 각각 독점 소프트웨어로서 배포되었고,[8] 1991년에 Ian Lance Taylor가 새로운 무료 소프트웨어 버전을 처음부터 작성하도록 영감을 주었습니다.Taylor UUCP는 GNU General Public License에 따라 출시되었습니다.Taylor UUCP는 원래의 네트워크 웜 중 일부가 예기치 않은 셸 명령을 원격으로 실행할 수 있도록 하는 보안 취약점에 대처했습니다.Taylor UUCP는 또한 UUCP의 모든 이전 버전의 기능을 통합하여 다른 버전과 통신할 수 있으며 다른 버전의 유사한 구성 파일 형식도 사용할 수 있습니다.

UUCP는 UNIX가 아닌 운영 체제, 특히 DOS 시스템에도 구현되었습니다.UUSLAVE/GNUCP(John Gilmore, Garry Paxinos, Tim Pozar), UUPC/확장(Kendra Electronic Wonderworks의 Drew Derbyshire), FSUUCP(IOD의 Christopher Ambler) 등의 패키지가 초기 인터넷 접속에 도입되었습니다.FSUUCP는 Galacticomm의 Major BBS와 Mustang Software의 와일드캣과 같은 많은 게시판 시스템(BBS) 패키지의 기반이 되었습니다! BBS는 UUCP 네트워크에 접속하여 이메일 및 Usenet 트래픽을 교환합니다.예를 들어 UFGATE(John Galvin, Garry Paxinos, Tim Pozar)는 Fidonet과 UUCP 프로토콜을 실행하는 네트워크 간에 게이트웨이를 제공하는 패키지입니다.

FSUUCP는 Taylor의 향상된 'i' 프로토콜의 유일한 다른 구현으로, 대부분의 UUCP [citation needed]구현에서 사용되는 표준 'g' 프로토콜보다 상당히 개선되었습니다.

테크놀로지

인터넷 접속이 널리 보급되기 전에는 컴퓨터는 기업이나 조직 내의 소규모 로컬 에리어 네트워크만으로 접속되어 있었습니다.또한 많은 경우 모뎀이 장착되어 있기 때문에 문자 모드 단말기에서 다이얼 업 전화 회선을 통해 원격으로 사용할 수 있습니다.UUCP는 컴퓨터의 모뎀을 사용하여 다른 컴퓨터에 다이얼 아웃을 실시해, 그 컴퓨터 사이에 일시적인 포인트 투 포인트 링크를 확립했습니다.UUCP 네트워크 내의 각 시스템에는 전화번호, 로그인 이름 및 비밀번호 등의 네이버시스템 목록이 있습니다.작업(파일 전송 또는 명령어 실행 요구)이 네이버시스템용으로 큐잉되면uucico프로그램은 일반적으로 해당 시스템을 호출하여 작업을 처리합니다.그uucico또한 프로그램은 네이버를 정기적으로 폴링하여 큐잉된 작업을 확인할 수 있습니다.이것에 의해, 다이얼 아웃 기능이 없는 네이버는 참가할 수 있습니다.

시간이 흐르면서 다이얼업 링크는 인터넷 연결로 대체되었고, UUCP는 많은 새로운 링크 계층 프로토콜을 추가하였다.새로운 애플리케이션 프로토콜이 새로운 네트워크를 활용하기 위해 개발되었기 때문에 이러한 새로운 연결은 UUCP의 필요성을 전혀 줄였습니다.현재 UUCP는 다이얼업링크에서는 거의 사용되지 않지만 TCP/[9][10]IP 상에서 사용되는 경우가 있습니다.2006년 초 현재 관련된 시스템의 수는 60개 기업에서 1500~2000개의 사이트를 운영하고 있습니다.UUCP의 장수는 저비용, 광범위한 로깅, 다이얼업으로의 네이티브페일오버 및 영속적인 큐 관리에 기인합니다.

세션

일반적으로 UUCP는 사용자가 대상 시스템에 로그인한 후 UUCP 프로그램을 실행하는 것으로 시작됩니다.대부분의 경우 이 작업은 전송에 사용되는 알려진 사용자 계정에 로그인함으로써 자동화됩니다.이 사용자 계정의 셸은 다음과 같이 설정됩니다.uucico따라서 자동 전송의 경우 다른 머신이 호출된 머신에 모뎀 접속을 열고 기존 계정에 로그인하기만 하면 됩니다.

uucico가 실행되면 호출자의 머신에 있는 다른 UUCP 프로그램으로부터 명령을 수신하여 세션을 시작합니다.세션에는 다음 3가지 단계가 있습니다.

  1. 초기 핸드쉐이크
  2. 파일 요구
  3. 마지막 악수

초기 핸드쉐이크

시작 시 uucico는 식별 문자열을 전송하여 응답합니다.\20Shere=hostname\0여기서 \20은 control-P 문자, \0은 말미의 늘입니다.발신자의 UUCP는 다음과 같이 응답합니다.\20Scallername options\0여기서 options는 0 이상의 Unix 라이크옵션스위치를 포함하는 문자열입니다.여기에는 패킷 및 창 크기, 지원되는 최대 파일 크기, 디버깅 옵션 등이 포함됩니다.

2대의 시스템의 설정에 따라서는, 콜이 여기서 종료하는 경우가 있습니다.예를 들어, 발신자가 시스템명으로 응답했을 때, 착신측 시스템은 발신자를 인식하지 않는 경우, 임의로 전화를 끊고,RYou are unknown to me\0응답 문자열을 누른 후 연결을 끊습니다.

파일 요구

2대의 시스템이 정상적으로 핸드쉐이크를 실시하면, 발신자는 일련의 파일 요구의 송신을 개시합니다.다음 4가지 유형이 있습니다.

S 에 의해, 발신측으로부터 착신측 시스템으로 파일이 송신됩니다(업로드).from 및 to 이름이 제공되므로 수신측에서 파일 이름을 변경할 수 있습니다.착신측 시스템에서S 명령어가 수신되면 SY로 응답하고 파일을 받아들일 준비가 되어 있으면SY로 응답합니다.실패했을 경우는 SNx로 응답합니다.x는 장애의 원인입니다.발신자가 SY를 수신하면, 최초의 핸드쉐이크시에 선택한 프로토콜을 사용해 파일의 업로드를 개시합니다(아래를 참조).전송이 완료되면, 착신측 시스템은 파일을 정상적으로 수신했을 경우는 CY, 실패했을 경우는 CN5로 응답합니다.
R은, 착신측 시스템에서 발신자에게 파일을 송신하는 요구(다운로드)입니다.그 외에는 S와 비슷합니다.RY 및 RN을 사용하여 명령어가 받아들여지고 데이터 송신이 시작되거나 문제가 발생하며 전송 종료 시 발신자로부터 CY 및 CN5가 수신될 것으로 예상됩니다.
X 는, 착신측 시스템에서 eXecute 하는 커맨드를 업로드 합니다.이 명령을 사용하여 시스템이 다른 시스템에 호출하여 파일을 전송할 수 있습니다.착신측 시스템은 성공했을 경우는 XY, 실패했을 경우는 XN으로 응답합니다.
H(Hangup)는 발신자가 종료되었음을 나타냅니다.착신측 시스템은 성공했을 경우는 HY, 실패했을 경우는 HN으로 응답합니다.

마지막 악수

H 커맨드를 송신하면, 발신측 시스템은 최종 패킷을 송신합니다.\20OOOOOO\0(control-P, 6ohs, 늘터미네이터) 및 착신측 시스템은 다음과 같이 응답합니다.\20OOOOOO\0(control-P, 7ohs, 늘터미네이터).일부 시스템은 H 명령어가 정상적으로 수신될 때까지 전화를 끊을 뿐 최종 핸드쉐이크에 신경 쓰지 않습니다.

G자형

UUCP의 프로토콜 제품군 내에서 기본 g-protocol은 오류 없는 형태로 정보를 전송하는 역할을 합니다.이 프로토콜은 패킷 전송을 위한 범용 시스템으로 시작되었으며, 따라서 UUCP 패키지에서 전체적으로 사용되지 않는 많은 기능을 제공합니다.여기에는 파일 전송과 함께 명령어데이터를 송신할 수 있는 세컨더리 채널과 전송 중에 패킷과 윈도 크기를 재네고시에이트할 수 있는 기능이 포함됩니다.이러한 추가 기능은, UUCP [11]스택의 일부의 실장에서는 사용할 수 없는 경우가 있습니다.

패킷 포맷은 6바이트의 헤더로 구성되어 페이로드에서는0 ~ 4096바이트로 구성되어 있습니다.패킷은 1개의 \020(control-P)으로 시작합니다.그 다음에 32 ~4096 바이트의 패킷사이즈를 나타내는1 ~ 8 또는 제어 패킷을 나타내는9 의 값을 포함한, 「K」라고 불리는1 바이트가 표시됩니다.많은 시스템에서 K=2(64바이트)만 지원했습니다.다음 2바이트는 헤더를 포함하지 않는 페이로드의 16비트체크섬입니다다음 바이트는 데이터 유형이며 마지막 바이트는 헤더의 XOR이므로 페이로드와 [11]별도로 확인할 수 있습니다.

제어 바이트는 TTXXYY 형식의 3개의 비트필드로 구성됩니다.TT는 패킷타입입니다.제어 패킷(K=9도 유효해야 함), 대체 데이터(UUCP에서는 사용되지 않음), 2는 데이터, 3은 K의 의미를 재인식하는 짧은 패킷을 나타냅니다.데이터 패킷에서 XXX는 0 ~7 의 패킷 번호이며, YYY 는 올바르게 수신된 마지막 패킷 번호입니다.이를 통해 창에 최대 8개의 패킷이 제공됩니다.제어 패킷에서 XXX는 명령어를 나타내며 YYY는 다양한 파라미터에 사용됩니다.예를 들어, 전송은 창 내의 패킷 수가 TT=0(제어), XXX=7 및 YYY인 짧은 제어 패킷을 보낸 다음 패킷 길이로서 XXX=6 및 YYY인 다른 패킷을 보낸 다음 첫 번째 패킷과 동일하지만 XXX=[11]5인 세 번째 패킷을 전송함으로써 시작됩니다.

g-timeout은 엔드포인트 간의 잠재적인 긴 지연을 처리하기 위해 간단한 슬라이딩 윈도우 시스템을 사용합니다.이 프로토콜을 사용하면 패킷의 크기를 64 ~4096의 8비트바이트로 지정할 수 있으며 1~7개의 패킷을 포함하는 윈도우가 허용됩니다.이론적으로 4k 패킷과 7개의 패킷 창(4096x7)을 사용하는 시스템은 ZMODEM과 같은 최고의 파일 전송 프로토콜을 일치시키거나 능가하는 성능을 제공합니다.실제로 많은 구현에서는 64x3의 단일 설정만 지원했습니다.그 결과, g-protocol은 성능 저하로 인해 부당한 평가를 받고 있습니다.패킷과 창 크기에 대한 혼란으로 인해 G 프로토콜이 생성되었으며 항상 4096x3을 사용했다는 점만 다릅니다.Taylor UUCP는 G를 지원하지 않았지만 유효한 요청 창이나 패킷 크기를 지원했기 때문에 G를 시작하는 원격 시스템은 Taylor의 g와 잘 동작하는 반면, 2개의 Taylor 시스템은 훨씬 더 빠른 [11]연결을 협상할 수 있었습니다.

텔레비트 모뎀은 프로토콜 스푸핑을 사용하여 패킷 종료 마커가 리모트시스템으로 전송되는 것을 인식하고 즉시 G 프로토콜 전송 성능을 향상시켰습니다.ACK리모트 시스템이 이미 패킷을 수신해 올바르게 디코딩한 것처럼 가장하여 로컬호스트에 되돌립니다.이것에 의해, 소프트웨어 스택이 다음의 패킷을 송신하는 것이 트리거 되어, 전송이 거의 계속되게 되었습니다.두 모뎀 사이의 데이터는 G-프로토콜보다 훨씬 [11]더 나은 Telebit의 반이중 접속을 통해 실행되는 MNP 기반의 독점 프로토콜을 사용하여 오류 수정되었습니다. 왜냐하면 일반적인 64x3의 경우 리모트 시스템이 지속적으로 스트림을 전송하기 때문입니다.ACKs는 저속 리턴 채널을 오버플로합니다.모뎀의 자연스레 높은 데이터 레이트와 조합하여 전체적인 throughput이 대폭 향상되어 일반적으로 2400 bps [12]모뎀의 약 7배의 속도로 동작합니다.이들은 저렴한 장거리 요금으로 신속하게 비용을 지불할 수 있기 때문에 UUCP 호스트에서 널리 사용되었습니다.

기타 프로토콜

UUCP 구현에는 특정 링크에서 사용하기 위한 다른 전송 프로토콜도 포함됩니다.

f-module은 7비트의 에러 검출 링크로 동작하도록 설계되어 있습니다.이것은 원래 1980년대에 유행했던 X.25 링크에서 사용하기 위한 것입니다.데이터를 패킷화하지 않고 파일 전체가 단일 긴 문자열로 전송된 후 전체 파일 체크섬이 전송됩니다.d-protocol은 x와 비슷하지만 많은 Bell Labs [11]사무실을 연결하는 Datakit 네트워크에서 사용하기 위한 것입니다.

t-protocol은 UUCP의 BSD 버전에서 시작되었으며 오류 없는 8비트 TCP/IP 링크에서 실행되도록 설계되었습니다.이 프로토콜은 일반적인 TCP 프레임에 쉽게 들어갈 수 있도록 명령 및 파일 데이터를 512바이트 또는 1024바이트 패킷으로 분할합니다.BSD에서 t가 아닌 HoneyDanBer 버전을 생성한 사용률이 낮은e-protocol은 명령어가 패킷화되지 않고 일반 문자열로 전송되며 파일은 가장 가까운 20바이트로 [11]패딩됩니다.

메일 라우팅

UUCP 이메일 주소가 포함된 명함

그uucp그리고.uuxqt적절한 메일 사용자 인터페이스와 배달 에이전트 프로그램을 사용하여 머신 간에 이메일을 보내는 기능을 사용할 수 있습니다.단순한 UUCP 메일주소는, 인접한 머신명, 느낌표(종종 bang이라고 발음)와 그 다음에 인접 머신상의 유저명을 사용해 작성되었습니다.예를 들어 Address barbox!user는 인접한 머신바박스의 사용자를 참조합니다.

또한 메일은 수신처에 도착하기 전에 임의의 수의 중간 노드를 통과하여 네트워크를 통해 라우팅될 수 있습니다.처음에는 중간 호스트 이름 목록을 앞머리로 구분하여 완전한 경로를 지정해야 했습니다.예를 들어 머신 바박스가 로컬머신에 연결되어 있지 않지만 바박스가 로컬머신과 통신하는 머신 푸박스에 연결되어 있는 것으로 알려진 경우 메일을 보낼 적절한 주소는 foovax!barbox!user입니다.

사용자 barbox!user는 일반적으로 UUCP 이메일 주소를 …!bigsite!foovax!barbox!user와 같은 형식으로 게시합니다.이것에 의해, 메일은 머신의 빅 사이트(아마도 모든 사람이 액세스 할 수 있는, 잘 알려져 있고 접속이 잘 되어 있는 머신)로 라우팅 됩니다.그리고 거기에서 머신의 foovax를 경유해 Barbox의 유저 어카운트로 라우팅 됩니다.풀 패스를 공개하는 것은 송신자의 위치에 따라 다르기 때문에 의미가 없습니다(예를 들어, 한 사이트의 Ann은 패스 gway!tcol!canty!uoh!bigsite!foovax!barbox!user를 통해 전송해야 하는 반면, 다른 사이트에서는 Bill이 패스 pdp10!router22!routerbox!site!foopax!fox!user!fox!fox!user!fox!user!fox!fox!user!user!fox!fox!fox!user!fox!fox!를 통해 전송해야 합니다많은 사용자들은 메일 발송자로부터 더 좋고 아마도 더 빠른 접속 서비스를 제공하기 위해 다양한 유명한 사이트에서 여러 경로를 제안할 것입니다.

뱅 패스

이 양식의 이메일 주소는 bang path로 알려져 있습니다.1981년에는 8~10대의 기계(또는 홉)의 뱅 패스가 드물지 않았으며, 심야 다이얼 업 UUCP 링크로 인해 일주일간의 전송 시간이 발생할 수 있습니다.Bang 경로는 종종 메시지가 손실되기 때문에 전송 시간과 신뢰성에 의해 선택되었습니다.일부 호스트에서는 패스의 「재작성」까지 해, 「고속」루트를 개입시켜 메일을 송신했습니다.이러한 관행은 무시되는 경향이 있었습니다.

.uucp로 끝나는 "seudo-domain"은 UUCP 네트워킹에 의해 도달할 수 있는 호스트 이름을 지정하기 위해 사용되기도 했습니다.단, 이것은 도메인네임 시스템(DNS)에 최상위 도메인으로 정식으로 등록된 적은 없습니다.uucp 커뮤니티는 스스로 관리되어 DNS를 관리하는 관리방법 및 규정과 잘 일치하지 않습니다.uucp는 필요에[where?] 따라 기능합니다.착신 SMTP [citation needed]접속으로 .uucp 주소가 인식되면 일부[which?] 호스트는 SMTP 큐에서 uucp 큐로 메일을 팬트합니다.

Usenet 트래픽은 원래 뱅 경로를 사용하여 UUCP 프로토콜을 통해 전송되었습니다.이것들은 Usenet 메시지 형식 Path 헤더 행 내에서 여전히 사용되고 있습니다.루프가 발생하지 않도록 하기 위해 사용할 수 있지만, 현재는 정보 목적만을 가지고 있으며 라우팅에는 사용되지 않습니다.

일반적으로 다른 오래된 전자 메일 주소 형식과 마찬가지로 뱅 경로는 "@ 표기법"으로 대체되었습니다. UUCP 전용 사이트는 DNS 도메인 이름을 등록할 수 있으며, 이 도메인을 처리하는 DNS 서버가 인터넷 메일을 호스트 상의 UUCP로 전송하는 원인이 되는 MX 레코드를 제공하도록 할 수 있습니다.그러면 UUCP 사이트로 메일을 배달할 수 있습니다.

UUCPNET 및 매핑

UUCPNET은 UUCP를 통해 연결된 컴퓨터 네트워크의 전체 이름이었다.이 네트워크는 매우 비공식적이며 수천 개의 민간 기업, 대학 등이 소유한 시스템 간의 상호 협력 정신으로 유지되었습니다.많은 경우, 특히 민간 부문에서는, UUCP 링크가 기업의 상층부의 공식 승인 없이 확립되었습니다.UUCP 네트워크는 새로운 시스템과 다이얼 업 링크가 추가되거나 다른 시스템이 제거되는 등 지속적으로 변화하고 있었습니다.

UUCP Mapping Project는 자발적인 작업으로, 메일 릴레이가 열려 있는 머신 간의 접속 맵을 작성하고 관리 네임스페이스를 확립하는 데 크게 성공했습니다.각 시스템 관리자는 접속처의 시스템 목록과 접속처의 순위를 이메일로 송신합니다.이러한 송신된 맵엔트리는 자동 프로그램에 의해 처리되어 네트워크 내의 모든 접속을 나타내는 단일 파일세트로 통합됩니다.그런 다음 이 파일들은 이 목적을 위한 뉴스 그룹에 매달 게시되었습니다.UUCP 맵파일은, 「pathalias」등의 소프트웨어에 의해서 사용되어 메일용으로 머신간에 최적인 루트 패스를 계산해, 이 루트를 자동적으로 제공할 수 있습니다.UUCP 맵에는 사이트 연락처도 기재되어 있어 UUCPNET 가입을 희망하는 사이트에는 이웃을 쉽게 찾을 수 있는 방법이 제공되고 있습니다.

인터넷 접속

많은 UUCP 호스트, 특히 대학의 호스트도 초기에는 인터넷에 연결되어 있었고, 인터넷 SMTP 기반 메일과 UUCP 메일 사이의 이메일 게이트웨이가 개발되었습니다.따라서 UUCP 접속이 있는 시스템의 사용자는 인터넷 사용자와 메일을 교환할 수 있으며 인터넷 링크는 느린 UUCP 네트워크의 대부분을 우회하는 데 사용될 수 있습니다.이러한 인터페이스를 용이하게 하기 위해서, 인터넷 도메인 네임스페이스내에 「UUCP 존」이 정의되어 있습니다.

이 인프라스트럭처를 구축한 UUCP의 강점은 사이트가 인터넷 이메일과 Usenet 접속을 다른 공동 컴퓨터에 다이얼업 모뎀 링크만으로 얻을 수 있다는 것이었습니다.이것은 진정한 인터넷 액세스가 인터넷 Point of Presence에 접속할 수 있는 임대 데이터 회선이 필요했던 시기였는데, 둘 다 비용이 많이 들고 조정하기가 어려웠습니다.이와는 대조적으로 UUCP 네트워크에 대한 링크는 일반적으로 예상되는 네이버시스템 관리자에게 몇 통의 전화를 걸면 확립할 수 있습니다.인근 시스템은 전화 통화의 가장 기본적인 요금을 제외한 모든 요금을 피할 수 있을 정도로 가까운 경우가 많았다.

리모트 명령어

uux는 UUCP를 통한 리모트명령어 실행입니다.uux 명령어는 리모트시스템에서 명령어를 실행하거나 리모트시스템에서 파일을 사용하여 로컬시스템에서 명령어를 실행할 때 사용합니다.이 명령어는 에 의해 실행됩니다.uucico데몬: 넥스트홉 노드를 사용할 수 있을 때마다 리모트시스템에 일괄 송신하는 다른 종류의 파일로 리모트실행 요구를 처리합니다.그런 다음 원격 시스템은 요청된 명령을 실행하고 원래 시스템을 사용할 수 있게 되면 결과를 반환합니다.이러한 전송은 모두 멀티홉 패스를 경유하여 임의의 가용성 창을 사용하여 간접적으로 이루어질 수 있습니다.항상 사용 가능한 네이버에서 명령을 실행하는 경우에도 uux는 즉시 수행되지 않습니다.

사양

저렴한 SLIP와 PPP 서비스를 제공하는 인터넷 서비스 제공업체의 증가로 UUCP의 사용은 사라지기 시작했다.UUCP 매핑 프로젝트는 2000년 말에 공식적으로 중단되었다.

UUCP 프로토콜은 이제 대부분 메일을 위한 인터넷 TCP/IP 기반 프로토콜 SMTP와 유즈넷 뉴스를 위한 NNTP로 대체되었습니다.

2012년 7월, 네덜란드의 인터넷 프로바이더 XS4가ALL은 UUCP 서비스를 종료했습니다.그 당시 UUCP 서비스는 13명의 사용자밖에 없었습니다(그러나 종료 전에는 몇 [13]년 동안 새로운 사용자의 요청을 거부했습니다).

현재의 용도 및 레거시

UUCP의 기능 중 하나는 채팅파일 형식이며, 주로 Expect 소프트웨어 패키지에 의해 상속됩니다.

UUCP는 다른 [14]곳에서 사라진 지 오래 후에 특수 목적의 고비용 링크(예: 해양 위성 링크)를 통해 사용되었으며, 여전히 기존[citation needed] 용도로 사용되고 있다.레거시 사용 외에도 2021년에는 새롭고 혁신적인 UUCP 사용이 증가하고 있으며, 특히 이메일 교환 및 기타 사용을 위한 아마존 열대 우림 지역 커뮤니티를 위한 HF 대역의 통신에 대한 사용이 증가하고 있습니다.UUCP [16]HF 접속을 제공하는 HERMES(High-Frequency Emergency and Rural Multimedia Exchange System) 프로젝트에 적응하기 위해 Ian의 UUCP에 대한 패치가 UUCP Debian Linux[15] 패키지에 제공되었습니다.

2000년대 중반에 UUCP over TCP/IP(종종 SSH[10] 프로토콜을 사용하여 암호화됨)는 컴퓨터가 고정 IP 주소를 가지고 있지 않지만 Sendmail이나 Postfix와 같은 표준 메일 전송 에이전트(MTA)를 실행할 의사가 있을 때 사용하도록 제안되었습니다[according to whom?].

뱅과 같은 패스는 라우팅에는 사용되지 않지만 Usenet 네트워크 내에서 여전히 사용되고 있습니다.이 패스는 메시지가 다음에 [17]어디로 전달되는지를 지시하는 것이 아니라 메시지 헤더에 메시지가 전달된 노드를 기록하기 위해 사용됩니다.「Bang path」는, 네트워크 호스트간에 명시적으로 지정된 라우팅 패스의 표현으로도 사용됩니다.이 사용은 반드시 UUCP, IP 라우팅, 이메일 메시징 또는 Usenet에만 국한되는 것은 아닙니다.

지연 허용 네트워킹 프로토콜의 개념은 2000년대 초에 다시 검토되었습니다.UUCP에서 사용되는 것과 유사한 기술은 지연 또는 대폭적인 [18]중단이 발생하는 다른 네트워크에도 적용될 수 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ UNIX(TM) TIME-SHARING SYSTEM: UNIX PROGRAMMER'S MANUAL, Seventh Edition, Volume 1 (PDF). Murray Hill, New Jersey: Bell Telephone Laboratories, Incorporated. January 1979. Archived (PDF) from the original on 2016-04-29. Retrieved 2018-02-20.
  2. ^ "Aminet - Search".
  3. ^ McIlroy, M. D. (1987). A Research Unix reader: annotated excerpts from the Programmer's Manual, 1971–1986 (PDF) (Technical report). CSTR. Bell Labs. 139. Archived (PDF) from the original on 2017-11-11. Retrieved 2015-02-01.
  4. ^ "Version 7 Unix manual: "UUCP Implementation Description" by D. A. Nowitz, and "A Dial-Up Network of UNIX Systems" by D. A. Nowitz and M. E. Lesk" (PDF). Archived (PDF) from the original on 2018-02-21. Retrieved 2018-02-21.
  5. ^ Houlder, Peter (19 January 2007). "Starting the Commercial Internet in the UK" (PDF). 6th UK Network Operators' Forum. Retrieved 2020-02-12.
  6. ^ Reid, Jim (3 April 2007). "Networking in UK Academia ~25 Years Ago" (PDF). 7th UK Network Operators' Forum. Retrieved 2020-02-12.
  7. ^ Gary J. Murakami (September 24, 1988). "The History of ihnp4 and The Growth of the Email Network". Archived from the original on September 11, 2013. Retrieved June 7, 2013.
  8. ^ Ian Lance Taylor (September 1991). "Beta release of new UUCP package available". Retrieved 2009-01-19.
  9. ^ Ian Lance Taylor (June 2003). "UUCP 'f' Protocol". Archived from the original on 2008-07-18. Retrieved 2008-08-04.
  10. ^ a b Fabien Penso. "UUCPssh". Archived from the original on 2009-09-30. Retrieved 2009-08-09.
  11. ^ a b c d e f g Taylor, Ian Lance (8 March 1996). "UUCP Internals Frequently Asked Questions". Archived from the original on 6 November 2019. Retrieved 29 August 2020.
  12. ^ Kirksey, Kenneth (25 December 1991). "What You Need To Know About Modems". Archived from the original on 24 October 2020. Retrieved 29 August 2020. The actual throughput is around 14400 bps.
  13. ^ Huijbregts, Niels (30 July 2012). "XS4ALL Weblog: Afscheid van UUCP (Goodbye to UUCP)" (in Dutch). XS4ALL. Archived from the original on 31 July 2013.
  14. ^ Randolph Bentson (August 1995). "Linux Goes To Sea". Archived from the original on 2008-02-26. Retrieved 2009-02-21.
  15. ^ Rafael Diniz (January 2021). "UUCP 1.07.27-changelog". Archived from the original on 2020-08-12. Retrieved 2021-01-10.
  16. ^ Rafael Diniz (January 2021). "High-frequency Emergency and Rural Multimedia Exchange System". Retrieved 2021-01-10.
  17. ^ K. Murchison; C. Lindsey; D. Kohn (November 2009). "Path". Netnews Article Format. IETF. p. 14-16. sec. 3.1.5. doi:10.17487/RFC5536. RFC 5536.
  18. ^ Kevin Fall (August 2003). "A Delay-Tolerant Network Architecture for Challenged Internets". Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications - SIGCOMM '03. 2003 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications. ACM SIGCOMM. pp. 27–34. doi:10.1145/863955.863960. ISBN 978-1-58113-735-4.

외부 링크