Можно ли формализовать сквозной принцип?

В конце 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), которая не выполняет свою задачу полностью и правильно с установленными интерфейсами - если вы хотите использовать черновую формализацию, представленную выше (что, конечно, является лишь началом, полезным для расширения, чтобы полностью ответить на ваш вопрос но скорее всего не полная сама по себе).