В конце 1990-х, когда я учился в аспирантуре, газета
JH Saltzer; DP Reed; Д. Д. Кларк: Сквозные аргументы в дизайне системы . ACM Trans. Вычи. Сист. 2 (4): 277-288, 1984. DOI = 10.1145 / 357401.357402
в каждом классе операционных систем в каждом университете требовалось чтение, и это все еще кажется одним из основных руководящих принципов, лежащих в основе дизайна Интернета. (См., Например: J Kempf, R Austein (eds) и IAB, « Подъем середины и будущее сквозного : размышления об эволюции архитектуры Интернета », RFC 3724, март 2004 г. )
Принцип сквозного принципа гласит (Saltzer et al., 1984):
[Если] рассматриваемая функция может быть полностью и правильно реализована только с ведома и при помощи приложения, стоящего в конечных точках системы связи, ... при условии, что эта сомнительная функция как функция самой системы связи не является возможный. [Хотя] иногда неполная версия функции, предоставляемой системой связи, может быть полезна в качестве повышения производительности.
Или более кратко (из аннотации):
Сквозной аргумент предполагает, что функции, размещенные на низких уровнях системы, могут быть избыточными или иметь небольшую ценность по сравнению со стоимостью их предоставления на этом низком уровне.
Но у меня был небольшой успех в применении сквозного принципа в моем собственном опыте (который относится к компьютерной архитектуре, а не к интернет-архитектуре). Поскольку принцип сформулирован как «стихотворение» (т. Е. В английской прозе с набором терминов, которые не определены математически), довольно легко обмануть себя, полагая, что «данная функция может быть полностью и правильно реализована только с знание и помощь приложения. " Но что такое «рассматриваемая функция», не говоря уже о «знаниях и помощи» приложения?
Пример: внутрипроцессным сетям (в отличие от интернета) запрещается отбрасывать пакеты, но они имеют довольно ограниченную буферизацию, поэтому необходимо иметь какой-либо способ избежать или восстановиться из тупика. С другой стороны, приложение должно быть само по себе свободным от тупиков, не так ли? Таким образом, я мог бы поспорить, что я должен ускорить общий случай (без тупиков) и отключить предотвращение тупиковых ситуаций в приложении. На самом деле это то, что мы попробовали на Алефай и Фугу (Маккензи и др., Использование доставки в двух случаях для быстрой защиты сообщений , Int'l Symp High-Perf Comp Arch, (HPCA-4): 231-242, 1998. Или диссертация Джона Кубятовича.) Это «сработало» (благодаря тому, что межсоединение прерывало процессор, когда буферы были заполнены, и увеличив операционную систему с программной буферизацией), но я не видел никого в академических кругах или промышленности (включая кого-либо из нас, кто был автором этого HPCA paper) мчится вокруг, пытаясь воспроизвести идею. Таким образом, очевидно, что предотвращение взаимоблокировок в сети - это не та «рассматриваемая функция», как предотвращение взаимоблокировок на уровне приложений, или сквозной принцип неверен.
Можно ли превратить сквозной принцип из «стихотворения» в теорему? Или, по крайней мере, это можно сформулировать в терминах, понятных компьютерному архитектору?
источник
Ответы:
Я полагаю, что у вас может быть два недостатка в применении принципа сквозной (e2e):
Во-первых, в том смысле, что вы применяете его для производительности. Сквозной является принципом проектирования, таким как обеспечение ортогональности архитектуры, компоновки, регулярности, одного или всех, предоставление примитивов и т. Д. Такие принципы были изложены в соответствующих учебниках. Производительность не является одним из них. Фактически, Кларк и др. Подразумевают, что строгая сквозная связь может привести к ухудшению производительности, поэтому он использует ее как исключение из этого принципа.
Итак, если вы все еще хотите формализовать:
«Сквозной аргумент обращается к требованиям приложения и предоставляет обоснование для перемещения функции вверх в многоуровневой системе», поэтому вам потребуются формализованные требования приложения и формализованная многоуровневая система. Вот попытка, которая может помочь сделать еще один шаг вперед:
Скажем, у вас есть требования уровня (i) (уровень (0) предназначен для набора приложений, который вы ожидаете поддерживать сейчас или в будущем, уровень приложений) и фирменных интерфейсов Interface (i, i + 1) и Interface (i + 1) , i) (от Уровня i до i + 1 предварительно предполагают, что здесь нет кросс-слоя, легко изменить и сделать его обязательным) и функции Функция (i, j) (Уровень i, Индекс функции j, принять часть данных функции чтобы было проще)
Входные данные: требования Layer (0) (как мы уже говорили, они должны быть формализованы)
Вывод: все остальное
Выход END-TO-END является выходом таким, что: для каждого L уровень (L) выполняет свои требования только с помощью функций Function (L, j) (то есть функций внутри уровня) и Interface (L, L + 1), Interface (L + 1, L),
Для каждого уровня L и функции Function (L, F) в выводе нет набора функций S, так что Function (L, F) = S (= означает эквивалентный выход и побочные эффекты)
Итак, переходя ко второму возможному недостатку для конкретного применения принципа e2e (и если я правильно читаю то, что предпринимают), можно утверждать, что он вообще не следует принципу e2e, а совсем наоборот. Ваши микросхемы обеспечивают «некоторое предотвращение тупиковой ситуации», и у вас есть интерфейс, который является необычным и нестандартным и предназначен для запуска (прерывания) большей помощи от верхних уровней. Это, возможно, межуровневый подход, а не сквозной подход. Другими словами, у вас есть функция (1, x), которая не выполняет свою задачу полностью и правильно с установленными интерфейсами - если вы хотите использовать черновую формализацию, представленную выше (что, конечно, является лишь началом, полезным для расширения, чтобы полностью ответить на ваш вопрос но скорее всего не полная сама по себе).
источник