종단 간 원칙을 공식화 할 수 있습니까?


10

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 논문) 아이디어를 모방하기 위해 경주. 따라서 네트워크에서 교착 상태 방지는 응용 프로그램 수준 교착 상태 방지와 같은 "문제의 기능"이 아니거나 종단 간 원칙이 잘못되었습니다.

엔드-투-엔드 원리를 "시"에서 정리로 바꿀 수 있습니까? 아니면 적어도 컴퓨터 설계자가 이해할 수있는 용어로 설명 할 수 있습니까?


이것은 통신 환경에서 인터페이스를 과도하게 설계하거나 과도하게 설계하는 것과 같은 소리가납니다. 종종 CS 인터페이스 / API에서 거의 사용되지 않는 함수로 작성되거나 예상 구조가 실제 사용 / 요구 사항과 일치하지 않습니다. 훈계는 "가능하면 그것을 알고 피하는 것"으로 보인다.
vzn

당신의 모범에 관해; 언급 한 내용은 버퍼가 채워 졌을 때 인터커넥트가 프로세서를 인터럽트하고 소프트웨어 버퍼링으로 OS 기능을 보강함으로써 "작동"한 것입니다. CPU 간의 상호 연결이 다른 프로세서가 일반 프로세서 메모리의 데이터를 버퍼링 할 수있을 정도로 "자동"입니까? 그것은 나에게 믿기 어려워 보인다.
Alexandros

상호 연결이 매우 바쁩니다. 교착 상태를 방지하기 위해 하드웨어 버퍼가 부족한 경우에만 소프트웨어 인터럽트 및 버퍼링이 발생합니다. 소프트웨어 버퍼는 하드웨어 버퍼보다 ​​수십 배 더 클 수 있으므로 작은 하드웨어 버퍼가 가득 차서 종속성 루프가 끊어 질 수 있습니다. 이것은 거의 발생하지 않았으며 (주로 캐시 일관성 트래픽과 경쟁하는 DMA 트래픽이 많을 때만), 대부분의 프로그램에서 하드웨어가 아닌 소프트웨어에서 처리 된 메시지의 일부를 무시할 수있었습니다.
방황 논리

답변:


3

엔드 투 엔드 (e2e) 원칙을 적용 할 때 다음과 같은 두 가지 단점이있을 수 있습니다.

첫째, 성능에 적용한다는 의미입니다. 엔드-투-엔드 (end-to-end)는 아키텍처 직교성, 구성 성, 규칙 성, 하나 또는 모두를 보장하고 프리미티브 등을 제공하는 것과 같은 디자인 원칙입니다. 이러한 원칙은 관련 교과서에 요약되어 있습니다. 성능은 그중 하나가 아닙니다. 실제로 Clark et al은 엄격한 종단 간 성능이 저하되어이 원칙에 대한 예외와 같이 성능이 저하 될 수 있음을 암시합니다.

따라서 공식화하려는 경우 :

"엔드-투-엔드 인수는 애플리케이션 요구 사항에 호소하며 계층화 된 시스템에서 기능을 위로 이동시키는 근거를 제공합니다."공식화 된 애플리케이션 요구 사항 및 공식화 된 계층화 된 시스템이 필요합니다. 한 단계 더 나아가는 데 도움이 될 수있는 시도는 다음과 같습니다.

Layer (i) 요구 사항이 있다고 가정하십시오 (Layer (0)은 현재 또는 미래에 응용 프로그램 계층을 지원할 것으로 예상되는 일련의 응용 프로그램에 대한 것입니다) 및 견고한 인터페이스 Interface (i, i + 1) 및 Interface (i + 1) , i) (레이어 i에서 i + 1까지 사전 계층화가 없다고 가정하고 변경하고 요구 사항을 쉽게 만들 수 있음) 및 함수 Function (i, j) (Layer i, Function index j, 함수의 데이터 부분으로 가정) 더 간단하게)

입력 : Layer (0) 요구 사항 (이 형식화가 필요하다고 말했듯이)

출력 : 그 밖의 모든 것

END-TO-END 출력은 다음과 같은 출력입니다. 각 L에 대해 Layer (L)는 Function (L, j) 함수 (예 : 계층 내의 함수) 및 Interface (L, L + 1) 인터페이스에 의해서만 요구 사항을 충족합니다. (L + 1, L)

각 레이어 L 및 함수 Function (L, F)에 대해, 함수 (L, F) = S (= 등가 출력 및 부작용을 의미)와 같이 출력에 함수 S 세트가 없습니다.

따라서 특정 e2e 원리 응용 프로그램의 두 번째 가능한 단점은 (그리고 시도중인 내용을 올바르게 읽고 있다면) e2e 원리를 전혀 따르지 않는다고 주장 할 수 있습니다. 칩이 "일부 교착 상태 방지"를 제공하고 일반적이지 않은 비정상적이고 상위 계층에서 더 많은 도움을 트리거 (인터럽트)하기위한 인터페이스가 있습니다. 이것은 엔드-투-엔드 방식이 아닌 크로스 레이어 방식입니다. 다시 말해, Set 인터페이스를 사용하여 기능을 완벽하고 정확하게 수행하지 못하는 Function (1, x)을 가지고 있습니다-위에 제공된 드래프트 공식화를 사용하려면 그러나 그 자체로는 충분하지 않을 수 있습니다).

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.