1990 년대 후반 제가 대학원에있을 때
JH 솔저; DP 리드; DD Clark : 시스템 디자인의 엔드-투-엔드 인수 . ACM 거래 계산. 시스. 2 (4) : 277-288, 1984. DOI = 10.1145 / 357401.357402
모든 대학의 모든 운영 체제 수업에서 읽기가 거의 필요했지만 여전히 인터넷 디자인의 기본 원칙 중 하나 인 것 같습니다. (예를 들어 : J Kempf, R Austein (eds), IAB, " 중간과 끝의 미래 : 인터넷 아키텍처의 진화에 대한 고찰 ", RFC 3724, 2004 년 3 월. )
엔드-투-엔드 원칙 상태 (Saltzer et al., 1984) :
[만약] 해당 기능이 통신 시스템의 종점에 서있는 응용 프로그램의 지식과 도움으로 만 완벽하고 정확하게 구현 될 수 있다면, ... 가능한. [그러나] 때때로 통신 시스템에 의해 제공되는 기능의 불완전한 버전이 성능 향상으로서 유용 할 수있다.
또는 더 간략하게 (초록에서) :
엔드-투-엔드 논쟁은 시스템의 낮은 레벨에 배치 된 기능은 그 낮은 레벨에서 제공하는 비용과 비교할 때 중복되거나 가치가 거의 없을 수 있음을 시사합니다.
그러나 나는 내 경험 (인터넷 아키텍처가 아닌 컴퓨터 아키텍처에 있음)에서 엔드 투 엔드 원칙을 적용하는 데 거의 성공하지 못했습니다. 원칙은 "시"(즉, 수학적으로 정의되지 않은 용어가 많은 영어 산문)로 표시되기 때문에 "문제가되는 기능은 "응용 프로그램의 지식과 도움." 그러나 응용 프로그램의 "지식과 도움"은 물론 "문제의 기능"은 무엇입니까?
예 : 인터넷과 달리 온칩 네트워크는 패킷을 삭제할 수 없지만 버퍼링이 상당히 제한되어 있으므로 교착 상태를 피하거나 복구 할 수있는 방법이 필요합니다. 반면에 애플리케이션은 교착 상태를 자유롭게 만들어야합니다. 따라서 일반적인 경우 (교착 상태 없음)를 빨리 만들고 앱에서 교착 상태를 피해야한다고 추론 할 수 있습니다. 사실 이것은 우리가 Alewife와 Fugu에서 시도한 것입니다 (Mackenzie, et al., 빠른 보호 메시징을위한 2- 케이스 전달 탐색, 국제 증상 고기능 Comp Arch, (HPCA-4) : 231-242, 또는 존 쿠비 아토 비츠의 논문.) (버퍼가 채워 졌을 때 인터커넥트가 프로세서를 방해하고 소프트웨어 버퍼링으로 OS 기능을 보강함으로써) "작동"했지만 학계 나 산업계의 어느 누구도 보지 못했습니다 HPCA 논문) 아이디어를 모방하기 위해 경주. 따라서 네트워크에서 교착 상태 방지는 응용 프로그램 수준 교착 상태 방지와 같은 "문제의 기능"이 아니거나 종단 간 원칙이 잘못되었습니다.
엔드-투-엔드 원리를 "시"에서 정리로 바꿀 수 있습니까? 아니면 적어도 컴퓨터 설계자가 이해할 수있는 용어로 설명 할 수 있습니까?