Vào cuối những năm 1990, khi tôi học cao học, tờ báo
Máy xay muối JH; Sậy DP; DD Clark: Đối số đầu cuối trong thiết kế hệ thống . ACM Trans. Tính toán. Hệ thống. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402
đọc được khá nhiều yêu cầu trong mọi lớp hệ điều hành ở mỗi trường đại học, và nó dường như vẫn là một trong những nguyên tắc hướng dẫn cơ bản trong thiết kế internet. (Xem ví dụ: J Kempf, R Austein (eds), và IAB, " Sự trỗi dậy của Trung và tương lai của End-to-End: Những phản ánh về sự tiến hóa của kiến trúc Internet ," RFC 3724, tháng 3 năm 2004. )
Các nguyên tắc từ đầu đến cuối (Saltzer et al., 1984):
[Nếu] chức năng được đề cập có thể được thực hiện hoàn toàn và chính xác chỉ với kiến thức và trợ giúp của ứng dụng đứng ở điểm cuối của hệ thống truyền thông, ..., cung cấp chức năng nghi vấn đó như là một tính năng của chính hệ thống truyền thông khả thi. [Mặc dù] đôi khi một phiên bản không đầy đủ của chức năng được cung cấp bởi hệ thống truyền thông có thể hữu ích như một sự nâng cao hiệu suất.
Hoặc ngắn gọn hơn (từ bản tóm tắt):
Đối số đầu cuối cho thấy rằng các hàm được đặt ở mức thấp của hệ thống có thể là dự phòng hoặc ít giá trị khi so sánh với chi phí cung cấp chúng ở mức thấp đó.
Nhưng tôi đã có một chút thành công khi áp dụng nguyên tắc đầu cuối theo kinh nghiệm của riêng tôi (đó là trong kiến trúc máy tính, không phải kiến trúc internet). Vì nguyên tắc này được coi là một "bài thơ" (nghĩa là trong văn xuôi tiếng Anh với một loạt các thuật ngữ không được định nghĩa về mặt toán học), khá dễ để đánh lừa bản thân rằng "chức năng trong câu hỏi chỉ có thể được thực hiện hoàn toàn và chính xác với kiến thức và sự giúp đỡ của ứng dụng. " Nhưng "chức năng trong câu hỏi" là gì, hãy để một mình "kiến thức và trợ giúp" của một ứng dụng?
Ví dụ: Mạng trên chip (không giống như internet) không được phép bỏ các gói, nhưng có bộ đệm khá hạn chế, vì vậy bạn cần có một số cách để tránh hoặc khôi phục từ bế tắc. Mặt khác, ứng dụng cũng cần làm cho nó bế tắc miễn phí, phải không? Vì vậy, tôi có thể lý do rằng tôi nên làm cho trường hợp phổ biến (không có bế tắc) nhanh chóng và tránh việc tránh bế tắc trên ứng dụng. Trên thực tế, đây là những gì chúng tôi đã thử trên Alewife và Fugu (Mackenzie, et al., Khai thác chuyển phát hai trường hợp để nhắn tin được bảo vệ nhanh , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Hoặc luận án của John Kubiatowicz.) Nó "hoạt động" (bằng cách kết nối ngắt bộ xử lý khi bộ đệm được lấp đầy và có hệ điều hành tăng cường với bộ đệm phần mềm) nhưng tôi chưa thấy ai trong học viện hoặc ngành công nghiệp (kể cả bất kỳ ai trong chúng ta là tác giả về điều đó Giấy HPCA) chạy đua xung quanh cố gắng tái tạo ý tưởng. Vì vậy, rõ ràng việc tránh bế tắc trong mạng không giống như "chức năng được đề cập" như việc tránh bế tắc ở cấp ứng dụng hoặc nguyên tắc đầu cuối là sai.
Có thể biến nguyên tắc từ đầu đến cuối từ một "bài thơ" thành một định lý không? Hoặc ít nhất, nó có thể được nói theo thuật ngữ dễ hiểu đối với một kiến trúc sư máy tính không?