Czy zasadę kompleksowości można sformalizować?

10

Pod koniec lat 90., kiedy byłem na studiach, gazeta

JH Saltzer; Stroik DP; DD Clark: Kompleksowe argumenty w projektowaniu systemu . ACM Trans. Comput. Syst. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402

było prawie wymagane czytanie w każdej klasie systemów operacyjnych na każdym uniwersytecie i nadal wydaje się być jedną z głównych zasad leżących u podstaw projektowania Internetu. (Patrz na przykład: J Kempf, R Austein (red.) I IAB, „ The Rise of the Middle and the Future of End-to-End: Refleksje na temat ewolucji architektury Internetu ”, RFC 3724, marzec 2004. )

Zasada end-to-end stwierdza (Saltzer i in., 1984):

[Jeżeli] dana funkcja może zostać całkowicie i poprawnie zaimplementowana tylko przy wiedzy i pomocy aplikacji stojącej w końcowych punktach systemu komunikacyjnego ..., pod warunkiem, że ta kwestionowana funkcja jako cecha samego systemu komunikacyjnego nie jest możliwy. [Chociaż] czasami niepełna wersja funkcji zapewnianej przez system komunikacyjny może być przydatna jako ulepszenie wydajności.

Lub w skrócie (z streszczenia):

Argument end-to-end sugeruje, że funkcje umieszczone na niskich poziomach systemu mogą być zbędne lub mieć niewielką wartość w porównaniu z kosztem ich zapewnienia na tym niskim poziomie.

Ale z niewielkim powodzeniem stosowałem zasadę end-to-end we własnym doświadczeniu (która dotyczy architektury komputerowej, a nie architektury internetowej). Ponieważ zasada jest określona jako „wiersz” (tj. W angielskiej prozie zawierającej kilka terminów, które nie są zdefiniowane matematycznie), dość łatwo oszukać się, że „daną funkcję można całkowicie i poprawnie zrealizować tylko za pomocą znajomość i pomoc aplikacji ”. Ale czym jest „omawiana funkcja”, nie mówiąc już o „wiedzy i pomocy” aplikacji?

Przykład: sieci na chipie (w przeciwieństwie do Internetu) nie mogą upuszczać pakietów, ale mają dość ograniczone buforowanie, więc musisz mieć sposób na uniknięcie impasu lub odzyskanie go. Z drugiej strony aplikacja musi również stać w martwym punkcie, prawda? Mogę więc pomyśleć, że powinienem zrobić wspólny przypadek (bez impasu) szybko i odrzucić unikanie impasu w aplikacji. Właśnie tego próbowaliśmy na Alewife i Fugu (Mackenzie i in., Exploiting Two-Case Delivery for Fast Protected Messaging , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Lub rozprawa Jana Kubiatowicza.) „Zadziałało” (ponieważ interkonekt przerwał procesor, gdy bufory zostały zapełnione, a system operacyjny został wzbogacony o buforowanie oprogramowania), ale nie spotkałem nikogo w środowisku akademickim lub przemysłowym (w tym żadnego z nas, którzy byli autorami tego Papier HPCA) ścigający się, próbując powtórzyć ten pomysł. Zatem najwyraźniej unikanie zakleszczenia w sieci nie jest tą samą „omawianą funkcją”, jak unikanie zakleszczenia na poziomie aplikacji, lub zasada end-to-end jest błędna.

Czy można przekształcić zasadę end-to-end z „wiersza” w twierdzenie? A przynajmniej czy można to stwierdzić w sposób zrozumiały dla architekta komputerowego?

Wędrująca logika
źródło
brzmi to jak przeprojektowanie lub nadinżynieria interfejsu w kontekście komunikacji. często w CS interfejsy / interfejsy API tworzone są za pomocą funkcji, które są rzadko używane lub oczekiwana struktura nie jest zgodna z faktycznym wykorzystaniem / wymaganiami. napomnienie wydaje się być „być świadomym i unikać tego, gdzie to możliwe”.
vzn
Jeśli chodzi o twój przykład; wspominasz: „zadziałało” (przez interkonekt przerywający procesor, gdy bufory się zapełniły, i system operacyjny wzbogacony o buforowanie programowe). Czy interkonekt pomiędzy procesorami jest „wystarczająco cichy”, aby umożliwić innym procesorom buforowanie danych w zwykłej pamięci procesora? Wydaje mi się to niewiarygodne.
Alexandros,
Interkonekt jest dość zajęty. Przerwanie oprogramowania i buforowanie następuje tylko wtedy, gdy bufory sprzętowe są niewystarczające, aby zapobiec zakleszczeniu. Bufory programowe mogą być o rząd wielkości większe niż bufory sprzętowe, więc mogą zerwać pętle zależności, które zostały spowodowane przez zapełnianie się małych buforów sprzętowych. To zdarzało się rzadko (głównie tylko wtedy, gdy ruch DMA konkurował z ruchem koherencyjnym), więc w przypadku większości programów część wiadomości obsługiwanych programowo, a nie sprzętowo, była nieistotna.
Wandering Logic

Odpowiedzi:

3

Uważam, że mogą występować dwa niedociągnięcia w stosowaniu zasady end-to-end (e2e):

Po pierwsze, w tym sensie, że zastosujesz go do wydajności. Kompletny jest zasadą projektowania, która zapewnia ortogonalność architektury, kompozycyjność, regularność, jedno lub wszystkie, zapewnia prymitywy itp. Takie zasady zostały opisane w powiązanych podręcznikach. Wydajność nie jest jedną z nich. W rzeczywistości Clark i wsp. Implikują, że ścisłe kompleksowe działanie może skutkować gorszą wydajnością, dlatego wykorzystuje takie, jako wyjątek od tej zasady.

Jeśli więc nadal chcesz sformalizować:

„Argument end-to-end odwołuje się do wymagań aplikacji i stanowi uzasadnienie dla przeniesienia funkcji w górę w systemie warstwowym”, więc będziesz potrzebować sformalizowanych wymagań aplikacji i sformalizowanego systemu warstwowego. Oto próba, która może pomóc pójść o krok dalej:

Załóżmy, że masz wymagania dotyczące warstwy (i) (warstwa (0) dotyczy zestawu aplikacji, które spodziewasz się teraz lub w przyszłości, warstwy aplikacji) oraz stabilnych interfejsów Interfejs (i, i + 1) i Interfejs (i + 1 , i) (od Warstwy i do i + 1 zakładamy tutaj brak nakładania warstw, łatwo je zmienić i sprawiają, że jest to wymóg) i funkcje Funkcja (i, j) (Warstwa i, Indeks funkcji j, zakłada część danych funkcji mieć to prostsze)

Dane wejściowe: wymagania dotyczące warstwy (0) (jak powiedzieliśmy, należy je sformalizować)

Wyjście: wszystko inne

Wyjście END-TO-END jest wyjściem takim, że: Dla każdego L warstwa (L) spełnia swoje wymagania tylko za pomocą funkcji Funkcja (L, j) (tj. Funkcje w warstwie) i Interfejs (L, L + 1), Interfejs (L + 1, L)

Dla każdej warstwy L i funkcji Funkcja (L, F) nie ma zestawu Funkcji S na wyjściu, więc Funkcja (L, F) = S (= oznacza równoważną wydajność i skutki uboczne)

Tak więc, dochodząc do drugiego możliwego niedociągnięcia dla konkretnego zastosowania zasady e2e (i jeśli dobrze czytam, co się próbuje), można stwierdzić, że wcale nie jest ona zgodna z zasadą e2e. Twoje układy zapewniają „pewne unikanie zakleszczeń” i masz interfejs, który jest nietypowy, nie jest twardy i specyficzny, aby wyzwalać (przerywać) więcej pomocy z wyższych warstw. Jest to prawdopodobnie podejście między warstwami, a nie podejście kompleksowe. Innymi słowy, masz funkcję (1, x), która nie wypełnia swojego zadania całkowicie i poprawnie z ustawionymi interfejsami - jeśli chcesz skorzystać z powyższej formalizacji wersji roboczej (która oczywiście jest tylko początkiem przydatnym do rozszerzenia, aby w pełni odpowiedzieć na twoje pytanie ale prawdopodobnie sama w sobie nie jest pełna).

użytkownik3134164
źródło