본문 바로가기
리눅스

UUCP

by 다움위키 2023. 12. 23.

UUCP는 Unix-to-Unix Copy의 약어입니다. 그 용어는 일반적으로 명령을 원격으로 실행하고 컴퓨터 사이에 파일, 이메일, 및 넷뉴스를 전송하는 것을 허용하는 컴퓨터 프로그램과 프로토콜의 모음을 참조합니다.

uucp라고 이름-지어진 명령은 모음에서 프로그램 중 하나입니다; 그것은 파일 복사 작업을 요청하기 위한 사용자 인터페이스를 제공합니다. UUCP 모음은 역시 uux (원격 명령 실행을 위한 사용자 인터페이스), uucico (파일 전송을 수행하는 통신 프로그램), uustat (최근 활동에 대한 통계 보고), uuxqt (원격 컴퓨터에서 보낸 명령 실행), 및 uuname (로컬 시스템의 UUCP 이름을 보고)를 포함합니다. 모음의 일부 버전은 uuencode/uudecode (8비트 바이너리 파일을 7비트 텍스트 형식으로 또는 그 반대로 변환)을 포함합니다.

비록 UUCP가 원래 1970년대와 1980년대에 유닉스에서 개발되었고, 유닉스-계열 시스템과 가장 밀접하게 연관되어 있지만, UUCP 구현은 DOS, OS/2, OpenVMS (VAX 하드웨어-전용), AmigaOS, classic Mac OS, 심지어 CP/M를 포함하여 여러 비-유닉스-계열 운영 시스템에 존재합니다.

History

UUCP는 원래 Mike Lesk에 의해 AT&T Bell Laboratories에서 작성되었습니다. 1978년까지 그것은 주로 소프트웨어 배포를 위해 Bell 시스템 내부의 82개의 유닉스 시스템에서 사용되었습니다. 그것은 1979년 버전 7 유닉스의 일부로 출시되었습니다. 원래 UUCP는 1983년경 AT&T 연구원 Peter Honeyman, David A. Nowitz 및 Brian E. Redman에 의해 다시 작성되었습니다. 다시 작성은 HDB 또는 HoneyDanBer uucp로 참조되며, 나중에 개선되고, 버그가 수정되었고, BNU UUCP ("기본 네트워크 유틸리티")로 다시 패키징되었습니다.

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

UUCP는 비-유닉스 운영 시스템, 특히 DOS 시스템에서도 구현되었습니다. (John Gilmore, Garry Paxinos, Tim Pozar), UUPC/extended (Drew Derbyshire of Kendra Electronic Wonderworks) 및 FSUUCP (Christopher Ambler of IODesign)와 같은 패키지는 개인용 컴퓨터에 초기 인터넷 연결을 가져왔고, 서로 연결된 대학교 시스템을 넘어 네트워크를 확장했습니다. FSUUCP는 Galacticomm의 Major BBS 및 Mustang Software의 Wildcat! BBS과 같은 많은 게시판 시스템 (BBS) 패키지에 대해 UUCP 네트워크에 연결하고 이메일과 유즈넷 트래픽을 교환하기 위한 기반을 형성했습니다. 예제로써, UFGATE (John Galvin, Garry Paxinos, Tim Pozar)는 Fidonet과 UUCP 프로토콜을 실행하는 네트워크 사이에 게이트웨이를 제공하는 패키지였습니다.

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

Technology

인터넷 접근의 광범위한 보급 전에, 컴퓨터는 오직 회사 또는 조직 내의 소규모 근거리 통신망에 의해 연결되었습니다. 그것들은 역시 종종 모뎀을 갖추고 있었으므로 전화 접속 전화선을 통해 문자-모드 터미널에서 원격으로 사용될 수 있었습니다. UUCP는 컴퓨터의 모뎀을 다른 컴퓨터에 전화를 걸기 위해 사용했으며, 그들 사이에 임시 점-대-점 링크를 설립했습니다. UUCP 네트워크에서 각 시스템은 전화번호, 로그인 이름 및 암호, 등이 포함된 이웃 시스템의 목록을 가집니다. 작업 (파일 전송 또는 명령 실행 요청)이 이웃 시스템에 대해 대기열에 있을 때, uucico 프로그램은 전형적으로 해당 시스템에서 작업을 처리하기 위해 호출됩니다. uucico 프로그램은 역시 주기적으로 이웃을 그들의 옆에 대기 중인 작업을 확인하기 위해 등록할 수 있습니다; 이것은 전화-걸기 능력 없는 이웃도 참여하는 것을 허용합니다.

시간이 지남에 따라, 전화-접속 링크는 인터넷 연결로 대체되었고, UUCP는 여러 가지 새로운 링크 계층 프로토콜을 추가했습니다. 이들 새로운 연결은 역시 새로운 네트워크의 이점을 취하기 위해 개발된 새로운 애플리케이션 프로토콜로 인해 UUCP에 대해 요구를 전혀 감소시켰습니다. 오늘날, UUCP는 전화-접속 링크를 통해 거의 사용되지 않지만, 때때로 TCP/IP를 통해 사용됩니다. 2006년 초부터, 관련된 시스템의 수는 60개 기업의 1500에서 2000개 사이트 사이에서 실행되었습니다. UUCP의 수명은 저렴한 비용, 광범위한 로깅, 전화-접속에 대한 네이티브 장애-조치, 및 지속적인 대기열 관리에 기인할 수 있습니다.

Sessions

UUCP는 통상적으로 대상 시스템에 로그인한 사용자를 가지고 그런-다음 UUCP 프로그램을 실행함으로써 시작됩니다. 대부분의 경우에서, 이것은 계정의 쉘이 uucico로 설정된, 전송에 대해 사용된 알려진 사용자 계정에 로그인함으로써 자동화됩니다. 따라서, 자동화된 전송에 대해, 또 다른 기계가 단순히 호출된 기계에 모뎀 연결을 열고 알려진 계정에 로그인해야 됩니다.

uucico가 실행될 때, 호출자의 기계에 있는 또 다른 UUCP 프로그램에서 명령을 수신하고 세션을 시작할 것으로 예상할 것입니다. 세션은 세 가지 구별되는 단계를 가집니다:

  1. 초기 악수
  2. 파일 전송
  3. 마지막 악수

Initial handshake

시작 시, uucico는 식별 문자열 \20Shere=hostname\0을 보냄으로써 응답할 것이며, 여기서 \20은 control-P 문자이고, \0은 후행하는 널입니다. 호출자의 UUCP는 \20Scallername options\0으로 응답하며, 여기서 options은 0개 이상의 유닉스-계열 옵션 스위치를 포함하는 문자열입니다. 이것들은 패킷 및 창 크기, 지원되는 최대 파일 크기, 디버깅 옵션, 등을 포함할 수 있습니다.

두 시스템의 설정에 따라, 통화가 여기서 종료될 수 있습니다. 예를 들어, 호출자가 자신의 시스템 이름으로 응답할 때, 만약 그것이 호출자를 인식하지 못하면, 호출된 시스템이 선택적으로 전화를 끊고, RYou are unknown to me\0 응답 문자열을 보내고 그런-다음 연결을 끊을 수 있습니다.

File requests

만약 두 시스템이 성공적으로 악수하면, 호출자는 이제 일련의 파일 요청을 보내기 시작할 것입니다. 네 가지 유형이 있습니다:

S는 파일을 호출자에서 호출된 시스템으로 전송 (업로드)되도록 하는 원인이 됩니다. 에게 및 로 이름이 제공되며, 파일이름을 수신자에서 변경되도록 허용합니다. S 명령이 호출된 시스템에서 수신될 때, 만약 그것이 성공하고 파일을 수락할 준비가 되었으면 SY로 응답하거나, 만약 실패하면 SNx로 응답하며, 여기서 x는 실패 이유입니다. 만약 SY가 호출자에 의해 전송되면, 초기 악수 동안 선택된 프로토콜을 사용하여 파일 업로드를 시작합니다 (아래 참조). 전송이 완료될 때, 호출된 시스템은 만약 파일을 성공적으로 수신하면 CY로 응답하거나, 실패하면 CN5로 응답합니다. R은 호출자에게 파일을 전송 (다운로드)하기 위해 호출된 시스템에 대한 요청입니다. 그렇지 않으면 S와 유사하며, RY 및 RN을 명령이 수락되었고 데이터 전송을 시작하거나 문제가 있음을 나타내기 위해 사용하고, 전송의 끝에서 호출자로부터 CY 및 CN5를 기대합니다. X는 호출된 시스템에서 실행될 명령을 업로드합니다. 이것은 해당 시스템에게 또 다른 시스템을 호출하도록 만들고 파일을 전달하기 위해 사용될 수 있습니다. 호출된 시스템은 성공하면 XY로, 실패하면 XN으로 응답합니다. H는, 전화-끊기에 대해, 호출자가 완료되었음을 나타냅니다. 호출된 시스템은 성공하면 HY로 응답하고 실패하면 HN으로 응답합니다.

Final handshake

H 명령을 보낸 후, 호출한 시스템은 최종 패킷 \20OOOOOO\0 (control-P, six ohs, null-terminator)을 보내고 호출된 시스템은 \20OOOOOO\0 (control-P, seven ohs, null-terminator)로 응답합니다. 일부 시스템은 H 명령의 성공적인 수신을 단순히 끊고 최종 악수를 방해하지 않을 것입니다.

g-protocol

UUCP에서 프로토콜의 모음 내에서, 놓여있는 g-프로토콜은 오류-없는 형식으로 정보를 전송하는 책임을 가집니다. 그 프로토콜은 패킷 전달을 위한 일반적인-목적 시스템으로 시작되었고, 따라서 UUCP 패키지 전체에서 사용되지 않는 여러 기능을 제공합니다. 이것들은 파일 전송과 함께 산재된 명령 데이터를 보낼 수 있는 보조 채널과 전송 중 패킷 및 창 크기를 재협상하는 능력을 포함합니다. 이것들 여분의 기능은 UUCP 스택의 일부 구현에서 사용하지 못할 수 있습니다.

패킷 형식은 6-바이트 헤더와 유효-탑재량에서 0에서 4096바이트 사이로 구성됩니다. 패킷은 단일 \020 (control-P)으로 시작합니다. 그 다음에는 "K"라고 하는 단일 바이트가 오며, 32에서 4096바이트 사이의 패킷 크기를 나타내는 1에서 8까지의 값, 또는 제어 패킷을 나타내는 9를 포함합니다. 많은 시스템은 오직 64바이트를 의미하는 K=2를 지원했습니다. 다음 2바이트는 헤더를 포함하지 않은 유효-탑재량의 16-비트 체크섬이었습니다. 다음 바이트는 데이터 유형이고 마침내, 마지막 바이트는 헤더의 XOR로, 유효-탑재량과 별도로 확인되는 것을 허용합니다.

제어 바이트는 TTXXXYYY 형식에서 세 비트-필드로 구성됩니다. 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인 세 번째 패킷을 보냄으로써 시작됩니다.

g-protocol은 엔드포인트 사이의 잠재적으로 긴 대기 시간을 처리하기 위해 간단한 슬라이딩 윈도우 시스템을 사용합니다. 그 프로토콜은 패킷 크기를 64에서 4096 8-비트 바이트와 1에서 7 패킷을 포함하는 창을 허용합니다. 이론적으로, 4k 패킷과 7개의 패킷 창 (4096x7)을 사용하는 시스템은 ZMODEM과 같은 최고의 파일-전송 프로토콜과 일치하거나 능가하는 성능을 제공합니다. 실제로, 많은 구현은 오직 64x3의 단일 설정을 지원했습니다. 결과로써, g-protocol은 초라한 성능에 대해 값어치 없는 평판을 가졌습니다. 패킷과 창 크기에 대한 혼란은 항상 4096x3을 사용했다는 점에서만 다른 G-프로토콜로 이어졌습니다. Taylor UUCP는 G를 지원하지 않았지만, 유효한 임의의 요청 창이나 패킷 크기를 지원했으며, 따라서 G를 시작하는 원격 시스템은 Taylor의 g와 잘 작동했지만, 두 Taylor 시스템은 더 빠른 연결을 협상할 수 있습니다.

텔레비트 모뎀은 프로토콜 스푸핑을 패킷-의-끝 표시기가 원격 시스템으로 전송되고 있음을 알아차리고 원격 시스템이 이미 패킷을 수신하고 올바르게 디코딩한 것처럼 가장하고 로컬 호스트에 즉시 ACK를 다시 전송함으로써 g-프로토콜 전송의 성능을 향상시키기 위해 사용했습니다. 이것은 소프트웨어 스택에게 다음 패킷을 보내도록 촉발하므로, 급속히 전송이 거의 연속적이게 되게 했습니다. 두 모뎀 사이의 데이터는 텔레비트의 두 모뎀 사이의 데이터는 텔레비트의 반-이중 연결을 통해 실행되는 MNP 기반 독점 프로토콜을 사용하여 오류가 수정되었으며, 이것은 g-프로토콜이 통상적으로 사용하는 것보다 훨씬 뛰어났는데, 왜냐하면 공통적인 64x3의 경우에서 원격 시스템이 저속 반환 채널을 오버플로하는 일정한 ACK 스트림을 보내기 때문입니다. 모뎀의 자연스러운 더 높은 데이터 속도와 결합하여, 그것들은 전체 처리량을 크게 향상시켰고 일반적으로 2400 bps 모뎀 속도의 약 7배를 수행했습니다. 그것들은 저렴한 장거리 요금으로 신속하게 비용을 지불할 수 있기 때문에 UUCP 호스트에서 널리 사용되었습니다.

Other protocols

UUCP 구현은 특정 링크를 통해 사용하기 위한 다른 전송 프로토콜도 포함합니다.

f-protocol은 7비트 오류-수정 링크에서 실행되도록 설계되었습니다. 이것은 원래 1980년대에 한동안 유행했었던 X.25 링크에 사용하기 위해 의도된 것이었습니다. 그것은 데이터를 패킷화하지 않고, 대신, 전체 파일이 전체 파일 체크섬이 뒤따르는 하나의 긴 문자열로 전송됩니다. 유사한 x-protocol은 거의 또는 전혀 사용되지 않은 것으로 보입니다. d-protocol은 x와 유사했지만, 벨 연구소의 많은 사무실을 연결된 데이터킷 네트워크에서 사용하기 위해 의도된 것이었습니다.

t-protocol은 BSD 버전의 UUCP에서 기원되었고 8-비트 오류-없는 TCP/IP 링크를 통해 실행되도록 설계되었습니다. 그것은 오류 수정을 전혀 가지지 않았고, 그 프로토콜은 명령과 파일 데이터를 전형적인 TCP 프레임 내에 쉽게 맞도록 512 또는 1024-바이트 패킷으로 나누는 것으로 구성됩니다. BSD의 t와 대조적으로 HoneyDanBer 버전을 기원으로 하는 덜-사용된 e-protocol은 명령이 패킷화되지 않고 대신 정규 문자열로 전송되지만, 파일은 가장 가까운 20바이트로 채워진다는 점에서만 다릅니다.

Mail routing

uucp와 uuxqt 능력은 적절한 메일 사용자 인터페이스와 배달 에이전트 프로그램과 함께 시스템 사이에 이메일을 보내기 위해 사용될 수 있습니다. 간단한 UUCP 메일 주소는 인접 기계 이름, 느낌표 (종종 뱅(bang)으로 발음됨), 뒤따르는 인접 기계의 사용자 이름으로 구성됩니다. 예를 들어, 주소 barbox!user는 인접한 기계 barbox의 사용자 user를 참조합니다.

메일은 나아가서 네트워크를 통해 라우팅되어, 목적지에 도달하기 전에 임의의 숫자의 중간 노드를 통과할 수 있습니다. 초기에는, 이것은 bang으로 구분된 중간 호스트 이름 목록과 함께 완전한 경로를 지정함으로써 수행되어야 했습니다. 예를 들어, 만약 barbox 기계가 지역 기계에 연결되어 있지 않지만, barbox가 지역 기계와 통신하는 foovax 기계에 연결되어 있다고 알려져 있으면, 메일을 보낼 적절한 주소는 foovax!barbox!user입니다.

사용자 barbox!user는 일반적으로 ...!bigsite!foovax!barbox!user와 같은 형식으로 UUCP 이메일 주소를 게시합니다. 이것은 사람들에게 그들의 메일을 기계 bigsite (아마도 모든 사람에게 잘-알려진 및 잘-연결된 기계)로 라우팅하고 그곳에서 기계 foovax를 통해 barbox에 사용자 user 계정으로 라우팅하도록 지시합니다. 전체 경로를 게시하는 것은 발신자가 어디에 있느냐에 따라 다르기 때문에 무의미합니다. (예를 들어, 한 사이트의 Ann은 gway!tcol!canty!uoh!bigsite!foovax!barbox!user 경로를 통해 전송해야 할 수 있지만, 어떤 다른 곳에서, Bill이 pdp10!router22!bigsite!foovax!barbox!user 경로를 통해 전송해야 합니다). 많은 사용자는 잘 알려진 다양한 큰 사이트에서 여러 경로를 제안하여, 메일 발신자로부터 훨씬 더 좋고 아마도 더 빠른 연결 서비스를 제공합니다.

Bang path

이 형식의 이메일 주소는 bang path로 알려져 있습니다. 1981년에는 8개에서 10개의 기계 (또는 hops)의 뱅 경로가 드문 일이 아니었고, 심야 전화-접속 UUCP 링크는 일주일에 걸친 전송 시간의 원인이 될 수 있었습니다. 뱅 경로는 종종 메시지가 종종 손실되기 때문에 전송 시간과 안정성 모두에 의해 선택되었습니다. 일부 호스트는 "더 빠른" 경로를 통해 메일을 전송하여 경로를 가능한 한 "다시 작성"하려고 시도했습니다–이 관행은 눈살을 찌푸리게 하는 경향이 있었습니다.

.uucp로 끝나는 "유사-도메인"은 호스트이름을 UUCP 네트워킹에서 연결될 수 있는 것으로 지정하기 위해 때때로 사용되었지만, 이것은 결코 최상위 도메인으로 도메인 이름 시스템 (DNS)에 정식으로 등록된 적이 없습니다. uucp 커뮤니티는 자체적으로 관리되었고 DNS를 관리하는 관리 방법 및 규정과 잘 맞지 않았습니다; .uucp는 필요한 곳에서 작동합니다; 일부 호스트는 들어오는 SMTP 연결에서 .uucp 주소가 인식되면 SMTP 대기열의 메일을 게이트웨이 시스템의 uucp 대기열로 이동합니다.

유즈넷 트래픽은 원래 뱅 경로를 사용하여 UUCP 프로토콜을 통해 전송되었습니다. 이것들은 여전히 유즈넷 메시지 형식 경로 헤더 행 내에서 사용됩니다. 비록 그것들이 루프가 발생하지 않는 것을 보장하기 위해 사용될 수 있지만, 그것들은 이제 오직 정보 목적을 가지고, 라우팅에 대해 사용되지 않습니다.

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

UUCPNET and mapping

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

UUCP 매핑 프로젝트는 오픈 메일 릴레이였던 시스템 사이의 연결 맵을 구축하고 관리된 이름공간을 설정하려는 자발적인, 크게 성공적인 노력이었습니다. 각 시스템 관리자는 자신이 연결할 시스템 목록과 각각의 그러한 연결에 대한 순위에 따라, 이메일에 의해, 제출합니다. 이들 제출된 맵 항목은 네트워크에서 모든 연결을 설명하는 단일 파일의 집합으로 결합된 자동 프로그램에 의해 처리되었습니다. 이들 파일은 그런-다음 이 목적을 전담하는 뉴스그룹에 매월 게시되었습니다. UUCP 맵 파일은 그런-다음 "경로-별칭"과 같은 소프트웨어에서 메일을 위해 한 기계에서 또 다른 기계로의 최상의 라우트 경로를 계산하고, 이 라우트를 자동으로 제공하기 위해 사용될 수 있었습니다. UUCP 맵은 역시 사이트의 연락처 정보도 나열되어 있었고, 따라서 UUCPNET에 가입하려는 사이트에서 잠재적인 이웃을 찾기 위한 쉬운 방법을 제고했습니다.

Connections with the Internet

많은 UUCP 호스트, 특히 대학교의 호스트는 역시 초기에 인터넷에 연결되었고, 인터넷 SMTP-기반 메일과 UUCP 메일 사이의 이메일 게이트웨이가 개발되었습니다. UUCP 연결을 갖는 시스템에서 사용자는 그것에 따라서 인터넷 사용자와 메일을 교환할 수 있었고, 인터넷 링크는 느린 UUCP 네트워크의 많은 부분을 우회하기 위해 사용될 수 있습니다. "UUCP 영역"이 이들 인터페이스를 용이하게 하기 위해 인터넷 도메인 이름공간 내에 정의되었습니다.

이 하부 구조를 갖는 장소에서, UUCP의 강점은 또 다른 협력 컴퓨터에 대한 전화-접속 모뎀 링크만으로 사이트에서 인터넷 이메일과 유즈넷 연결을 얻을 수 있다는 것입니다. 이것은 진정한 인터넷 접속이 인터넷 접속 지점에 대한 연결을 제공하는 임대 데이터 회선이 필요했던 때였으며, 그것의 둘 다는 비용이 많이 들고 준비하기 어려웠습니다. 대조적으로, UUCP 네트워크에 대한 링크는 보통 예상되는 이웃 시스템의 관리자에게 몇 번의 전화 통화로 설정할 수 있습니다. 이웃 시스템은 종종 전화 통화에 대한 가장 기본적인 요금을 제외한 모든 요금을 피할 수 있을 만큼 충분히 가깝습니다.

Remote commands

uux는 UUCP를 통한 원격 명령 실행입니다. uux 명령은 원격 시스템에서 명령을 실행하거나 원격 시스템으로부터 파일을 사용하여 지역 시스템에서 명령을 실행하기 위해 사용됩니다. 그 명령은 다음-이륙 노드를 사용할 수 있을 때마다 원격 시스템에 일괄-전송하기 위한 또 다른 종류의 파일로 원격 실행 요청을 처리하는 uucico 데몬에 의해 실행됩니다. 원격 시스템은 그런-다음 요청된 명령을 실행하고 원래 시스템을 사용할 수 있을 때 결과를 반환할 것입니다. 이들 전송 둘 다는, 다중-이륙 경로를 통해, 임의의 가용성 창과 함께 간접적일 수 있습니다. 항상 사용 가능한 이웃에서 명령을 실행할 때도, uux는 즉각적이지 않습니다.

Decline

UUCP 사용은 저렴한 SLIP 및 PPP 서비스를 제공하는 인터넷 서비스 제공업체의 부상으로 인해 사라지기 시작했습니다. UUCP 매핑 프로젝트는 2000년 후반에 공식적으로 종료되었습니다.

UUCP 프로토콜은 이제 대부분 메일에 대해 SMTP 및 유즈넷 뉴스에 대해 NNTP 인터넷 TCP/IP 기반된 프로토콜로 대체되었습니다.

2012년 7월에서, 네덜란드 인터넷 제공업체 XS4ALL은, "아마도 여전히 UUCP를 제공하는 세계에서 마지막 제공업체 중 하나일 것"이라고 주장하면서 UUCP 서비스를 폐쇄했습니다; 그 당시에는 13명의 사용자만 있었습니다 (어쨌든 폐쇄되기 전에 몇 년 동안 새로운 사용자의 요청을 거부했습니다).

Current uses and legacy

UUCP의 살아남은 기능 중 하나는 대부분 Expect 소프트웨어 패키지에 의해 크게 상속된 채팅 파일 형식입니다.

UUCP는 다른 곳에서 사라진 후 오랫동안 특수-목적 고비용 링크 (예를 들어, 해양 위성 링크)를 통해 사용되었고, 여전히 레거시 사용에 남아 있습니다. 레거시 사용 외에도, 2021년에 새롭고 혁신적인 UUCP 사용이, 특히 HF 대역에서 통신, 예를 들어 이메일 교환 및 기타 사용을 위한 Amazon 열대 우림 커뮤니티에 대해 증가하고 있습니다. Ian의 UUCP에 대한 패치는 UUCP HF 연결을 제공하는 HERMES (High-Frequency Emergency and Rural Multimedia Exchange System) 프로젝트에 적응하기 위해 UUCP 데비안 리눅스 패키지에 기고되었습니다.

2000년대 중반에, 컴퓨터가 임의의 고정된 IP 주소를 가지지 않지만 여전히 Sendmail 또는 Postfix와 같은 표준 메일 전송 에이전트 (MTA)를 기꺼이 실행할 의향이 있을 때 사용하기 위해 TCP/IP를 통한 UUCP (종종 SSH 프로토콜[7]을 사용하여 암호화됨)가 제안되었습니다.

Bang-같은 경로는 라우팅을 위한 것은 아니지만 유즈넷 네트워크 내에서 여전히 사용 중입니다; 그것들은 다음으로 갈 곳을 지시하기보다는, 메시지 헤더에서, 해당 메시지가 통과한 노드를 기록하기 위해 사용됩니다. "Bang 경로"는 네트워크 호스트 사이에 임의의 명시적으로 지정된 라우팅 경로에 대한 표현으로도 사용됩니다. 해당 사용은 필연적으로 UUCP, IP 라우팅, 이메일 메시징, 또는 유즈넷으로 제한되지 않습니다.

지연-허용 네트워킹 프로토콜의 개념은 2000년대 초반에 재검토되었습니다. UUCP에 의해 사용된 것들과 유사한 기술은 지연이나 심각한 중단을 경험하는 다른 네트워크에 적용할 수 있습니다.

External links

관련글

티스토리툴바