Вот собственно сабж. Написать новый транспортный протокол.

Флаг прислать?

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Только не забудь свои сетевые карты тоже разработать.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Только не забудь свои сетевые карты тоже разработать.
А нафига? он же не ethernet переписывать собрался

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, BlackTigerAP, Вы писали:

BTA>>Только не забудь свои сетевые карты тоже разработать.
CC>А нафига? он же не ethernet переписывать собрался

Вот вот. Сетевые карты не нужно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, CreatorCray, Вы писали:

CC>>Здравствуйте, BlackTigerAP, Вы писали:

BTA>>>Только не забудь свои сетевые карты тоже разработать.
CC>>А нафига? он же не ethernet переписывать собрался

А>Вот вот. Сетевые карты не нужно.

Это в эту диназавров бы прошло. А на сегодняшний момент сетевые карты не только TCP поддерживают, даже еще и шифрованием балуются. Не говоря уж о том, что де факто TCP стал основой всех операционных систем со всеми вытекающими отсюда кернел моде режимами.

Мне больше всего интересно, чем же автору так протокол не угодил, и что он хочет приподнести в замен. Может тут дело решается все намного проще, так как на голом TCP сейчас мало что пишут.

Здравствуйте, <Аноним>, Вы писали:

А>Мне больше всего интересно, чем же автору так протокол не угодил, и что он хочет приподнести в замен. Может тут дело решается все намного проще, так как на голом TCP сейчас мало что пишут.

Хоть я не автор, но мне конкретно не нравится IP и UDP поверх которого TCP живет. А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе. Ну собственно, чего ожидать, если IP-семейство и близко не придерживается модели OSI... От того так сильно зависят друг от друга, и из-за этой взаимной зависимости с таким скрипом развиваются.

А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.

Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли?

А эти RFC по вкладыванию IP в другие протолы — как гимн кривой архитектуре. Ибо, если бы IP-семейство соответсвовало 7-миуровневой модели OSI, то этой тонны дополнительных стандартов можно было бы избежать.

в то время, как умные перцы думали об абстрактных уровнях OSI, tcp/ip уже годами работал в сетях ARPANET.
потому как перцы не знали о поговорке: "... за исключением большого количества абстрактных слоев".

сравнивать модель tcp и osi некорректно, ибо они суть одно и тоже, только в osi — 7 уровней, а в tcp — ну 4 примерно

>>Хоть я не автор, но мне конкретно не нравится IP и UDP поверх которого TCP живет <прочее бла-бла-бла>

Нда... Плохо быть слишком вумным. Ты, значицца, у нас весь такой умный, а все остальные — дебилы. Вот уж где точно смешно! :D

Никто не говорит, что там не без греха. Только для начала неплохо было бы покопаться в причинах того "греха" для начала, а не заявлять "фсё дирьмо, так как не я делал, а я знаю как сделать лучьше". Молодой ты еще...

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

>>но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети

Не может. Разве что только ОЧЕНЬ ТЕОРИТИЧЕСКИ :D

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, Ovl, Вы писали:

Ovl>в то время, как умные перцы думали об абстрактных уровнях OSI, tcp/ip уже годами работал в сетях ARPANET.
Ovl>потому как перцы не знали о поговорке: "... за исключением большого количества абстрактных слоев".

Да как обычно, кое-что развилось не благодаря, а вопреки. Сетевой протокол, простой как амеба (в разметке IP-пакета), был реализован на коленке как эксперимент. Ну оно как-то заработало. На это дело стали наверчивать дополнительные расширения, типа UDP, а потом — первые реализации TCP, страшно тупые и медленные... зато хоть как-то работающие. В условиях новизны "темы", ИМХО группа энтуазистов за эту тему уцепилась, и нарастила немного мяса, т.е. софта, который пользовал эти протоколы. Уверен, будь хоть какая-нибудь полновесная работающая реализация по модели OSI в то же время и в том же месте, то пошло бы все как в классике.

Ovl>сравнивать модель tcp и osi некорректно, ибо они суть одно и тоже, только в osi — 7 уровней, а в tcp — ну 4 примерно.

Да никаких 4-х независимых слоев нет на самом деле. Все переплетено и зависит друг от друга. Ты не можешь менять слои нижнего уровня, не затрагивая верхних. Именно из-за этого IP-протокол с таким скрипом развивается.

Здравствуйте, BlackTigerAP, Вы писали:

>>>но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети

BTA>Не может. Разве что только ОЧЕНЬ ТЕОРИТИЧЕСКИ :D

Вероятность зависит от частоты пакетов и кол-ва абонентов внутренней сети. Там вероятность близкая к единице, что в течении дня такие ситуации бывают при большом кол-ве абонентов. Просто они отрабатываются проверкой контрольной суммы на каждом TCP-соединении, т.е. происходит сбой "окна" TCP при таких коллизиях.

Здравствуйте, BlackTigerAP, Вы писали:


BTA>Нда... Плохо быть слишком вумным. Ты, значицца, у нас весь такой умный, а все остальные — дебилы. Вот уж где точно смешно! :D

BTA>Никто не говорит, что там не без греха. Только для начала неплохо было бы покопаться в причинах того "греха" для начала, а не заявлять "фсё дирьмо, так как не я делал, а я знаю как сделать лучьше".

Да просто лет 8 назад мне пришлось реализовывать стек IP и упрощенную реализацию TCP для микроконтроллеров. Столько огрех в проектировании стандартов я не встречал ни до, ни после. Да там почти в каждом месте программы, где стоит проверка на ошибку — непонятно что делать, именно. Я с непривычки был в шоке, ибо до этого работал с протоколами пейджинговых систем, сам разрабатывал протоколы для транкинговой связи, работал с протоколами старой сотовой связи (475MHz) и изучал семейство протоколов GSM. Везде все четко, любо-дорого посмотреть. Блин, но в этих RFC есть рекомендации по "политике" реализации реакций сторон в случае сервера и клиента для различных протоколов. Но рекомендации столь размывчаты и неточны, что порой противно... На стандарт это слабо тянет. Нет конкретных четких алгоритмов действий абонентов в тех или иных ситуациях. Все наши TCP работают "интуитивно", именно. Т.е. свою реализацию TCP отлаживаешь до тех пор, пока он не начнет адекватно работать в уже имеющимся окружении (иначе — будет неэффективно использовать полосу... и будь уверен, тут дело далеко не в талантливости программиста-реализатора протокола... Надо прочувствовать тонкости "всемирной реализации TCP", которых нет ни в одном стандарте... Эти тонкости заключаются в принятых как правило хорошего тона действиях в различных ситуациях, т.е. твоя сторона должна как можно точнее предположить дейтствия обратной стороны, чтобы выжать из канала достаточную эффективность... вот на таком дурацком полумистическом уровне обстоят дела... от того знатоки тонкостей реализаций стека IP заслуженно задирают нос, что знания эти — весьма потаённые ).

А то, что в сиськовые тунели виндовоз никак ворваться до сих пор не может — так это притча во язытцах... Все из-за слабой специфицированности (и я бы сказал — сумбурности) стандартов. Такое ощущение, что RFC застряют в развии на уровне идей и готовности к экспериментам, собсно, и расшифровка RFC этому способствует. Отсюда такое неточное представление т.н. "полустандартов" из семейства IP.


Исторические причины развития именно IP-семейства протоколов известны... Определенное кол-во правительственного бабла и сообщество увлеченных бездельников, которые заставили работать нечто "на коленке", не прочитав и пары книг про проектированию сетей (первые RFC того же TCP вызывают жалость). Ну а затем, как обычно в IT-сфере свою роль сыграла преемственность.

>>не прочитав и пары книг про проектированию сетей (первые RFC того же TCP вызывают жалость).

ВОТ! Задумайся над этой фразой! Когда всё это развивалось, НЕ БЫЛО ЕЩЕ КНИГ! И клепать, действительно, приходилось буквально на коленке. И "бабло правительственное" было, точнее военно-университетское. Это сейчас легко говорить "фсё дирьмо", а тогда...

Ну а потом начась уже преемственность и прочая "обратная совместимость", что является больше злом, чем добром, на самом деле. Совместимость должна быть "горизонтальная" (между чем-то, принадлежащем к одному поколению), а не "вертикальная".

Одно за другое... Плюс легендарная американская бюрократия.

Сейчас причесать всё можно только умножением всей бодяги на ноль. И разработкой заново "с учетом предыдущего опыта". Или не париться, а продолжать "жрать кактус".

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

TCP морально и физически устарел.
Взять хотя бы безопасность, использование в мобильных устройствах и т.д. и т.п.

Судя по высказываниям большинство поддерживает данную точку зрения. Дело за малым,
взяться и уничтожить его в ближайшие годы

Кто в помощники?

V>Уверен, будь хоть какая-нибудь полновесная работающая реализация по модели OSI в то же время и в том же месте, то пошло бы все как в классике.

есть 100%-ая уверенность, что развитие реализации шло аналогично IP?

V>Да никаких 4-х независимых слоев нет на самом деле. Все переплетено и зависит друг от друга. Ты не можешь менять слои нижнего уровня, не затрагивая верхних.

я наверно не совсем понимаю, о чем идет речь, поэтому попрошу примеры

V>Именно из-за этого IP-протокол с таким скрипом развивается.

OSI — просто модель. простота и гибкость разработки никак от неё не зависит.

Здравствуйте, Nevidim, Вы писали:

N>Кто в помощники?

Ты думаешь всё так просто?

Я тебе попробую описать, что получиться, если ты каким-то чудом заразишь общественность, доказав актуальность предложенной идеи.

Во первых, новый протокол такого уровня популярности — это, для корпораций, как красная тряпка для быка.
Каждая захочет принять в разработке участие, но сделать всё по-своему.
Организуется консорциум, а ещё лучше два, нет, три консорциума!
В результате получится несколько конкурирующих протоколов.
И все платные и на куче запатентованных технологий.

Через 5 лет появляются первые сетевые устройства поддерживающие эти протоколы.

А вообще то, похоже что так оно сейчас и происходит.
WiFi, Bluetooth и прочие на чём основанны?

Здравствуйте, Ovl, Вы писали:



V>>Да никаких 4-х независимых слоев нет на самом деле. Все переплетено и зависит друг от друга. Ты не можешь менять слои нижнего уровня, не затрагивая верхних.

Ovl>я наверно не совсем понимаю, о чем идет речь, поэтому попрошу примеры

Протокол верхнего уровня использует команды низкого уровня для управления своим состоянием.


V>>Именно из-за этого IP-протокол с таким скрипом развивается.

Ovl>OSI — просто модель. простота и гибкость разработки никак от неё не зависит.

Упссс... Тогда обсуждать нечего, ибо по-твоему эти уровни были выбраны совершенно случайно. На самом деле было взято МИНИМАЛЬНОЕ кол-во уровней, обеспечивающих низкую связанность или даже полное отсутствие связанности протоколов разных уровней. В IP получилось по наихудшему варианту.

V>Протокол верхнего уровня использует команды низкого уровня для управления своим состоянием.

это пример?
а можно поближе к реальности: какой протокол, какие команды, какое состояние?

V>Упссс... Тогда обсуждать нечего, ибо по-твоему эти уровни были выбраны совершенно случайно. На самом деле было взято МИНИМАЛЬНОЕ кол-во уровней, обеспечивающих низкую связанность или даже полное отсутствие связанности протоколов разных уровней. В IP получилось по наихудшему варианту.

модель не может определить уровень связанности реализации.
в модели TCP/IP также было взято действительно минимальное кол-во уровней.

Здравствуйте, WoldemaR, Вы писали:

WR>Организуется консорциум, а ещё лучше два, нет, три консорциума!
WR>В результате получится несколько конкурирующих протоколов.

Васюки переименовываются в Нью-Москву, Москва — Старые Васюки!!" (с)

V>Хоть я не автор, но мне конкретно не нравится IP и UDP поверх которого TCP живет.
TCP живет поверх IP. И UDP живет поверх IP. TCP никак не живет поверх UDP. Читать матчасть прежде чем лажать TCP. Придумывали его может и на коленке, но на профессорской коленке.
А без IP заголовка твой пакет не уйдет дальше первого роутера. Впрочем без TCP/UDP заголовков тоже скорее всего не уйдет

V>А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.
Надо заложить ровную сущность под названием GUID да? Кому оно нах надо такое здоровое в каждом пакете. Его же не только передавать — еще обсчитывать надо во всяких NAT'ах и роутерах где с производительностью очень большие траблы. Порты прекрасно справляются с поставленной задачей.. Впрчем не в руках человека который думает что TCP работает повер UDP.

V>Ну собственно, чего ожидать, если IP-семейство и близко не придерживается модели OSI... От того так сильно зависят друг от друга, и из-за этой взаимной зависимости с таким скрипом развиваются.
Сделаешь свой свою реализацию протокола которыая будет строго по оси и так же шустра и гибка как TCP/IP — карты в руки. Учти что tcp чексамы обсчитываются драйверами современных сетевых карточек аппаратно. А красота строгого следования модели OSI в жестоком мире юниксов и CISCO маршрутизаторов в которых стояит 200Mhz процы никому не нужна.

V>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.
GUID? ага. См про CISCO и чексамы

V>Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли?
Она не пересчитывается а слегка корректируется. Есть специальные оптимизированные алгоритмы коррекции чексам пакетов при измененнии определенных их полей без полного пересчета чексамы. Ага?

V>А эти RFC по вкладыванию IP в другие протолы — как гимн кривой архитектуре. Ибо, если бы IP-семейство соответсвовало 7-миуровневой модели OSI, то этой тонны дополнительных стандартов можно было бы избежать.
бгг.

Здравствуйте, Ovl, Вы писали:

V>>Протокол верхнего уровня использует команды низкого уровня для управления своим состоянием.

Ovl>это пример?
Ovl>а можно поближе к реальности: какой протокол, какие команды, какое состояние?

Легче написать, кто не использует команды ICMP, например. Конкретно для TCP это означает транспортный, сетевой и канальный уровень в рамках одного протокола. Учитывая API осей для открытия и управления TCP-каналами, смело можно присовокупить сеансовый уровень в эту кашу. брррр


Ovl>модель не может определить уровень связанности реализации.

чего??? понятие связанности не понимаешь.


Ovl>в модели TCP/IP также было взято действительно минимальное кол-во уровней.

Нет четких уровней в IP. Есть несколько взаимодействующих протоколов и стандартов (разделенных скорее по структуре пакетов, но по сути, находящихся на одном уровне). Слово "взаимодействующих" — ключевое.

Здравствуйте, <Аноним>, Вы писали:

V>>А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.
А>Надо заложить ровную сущность под названием GUID да? Кому оно нах надо такое здоровое в каждом пакете. Его же не только передавать — еще обсчитывать надо во всяких NAT'ах и роутерах где с производительностью очень большие траблы.

Во-во. А ведь длина идентификатора потока — это личное дело конкретного уровня связи (обычно транспортного для логического или канального для физического пакетов). Не должен канальный уровень знать что-либо о метках транспортного. NAT был бы принципиально не нужен. Ведь его используют как обход врожденного ограничения системы адресации хостов и портов IP.


А>Сделаешь свой свою реализацию протокола которыая будет строго по оси и так же шустра и гибка как TCP/IP — карты в руки.

Можно подробнее про гибкость, а то ИМХО, тут кто-то это понятие по-своему понимает.


V>>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.
А>GUID? ага. См про CISCO и чексамы

Смотри на форматы пакетов IPv6 хотя бы. Потом вернемся к NAT, ok? А пока обсуждать нечего, ибо ты явно считаешь, что проблемы нет, а разработчики IPv6 напрасно правили эти откровенные ляпы.


V>>Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли?
А>Она не пересчитывается а слегка корректируется. Есть специальные оптимизированные алгоритмы коррекции чексам пакетов при измененнии определенных их полей без полного пересчета чексамы. Ага?

Не "ага", а зачем?

Ты че, не понимаешь или прикидываешься? При поддержке полноценной OSI всякий новый уровень туннелирования (не обязательно один, заметь) добавлял бы лишь один дополнительный обсчет чексумов на конечных станциях абонентов. И для всех остальных уровней аналогично. Ну не должны маршрутизаторы обсчитывать сразу несколько чексумов. Каждый уровень должен обсчитывать только свои чексумы, т.е. для каждого более высокого уровня обсчет производится всегда на концах связи. Причем, для классической OSI обсчет чексумов мог бы быть вообще только на канальном и сетевом уровне. Сложность современных маршрутизаторов от того, что они вынуждены разбирать и формировать заново пакеты дополнительно еще сетевого и транспортного уровня, а они совершенно не должны этого делать, ибо должны обитать целиком на канальном уровне.

V>Легче написать, кто не использует команды ICMP, например. Конкретно для TCP это означает транспортный, сетевой и канальный уровень в рамках одного протокола. Учитывая API осей для открытия и управления TCP-каналами, смело можно присовокупить сеансовый уровень в эту кашу. брррр

TCP (транспортный уровень) является оберткой для IP (сетевой уровень), который рассылает свои фреймы на нижележащий уровень. разве это аналогично тому, что TCP держит в своих руках все 3 уровня?

ICMP используется для обмена информацией внутри стека IP (передача осуществляется аналогично UDP). И ошибочно причисляется к сетевому уровню.
если какой-то сетевой протокол пользуется своими средствами — это описано в стандарте протокола и не является секретом

V>чего??? понятие связанности не понимаешь.

удачный комплимент
не сомневаюсь, что OSI, как и любой сферический конь в вакууме, идеален в плане связанности.

V>Нет четких уровней в IP. Есть несколько взаимодействующих протоколов и стандартов (разделенных скорее по структуре пакетов, но по сути, находящихся на одном уровне). Слово "взаимодействующих" — ключевое.

но все же было бы удобно почитать не философию, а примеры

Здравствуйте, Ovl, Вы писали:


Ovl>но все же было бы удобно почитать не философию, а примеры

Примера ICMP не достаточно? Или мне сюда таблицу из справочника выложить команд этого протокола, а потом по всем RFC собрать, кто команды ICMP использует? В общем, если тебе нужны подробности, то go RFC 1256 (и 792).

V>Примера ICMP не достаточно? Или мне сюда таблицу из справочника выложить команд этого протокола, а потом по всем RFC собрать, кто команды ICMP использует? В общем, если тебе нужны подробности, то go RFC 1256 (и 792).

обязательно почитаю, но и лучше объясню что меня смутило:

V> Протокол верхнего уровня использует команды низкого уровня для управления своим состоянием
OVL> какой протокол, какие команды, какое состояние?
V> Легче написать, кто не использует команды ICMP, например [skipped]

конечно можно поискать кто не использует ICMP, я просто не понимаю, какое это отношение имеет к "Протокол верхнего уровня использует команды низкого уровня для управления своим состоянием". сама логика ответа мне не понятна, будь она даже 100% правильной.

если не хочется обяснять — нет проблем, но не надо говорить "ну что вы все такие тупые"

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, <Аноним>, Вы писали:

V>>>А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.
А>>Надо заложить ровную сущность под названием GUID да? Кому оно нах надо такое здоровое в каждом пакете. Его же не только передавать — еще обсчитывать надо во всяких NAT'ах и роутерах где с производительностью очень большие траблы.

V>Во-во. А ведь длина идентификатора потока — это личное дело конкретного уровня связи (обычно транспортного для логического или канального для физического пакетов). Не должен канальный уровень знать что-либо о метках транспортного. NAT был бы принципиально не нужен. Ведь его используют как обход врожденного ограничения системы адресации хостов и портов IP.


А>>Сделаешь свой свою реализацию протокола которыая будет строго по оси и так же шустра и гибка как TCP/IP — карты в руки.
V>Можно подробнее про гибкость, а то ИМХО, тут кто-то это понятие по-своему понимает.
IP — гибкость в маршрутизации пакетов. Устойчивость к "путанице" в условиях реальных линий связи с потерями и дубликатами приходящих пакетов.
TCP — оптимальность скорости потоковой передачи в любых технических линиях связи — модемные линии где дропается половина IP пакетов, 10-100-1000mbit линки — на них теряется почти 99.9% пакетов если слать с максимальной скоростью передачи, спутниковые каналы с офигенными скоростями и задержками в одну сторону 3 сек а в другую — 0.3 сек... И много-много других, проблемы типа NAT это мелочи


V>>>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.
А>>GUID? ага. См про CISCO и чексамы
V>Смотри на форматы пакетов IPv6 хотя бы. Потом вернемся к NAT, ok? А пока обсуждать нечего, ибо ты явно считаешь, что проблемы нет, а разработчики IPv6 напрасно правили эти откровенные ляпы.
NAT как таковой появился по сути изза недостатка адресов в IPv4.

V>>>Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли?
А>>Она не пересчитывается а слегка корректируется. Есть специальные оптимизированные алгоритмы коррекции чексам пакетов при измененнии определенных их полей без полного пересчета чексамы. Ага?
V>Не "ага", а зачем?


V>Ты че, не понимаешь или прикидываешься? При поддержке полноценной OSI всякий новый уровень туннелирования (не обязательно один, заметь) добавлял бы лишь один дополнительный обсчет чексумов на конечных станциях абонентов. И для всех остальных уровней аналогично. Ну не должны маршрутизаторы обсчитывать сразу несколько чексумов. Каждый уровень должен обсчитывать только свои чексумы, т.е. для каждого более высокого уровня обсчет производится всегда на концах связи.
ггг. Ну так оно и ведь есть в СЗ.ШЗ. IP чексума — это чексума ип заголовка, TCP — tcp и данных, какие претензии?

Здравствуйте, Ovl, Вы писали:


Ovl>конечно можно поискать кто не использует ICMP, я просто не понимаю, какое это отношение имеет к "Протокол верхнего уровня использует команды низкого уровня для управления своим состоянием". сама логика ответа мне не понятна, будь она даже 100% правильной.

Ну очень просто. Протокол верхнего уровня на самом деле должен просто говорить протоколу нижнего уровня: а пошли-ка от меня до вот этого логического адресата вот эти вот байты (строки, данные и т.д.). Именно с эти позиций разработана модель OSI, которая теоретически позволяет выстраивать произвольную иерархию протоколов, в том плане, что приложение, использующе некий сеансовый протокол, на самом деле может легко работать в сети, где нижлежащие уровни сделаны неизвестным для приложения способом.

Всё, понимаешь. Протокол верхнего уровня не должен заботится о том, как именно эти данные передаются.

Напротив в IP, если уж у тебя в приложении завязка на IP, то ты только с IP и работаешь.

V>Всё, понимаешь. Протокол верхнего уровня не должен заботится о том, как именно эти данные передаются.
V>Напротив в IP, если уж у тебя в приложении завязка на IP, то ты только с IP и работаешь.

угук, значит начало я начал правильно.
теперь конец.
в стеке IP сам IP находится на предпоследнем уровне — на сетевом, после него только транспортный.
в самом приложении (гипотетическом) — ты открываешь сокет с какими-то параметрами (например TCP/IP или UDP), и работаешь только с интерфейсом, которые дают эти протоколы.
есть возможность посылать raw-пакеты, прямо в сеть.

получается, что:
1. хочешь — используй иерархию TCP(UDP)
2. не хочешь — пиши прямо в сеть

если так, то получается и изоляция, и сквозной доступ.
я думаю, что к реализации OSI девелоперы выдвинули точно такие же требования, так как нельзя написать идеальный код, к которому уже не прибавить, не убавить

Здравствуйте, Ovl, Вы писали:

V>>Всё, понимаешь. Протокол верхнего уровня не должен заботится о том, как именно эти данные передаются.
V>>Напротив в IP, если уж у тебя в приложении завязка на IP, то ты только с IP и работаешь.

Ovl>угук, значит начало я начал правильно.
Ovl>теперь конец.
Ovl>в стеке IP сам IP находится на предпоследнем уровне — на сетевом, после него только транспортный.

А транспортный уровень — это какой?

На самом деле и сетевой и канальный уровни объеденены. Более того — используют одну и ту же адресацию, вот в чем бяка, к тому же не совсем удачную (отчего NAT и придуман). Любое, абсолютно любое твое приложение (не системное) использует логические адреса, и ты постоянно лезешь в DNS, явно либо неявно. Но ты не должен этого делать, сеть это должна делать за тебя, а в IP-сети к DNS постоянно обращается каждый конечный участник сети. Т.е. ты постоянно влазишь на сетевой уровень, хотя в прикладной программе максимум который интересует (если это не снифер какой-нить) — это сеансовый уровень.

V>На самом деле и сетевой и канальный уровни объеденены. Более того — используют одну и ту же адресацию, вот в чем бяка,
Мальчик, вы бредите. Канальный уровень — это ethernet или какой нить PPP. Адресация там отнюдь не IP.

V>к тому же не совсем удачную (отчего NAT и придуман).
NAT к канальному уровню отношения не имеет.

V>Любое, абсолютно любое твое приложение (не системное) использует логические адреса,
tcp/ip знает только про IP адреса, IP протоколы и TCP и UDP порты

V>и ты постоянно лезешь в DNS, явно либо неявно.
DNS это прикладной протокол. TCP/IP на него завязан так же как и на какой нибудь telnet. То бишь — никак. Не путайте пожалуйста TCP/IP как протокол и сокеты как API, которые действительно очень сильно связаны с доменными именами.

>Но ты не должен этого делать, сеть это должна делать за тебя, а в IP-сети к DNS постоянно обращается каждый конечный участник сети. Т.е. ты постоянно влазишь на сетевой уровень, хотя в прикладной программе максимум который интересует (если это не снифер какой-нить) — это сеансовый уровень.
резолвинг — это процесс обращения к распределенной базе чтобы узнать IP адрес. DNS — это база читабельных альясов для IP адресов. Самому TCP/IP она нафиг не надо.

V>(475MHz) и изучал семейство протоколов GSM. Везде все четко, любо-дорого посмотреть. Блин, но в этих RFC есть
V>рекомендации по "политике" реализации реакций сторон в случае сервера и клиента для различных протоколов. Но
V>рекомендации столь размывчаты и неточны, что порой противно... На стандарт это слабо тянет. Нет конкретных четких
V>алгоритмов действий абонентов в тех или иных ситуациях. Все наши TCP работают "интуитивно", именно. Т.е. свою
V>реализацию TCP отлаживаешь до тех пор, пока он не начнет адекватно работать в уже имеющимся окружении (иначе — будет Если не заметили -всн широкоиспользуемые протоколы стандартизованы ужасно нечетко. HTTP, FTP, TELNET, SMTP, POP3 -все текствые протоколы просто ад для парсинга. HTML документы на которых инет построен — их ведь отображают "как могут"... Мона вдарится в философию и подумать об нечеткости человеческого поведения.. Но мир заполнен именно этми нечеткостями и сила их — в способности к адаптации к самым разным условиям благодаря своей неопределенности.. Подумайте над этим

Здравствуйте, <Аноним>, Вы писали:


V>>На самом деле и сетевой и канальный уровни объеденены. Более того — используют одну и ту же адресацию, вот в чем бяка,
А>Мальчик, вы бредите. Канальный уровень — это ethernet или какой нить PPP. Адресация там отнюдь не IP.

Сразу go в классику OSI.


V>>Любое, абсолютно любое твое приложение (не системное) использует логические адреса,
А>tcp/ip знает только про IP адреса, IP протоколы и TCP и UDP порты

К тому же сложности с концентрацией внимания. Речь идет о прикладных программах. Напряги плиз внимание и прочти еще раз абзац, на который ты так невпопад ответил.


V>>и ты постоянно лезешь в DNS, явно либо неявно.
А>DNS это прикладной протокол. TCP/IP на него завязан так же как и на какой нибудь telnet. То бишь — никак. Не путайте пожалуйста TCP/IP как протокол и сокеты как API, которые действительно очень сильно связаны с доменными именами.

Это было согласие или возражение? И где, собственно, путаница? Говорилось только о том, что прикладные программы постоянно влезают на сетевой уровень. И вообще, "намертво" завязаны на конкретный низкоуровневый протокол. Такое положение вещей я считаю неудачным. (И не надо считать, что собеседник путает TCP и DNS, смешно звучит)


А>резолвинг — это процесс обращения к распределенной базе чтобы узнать IP адрес. DNS — это база читабельных альясов для IP адресов. Самому TCP/IP она нафиг не надо.

Угу, попытка устроить сеанс ликбеза. Спасибо, но я надеялся, что участвующие в этой ветке и так понимают, что именно имеется ввиду под аббревиатурами, не обязательно им расшифровывать.

Еще раз для тех, кто в танке. Речь о том, что во-первых, многие IP-протоколы "намертво" завязаны друг на друга, от чего и существуют объективные трудности в развитии протоколов (т.е. по уровню связанности дизайну основных IP-протоколов можно ставить двойку), во-вторых, прикладные сетевые программы, использующие IP, так же намертво привязаны именно к этому протоколу, по той же самой причине — отсутствия четкого деления на уровни. Пример с DNS и АПИ осей относительно IP — это лишь наглядная демонстрация, к какому бреду приводит некачественная архитектура сетевых протоколов.

Здравствуйте, <Аноним>, Вы писали:

V>Если не заметили -всн широкоиспользуемые протоколы стандартизованы ужасно нечетко. HTTP, FTP, TELNET, SMTP, POP3 -все текствые протоколы просто ад для парсинга. HTML документы на которых инет построен — их ведь отображают "как могут"... Мона вдарится в философию и подумать об нечеткости человеческого поведения.. Но мир заполнен именно этми нечеткостями и сила их — в способности к адаптации к самым разным условиям благодаря своей неопределенности.. Подумайте над этим

Опять подумать над этим?

В общем, из-за нечетких спецификаций существуют проблемы несовместимости. VPN от одних производителей не работает с VPN от других, соединенные маршрутизаторы одной фирмы неплохо выжимают из физического канала, но в паре с "чужими" работают явно слабее и т.д. Что тут думать-то? В СССР за несоблюдение стандартов была уголовная статья. Звучит зверско, но ведь любые несоблюдения стандартов, в случае масштабирования/разможения приводят к трудноподсчитываемым астрономическим доп.затратам/убыткам.

Я уже приводил примеры из GSM. И вообще, любые протоколы, разработанные "железячниками", отличаются четкостью, Т.е. включил — и сразу работает. А как же иначе, выкинуть многотысячную партию электронных устройств — это тебе не строчку в коде подправить, тут, панимаешь, отвественность висит над душой. Я когда отдавал в производство несчастную процессорную плату в 97-м году обливался холодным пОтом... перед этим многократно все проверил и успокоился только тогда, когда пробная партия, собранная посторонними людьми, заработала сразу. Для ПО это все недостижимо на современном уровне ментальности.

V>>>На самом деле и сетевой и канальный уровни объеденены. Более того — используют одну и ту же адресацию, вот в чем бяка,
А>>Мальчик, вы бредите. Канальный уровень — это ethernet или какой нить PPP. Адресация там отнюдь не IP.
V>Сразу go в классику OSI.
физический — сетевое оборудование, аппаратная архитектура (аппаратные стандарты ethernet 100, 10, F/O etc)
—
канальный — протокол ethernet. Адресация MAC (6 байтные адреса, заголовок 14 байт, нет контрольной суммы)
—
сетевой — IPv4. Адресация IPv4 (4байтные адреса свой заголовок, контрольная сумма исключительно IP заголовка), ICMP тоже сетевой уровень.
—
Далее ветвление — два стандартных транспортных протокола — UDP и TCP. У каждого свой заголовок который идет в составе данные IP пакета. У них свои чексумы которые включают заголовок и данные. TCP работает _не_ поверх UDP как вы утвержадли пару мессаг назадю.
—
Сессионный — всякие RPC работающие over TCP & UDP.
—
на 6й уровень примеров увы привести сходу не могу.
—
Далее стандартные прикладные протоколы например DNS, NETBIOS — работают over UDP и TCP. FTPSMTP, POP3, TELNET, SSH — over TCP.


Апдикухи пользуются как транспортными протоколами типа TCP/UDP так и по желанию стандартными приколадными. Которые кстати совсем необязательно могут присутствовать в OS.


V>>>Любое, абсолютно любое твое приложение (не системное) использует логические адреса,
А>>tcp/ip знает только про IP адреса, IP протоколы и TCP и UDP порты
V>К тому же сложности с концентрацией внимания. Речь идет о прикладных программах. Напряги плиз внимание и прочти еще раз абзац, на который ты так невпопад ответил.
Речь вроде идет о протоколе? сабж "Написать свой протокол взамен TCP"

V>>>и ты постоянно лезешь в DNS, явно либо неявно.
А>>DNS это прикладной протокол. TCP/IP на него завязан так же как и на какой нибудь telnet. То бишь — никак. Не путайте пожалуйста TCP/IP как протокол и сокеты как API, которые действительно очень сильно связаны с доменными именами.
V>Это было согласие или возражение? И где, собственно, путаница? Говорилось только о том, что прикладные программы постоянно влезают на сетевой уровень.
DNS это не сетевой уровень.

V>И вообще, "намертво" завязаны на конкретный низкоуровневый протокол.
DNS это прикладной уровень.

V>Такое положение вещей я считаю неудачным. (И не надо считать, что собеседник путает TCP и DNS, смешно звучит)
Просто у вас каша в голове.


А>>резолвинг — это процесс обращения к распределенной базе чтобы узнать IP адрес. DNS — это база читабельных альясов для IP адресов. Самому TCP/IP она нафиг не надо.
V>Угу, попытка устроить сеанс ликбеза. Спасибо, но я надеялся, что участвующие в этой ветке и так понимают, что именно имеется ввиду под аббревиатурами, не обязательно им расшифровывать.
V>Еще раз для тех, кто в танке. Речь о том, что во-первых, многие IP-протоколы "намертво" завязаны друг на друга,
Дааа? Где же привязки?

ethernet фреймы шлются по сетевым картам, диалап/ADSL модемам, радиоканалам, оптика
--
IP работает over ethernet, over token ring, over PPP, over SLIP, over PPPtP, over почтовые голуби (дада есть и такое, составители RFC умеют шутить
ICMP/IGMP на том же уровне что IP.
--
UDP и TCP как _протоколы_ не привязаны к IP. К IP привязано стандартное API под названием берклиевские сокеты, которые принимают в одной структуре в качестве destination IP адрес, идентификатор транспортного протокола и его порт TCP/UDP порт. А что? Удобно.
--
DNS как прикладной протокол базы данных читабельных альясов IP адресов понятное дело работает на TCP/UDP


> от чего и существуют объективные трудности в развитии протоколов (т.е. по уровню связанности дизайну основных IP-протоколов можно ставить двойку), во-вторых, прикладные сетевые программы, использующие IP, так же намертво привязаны именно к этому протоколу, по той же самой причине — отсутствия четкого деления на уровни.
Предлагаю забыть про сокеты, взять ethereal в руки и посмотреть как выглядят пакеты _протокола_ в сети. Хочется разработать свой API более идеологически совместимый с OSI чем с сокетами — пожалуйтса. API и протокол — это как велосипед и стол. Две разные вещи.

V>Пример с DNS и АПИ осей относительно IP — это лишь наглядная демонстрация, к какому бреду приводит некачественная архитектура сетевых протоколов
Повторяю — TCP/IP _никак_ не завязан нс DNS. Одноранговые виндовые локальные сети работают без DNS резолвя имена нетбиосовскими броадкастами. В NT/95 даже DNS как таковой не установлен в системе по умолчанию.

V>>Если не заметили -всн широкоиспользуемые протоколы стандартизованы ужасно нечетко. HTTP, FTP, TELNET, SMTP, POP3 -все текствые протоколы просто ад для парсинга. HTML документы на которых инет построен — их ведь отображают "как могут"... Мона вдарится в философию и подумать об нечеткости человеческого поведения.. Но мир заполнен именно этми нечеткостями и сила их — в способности к адаптации к самым разным условиям благодаря своей неопределенности.. Подумайте над этим
V>Опять подумать над этим?

V>В общем, из-за нечетких спецификаций существуют проблемы несовместимости. VPN от одних производителей не работает с VPN от других, соединенные маршрутизаторы одной фирмы неплохо выжимают из физического канала, но в паре с "чужими" работают явно слабее и т.д.
Как сотрудник конторы которая в частности VPN выпускает могу сказать что если речь идет о внедрении какой либо вкусной фичи, то вопрос совместимости этой фичи с VPN клиентами рассматривается на уровне — "лишь бы работало". Это жизнь

V>Что тут думать-то? В СССР за несоблюдение стандартов была уголовная статья. Звучит зверско, но ведь любые несоблюдения стандартов, в случае масштабирования/разможения приводят к трудноподсчитываемым астрономическим доп.затратам/убыткам.
Эти затраты идут в карман производителей VPN решений

V>Я уже приводил примеры из GSM. И вообще, любые протоколы, разработанные "железячниками", отличаются четкостью, Т.е. включил — и сразу работает.
Ну так вы железячники ведь протоколы под конкретные устройства и конкретные _имеющиеся_ требования разрабатываете


А как же иначе, выкинуть многотысячную партию электронных устройств — это тебе не строчку в коде подправить, тут, панимаешь, отвественность висит над душой. Я когда отдавал в производство несчастную процессорную плату в 97-м году обливался холодным пОтом... перед этим многократно все проверил и успокоился только тогда, когда пробная партия, собранная посторонними людьми, заработала сразу. Для ПО это все недостижимо на современном уровне ментальности.
Понимаете в ширпортеб выходит то что не заточено под конкретные задачи. TCP/IP призван работать везде где можно, вплоть до почтовых голубей, а не в таких то и тах то усовиях. Потому и такие спецификации.

построен — их ведь отображают "как могут"... Мона вдарится в философию и подумать об нечеткости человеческого поведения.. Но мир заполнен именно этми нечеткостями и сила их — в способности к адаптации к самым разным условиям благодаря своей неопределенности.. Подумайте над этим
V>Опять подумать над этим?

Подумайте было ли бы возможно это если бы поведение tcp/ip и сиантартных прикладных протоколов было строго регламентировано документацией и по другому не работало: http://www.opennet.ru/opennews/art.shtml?num=6263

V>Это было согласие или возражение? И где, собственно, путаница? Говорилось только о том, что прикладные программы постоянно влезают на сетевой уровень.
То что во всяких .Net-овских и Java-вских платформах сокет можно конектить сразу на имня хоста — это просто упрощение жизни программисту, tcp/ip как протокол тут совсем не причем.
Конкретный берклиевский IPPROTO_TCP сокет подключаться может исключительно _на_IP_адрес_ так что ни о каком неявном обращении к DNS речи и идти не может.
Кроме того что DNS как сам таковой является протоколом прикладного уровня, говорить что "прикладные программы постоянно влезают на сетевой уровень" означает то что прикладные программы постоянно вызывают функцию gethostbyname/gethostbyaddr для определения IP адреса по имени хоста. Для резолвинга IP адреса по имени в берклиевских сокетах есть отдельная функция а приконектить сокет на хостнейм никак нельзя
Более того — gethostbyname совсем необязательно будет работать по DNS, это так, к слову

Здравствуйте, <Аноним>, Вы писали:


А>канальный — протокол ethernet. Адресация MAC (6 байтные адреса, заголовок 14 байт, нет контрольной суммы)

Знаешь, что ты забыл упомянуть в плане Ethernet-протокола? Это самое главное: физические параметры ethernet-сигналов. Так что у кого тут каша в голове мы видим.


V>>Это было согласие или возражение? И где, собственно, путаница? Говорилось только о том, что прикладные программы постоянно влезают на сетевой уровень.
А>DNS это не сетевой уровень.

Ты только что написал, что адресация IP — это сетевой уровень. Блин, мы что, используем DNS ради DNS? Да мы туда лезем за определенной спецификой IP. Мы сами лезем в подробности организации сетевого протокола только затем, чтобы установить, например, соединение однозначно транспортного уровня (TCP — соединение).


V>>И вообще, "намертво" завязаны на конкретный низкоуровневый протокол.
А>DNS это прикладной уровень.

DNS — это необходимость приложению самостоятельно делать соответствия м/у прикладной и сетевой адресацией. В общем, ответы откровенно не в попад на мой вгляд, продолжать обсуждение скучно, мы о разных категориях говорим.


А>UDP и TCP как _протоколы_ не привязаны к IP.

Серьезно? И подсчет чексумы по "виртуальному" IP-заголовку тоже не привязан к IP? RFC сам найдешь или подсказать? TCP неотделим от IP, вот в чем дело. Невозможно отделить содержимое TCP/UDP-пакетов от объемлющего IP-протокола. Более того, по такому понятию, как адресация портов, вообще получаем конфликт TCP и UDP. Там вообще каша. Ничто не мешает, например, на стороне сервера принимать tcp и udp пакеты на один и тот же порт — стандарт никак не запрещает. Но для этого нет стандартного АПИ. У реализации MS TCP есть такая частичная возможность, у беркли-АПИ — нет.


А>К IP привязано стандартное API под названием берклиевские сокеты, которые принимают в одной структуре в качестве destination IP адрес, идентификатор транспортного протокола и его порт TCP/UDP порт. А что? Удобно.

Да пофиг какое конкретно АПИ. Хоть виндовое, которое содержит посиксное как под-АПИ. Суть не меняется. Прикладные программы намертво привязаны к сетевому протоколу. Сравни протокол named-pipes, мне уже скучно обсуждать, ибо твои ответы похожы на ответы глухого. Ты отвечаешь не на то, о чем речь.


А>DNS как прикладной протокол базы данных читабельных альясов IP адресов понятное дело работает на TCP/UDP

Опять скатываемся на ликбез?
Ты бы лучше потратил время на описание заголовка стандартных посиксных адресов: "высокоуровневый_протокол://пользователь:пароль@домен/адрес_в_домене". Это нормальный такой прикладной адрес сеансового уровня. Так вот, в настоящий момент я должен самостоятельно в каждом приложении выполнять разложение этого адреса на составляющие, чтобы попользовать DNS и снова собрать этот адрес уже в другом виде. После этого выслушивать, что высокоуровневые протоколы не завязаны на IP, мне откровенно скучно.


>> от чего и существуют объективные трудности в развитии протоколов (т.е. по уровню связанности дизайну основных IP-протоколов можно ставить двойку), во-вторых, прикладные сетевые программы, использующие IP, так же намертво привязаны именно к этому протоколу, по той же самой причине — отсутствия четкого деления на уровни.
А>Предлагаю забыть про сокеты, взять ethereal в руки и посмотреть как выглядят пакеты _протокола_ в сети. Хочется разработать свой API более идеологически совместимый с OSI чем с сокетами — пожалуйтса. API и протокол — это как велосипед и стол. Две разные вещи.

Лучше возьми named-pipes и посмотри в чем разница, я устал намекать. Для named-pipes пофиг, как именно идут данные, либо через shared-memory (internal pipes), либо непосредственно через ethernet или token-ring, либо через IP. Если бы еще не было вынужденной (для MS) привязки к IP-адресации, было бы вообще великолепно.

V>>Пример с DNS и АПИ осей относительно IP — это лишь наглядная демонстрация, к какому бреду приводит некачественная архитектура сетевых протоколов
А>Повторяю — TCP/IP _никак_ не завязан нс DNS. Одноранговые виндовые локальные сети работают без DNS резолвя имена нетбиосовскими броадкастами. В NT/95 даже DNS как таковой не установлен в системе по умолчанию.

Одноранговые сети microsoft могут работать без IP вообще, прямо через Ethernet.

-----------
Кстати, любитель устраивать ликбез. Вот определения уровней, попытайся еще раз найти место Ethernet, ATM, IP и т.д.

1) Физический уровень определяет электротехнические, механические, процедурные и функциональные характеристики активации, поддержания и дезактивации физического канала между конечными системами. Спецификации физического уровня определяют уровни напряжений, синхронизацию изменения напряжений, скорость передачи физической информации, максимальные расстояния передачи информации, требования к среде передачи, физические соединители и другие аналогичные характеристики.

2) Канальный уровень (Data Link) обеспечивает надежный транзит данных через физический канал. Выполняя эту задачу, канальный уровень решает вопросы физической адресации, топологии сети, линейной дисциплины (каким образом конечной системе использовать сетевой канал), уведомления о неисправностях, упорядоченной доставки блоков данных и управления потоком информации. Обычно этот уровень разбивается на два подуровня: LLC (Logical Link Control) в верхней половине, осуществляющего проверку на ошибки, и MAC (Media Access Control) в нижней половине, отвечающего за физическую адресацию и прием/передачу пакетов на физическом уровне.

3) Сетевой уровень обеспечивает соединение и выбор маршрута между двумя конечными системами, подключенными к разным "подсетям", которые могут находиться в разных географических пунктах. Сетевой уровень отвечает за выбор оптимального маршрута между станциями, которые в могут быть разделены множеством соединенных между собой подсетей.

4) Транспортный — самый высокий из уровней, отвечающих за транспортировку данных. На этом уровне обеспечивается надежная транспортировка данных через объединенную сеть. Транспортный уровень обеспечивает механизмы для установки, поддержания и упорядоченного завершения действия виртуальных каналов, систем обнаружения и устранения неисправностей транспортировки и управления информационным потоком.

5) Сеансовый уровень устанавливает, управляет и завершает сеансы взаимодействия между прикладными задачами. Сеансы состоят из диалога между двумя или более объектами представления. Сеансовый уровень синхронизирует диалог между объектами представительного уровня и управляет обменом информации между ними. В дополнение к управлением сеансами этот уровень предоставляет средства для отправки информации, класса услуг и уведомления в исключительных ситуациях о проблемах сеансового и более высоких уровней.

Особенно рекомендую обратить внимание на описание ATM, а так же на такую хрень как ethernet on radio. Я вижу некие познания в области IP у тебя (и постоянные попытки поделиться этими познаниями с читателями ), но так же вижу отсутсвие банального технического кругозора. Как ты можешь участвовать в сравнении IP с другими протоколами, если у тебя недостаточно информации о других протоколах?

Здравствуйте, <Аноним>, Вы писали:


А>Подумайте было ли бы возможно это если бы поведение tcp/ip и сиантартных прикладных протоколов было строго регламентировано документацией и по другому не работало: http://www.opennet.ru/opennews/art.shtml?num=6263

Прикольная ссылка, ведь стек IP-это не шутка. Но панимаешь... я склоняюсь к тому, что при четком разделении уровней для подобных "серверов" можно было бы подобрать наипростейший транспортный протокол. Транспортный, мсье, только транспортный. Так код стека протокола мог бы вообще отсутствовать или быть десяток байт, для некоего простейшего транспортного протокола. А сэкономленное пространство в ПЗУ отдать под лучшую реализацию прикладного HTTP-протокола.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, <Аноним>, Вы писали:


А>>канальный — протокол ethernet. Адресация MAC (6 байтные адреса, заголовок 14 байт, нет контрольной суммы)

V>Знаешь, что ты забыл упомянуть в плане Ethernet-протокола? Это самое главное: физические параметры ethernet-сигналов. Так что у кого тут каша в голове мы видим.

Я сказал про логический ethernet протокол. А физические, коих великая куча — это совершенно отдельная песня. Связи между ними — 0. Кроме одного слова в названии, являющимся скорее торговой маркой нежели уникальным техническим названием.


V>>>Это было согласие или возражение? И где, собственно, путаница? Говорилось только о том, что прикладные программы постоянно влезают на сетевой уровень.
А>>DNS это не сетевой уровень.

V>Ты только что написал, что адресация IP — это сетевой уровень.

Да. Адресация IP это сетевой уровень. DNS это просто база данных

V>Блин, мы что, используем DNS ради DNS?
Да. DNS используется ради красивых доменных имен.

V>Да мы туда лезем за определенной спецификой IP.
DNS лезет за определенной спецификой текстовой строчки под названием доменное имя. Специфика это включает в себя IP адрес. Связь тут односторонняя. Самим протоколам TCP/IP доменные имена не нужны. Они нужны только приложениям которые используют протоколы tcp/ip.

V>Мы сами лезем в подробности организации сетевого протокола только затем, чтобы установить, например, соединение однозначно транспортного уровня (TCP — соединение).
Короче что спорить, вы рассуждаете на уровне юзера или программиста .net сокетов, а я на уровне raw данных как они по сети идут. Вот список прикладных протоколов от wikidepia: http://en.wikipedia.org/wiki/Application_layer


V>>>И вообще, "намертво" завязаны на конкретный низкоуровневый протокол.
А>>DNS это прикладной уровень.
V>DNS — это необходимость приложению самостоятельно делать соответствия м/у прикладной и сетевой адресацией. В общем, ответы откровенно не в попад на мой вгляд, продолжать обсуждение скучно, мы о разных категориях говорим.
Причем тут ваш взгляд если согласно документации DNS — 7й уровеь OSI.


А>>UDP и TCP как _протоколы_ не привязаны к IP.

V>Серьезно? И подсчет чексумы по "виртуальному" IP-заголовку тоже не привязан к IP? RFC сам найдешь или подсказать? TCP неотделим от IP, вот в чем дело. Невозможно отделить содержимое TCP/UDP-пакетов от объемлющего IP-протокола. Более того, по такому понятию, как адресация портов, вообще получаем конфликт TCP и UDP. Там вообще каша.
Откуда каша? У UDP свои порты у TCP свои. Знаете портов вообще много бывает — есть еще аппаратные порты ввода/вывода. Тоже каша?

V>Ничто не мешает, например, на стороне сервера принимать tcp и udp пакеты на один и тот же порт — стандарт никак не запрещает.
А зачем запрещать? Может еще запретить принимать на порты номер которых совпадает с двумя старшими октетами ИП адреса? Тоже ведь циферки совпадают.

А>>К IP привязано стандартное API под названием берклиевские сокеты, которые принимают в одной структуре в качестве destination IP адрес, идентификатор транспортного протокола и его порт TCP/UDP порт. А что? Удобно.

V>Да пофиг какое конкретно АПИ. Хоть виндовое, которое содержит посиксное как под-АПИ. Суть не меняется. Прикладные программы намертво привязаны к сетевому протоколу.
Прикладные программы привязаны к АПИ. Что там за этим АПИ — хоть машинистка — их не интересует.

V>Сравни протокол named-pipes, мне уже скучно обсуждать, ибо твои ответы похожы на ответы глухого. Ты отвечаешь не на то, о чем речь.
Повторюь. Вы рассуждаете на уровне юзера или программиста .net сокетов, а я на уровне raw данных как они по сети идут.


А>>DNS как прикладной протокол базы данных читабельных альясов IP адресов понятное дело работает на TCP/UDP

V>Опять скатываемся на ликбез?
V>Ты бы лучше потратил время на описание заголовка стандартных посиксных адресов: "высокоуровневый_протокол://пользователь:пароль@домен/адрес_в_домене". Это нормальный такой прикладной адрес сеансового уровня.
СЕАНСОВОГО? Ну приехали, конечная...

[флейм поскипал.]

Здравствуйте, <Аноним>, Вы писали:


V>>Знаешь, что ты забыл упомянуть в плане Ethernet-протокола? Это самое главное: физические параметры ethernet-сигналов. Так что у кого тут каша в голове мы видим.
А>)
А>Я сказал про логический ethernet протокол. А физические, коих великая куча — это совершенно отдельная песня. Связи между ними — 0.

Боже, какая чушь... Как захватывается медиа в Ethernet? Как осуществляется контроль во время передачи? И никакой связи с логическим уровнем Ethernet? Как переводится аббревиатура MAC в конце концов? (Кстати, то, что этот адрес статический — это лишь конкретная подробность Ethernet-сообщества стандартов, этот адрес не обязан быть статическим или глобальным).


V>>Блин, мы что, используем DNS ради DNS?
А>Да. DNS используется ради красивых доменных имен.

А ну да... Прикладные приложения вообще могли бы по MAC-адресам работать... ню-ню...


V>>Да мы туда лезем за определенной спецификой IP.
А>DNS лезет за определенной спецификой текстовой строчки под названием доменное имя. Специфика это включает в себя IP адрес. Связь тут односторонняя. Самим протоколам TCP/IP доменные имена не нужны. Они нужны только приложениям которые используют протоколы tcp/ip.

Ты все правильно говоришь, но граблей в упор не видишь. Ну не нужны прикладным приложениям непонятные IP-адреса. Им нужны символические имена.


V>>Мы сами лезем в подробности организации сетевого протокола только затем, чтобы установить, например, соединение однозначно транспортного уровня (TCP — соединение).
А>Короче что спорить, вы рассуждаете на уровне юзера или программиста .net сокетов, а я на уровне raw данных как они по сети идут.

Заметно. По твоему программист-прикладник должен рассуждать так же? Де-факто, оно так и есть. Но это ненормальное положение вещей, ибо транспортный уровень, вообще-то, подразумевает что данные могут проходить через произвольное кол-во подсетей, где в каждой могут быть свои протоколы. А у нас прямо-таки транспортный уровень и все остальные завязаны на один конкретный сетевой протокол. Да возьми VPN. Нахрена он нужен, вот поясни нам, ты же любишь ликбезы устраивать. Вот и поясни, зачем нужен VPN? И попытайся найти этому кричащему костылю место в нормальной OSI-модели. На фик никакой VPN не нужен был бы. Это кривой и тормознутый костыль, не лучше NAT-а.


А>Причем тут ваш взгляд если согласно документации DNS — 7й уровеь OSI.

Досвидан сразу. Клоунов из себя строить в другом месте. В сотый раз повторяю, что прикладным программам, которые должны максимум обитать на транспортном уровне приходится заниматься тонкостями транспортного уровня. DNS — это инструмент для свершения этих бредовых действий. Если хочешь заостриться на DNS — ok, только в отдельной ветке. Там же обсудим динамические протоколы маршрутизации, ибо в случае с DNS надо понять, как так вышло, что доменные имена и высокоуровневые протоколы, на которые завязана безопасность, лежат совершенно сбоку от IP, и выглядят как очередном костыле в этой клинике под названием IP. Я вижу, что ты в упор не понимаешь, почему концевые хосты обязаны обращаться к DNS на каждый чих. По тебе это в норме вещей, хотя я считаю, что этими задачами должна заниматься сама среда передачи данных.


А>>>UDP и TCP как _протоколы_ не привязаны к IP.

V>>Серьезно? И подсчет чексумы по "виртуальному" IP-заголовку тоже не привязан к IP? RFC сам найдешь или подсказать? TCP неотделим от IP, вот в чем дело. Невозможно отделить содержимое TCP/UDP-пакетов от объемлющего IP-протокола. Более того, по такому понятию, как адресация портов, вообще получаем конфликт TCP и UDP. Там вообще каша.
А>Откуда каша? У UDP свои порты у TCP свои. Знаете портов вообще много бывает — есть еще аппаратные порты ввода/вывода. Тоже каша?

Аппаратные порты ввода-вывода — это ноги микросхем, при чем тут? Я не услышал вразумительного ответа насчет завязки TCP и UDP на IP. Обоснуй.


А>Прикладные программы привязаны к АПИ. Что там за этим АПИ — хоть машинистка — их не интересует.

АПИ разное бывает. Конкретно АПИ над IP выставляет все прелести IP на показ.


V>>Сравни протокол named-pipes, мне уже скучно обсуждать, ибо твои ответы похожы на ответы глухого. Ты отвечаешь не на то, о чем речь.
А>Повторюь. Вы рассуждаете на уровне юзера или программиста .net сокетов, а я на уровне raw данных как они по сети идут.

Досвидан еще раз, ибо обсуждается протокол. А протоколы они для прикладных целей нужны, в конечном итоге. На вершине любой экономической пирамиды стоит потребитель, а ему неважно как идут raw-данные. Де-факто под IP они идут хреново, особенно по набирающему популярность (естественно набирающему популярность!!!) VPN.


А>>>DNS как прикладной протокол базы данных читабельных альясов IP адресов понятное дело работает на TCP/UDP

V>>Опять скатываемся на ликбез?
V>>Ты бы лучше потратил время на описание заголовка стандартных посиксных адресов: "высокоуровневый_протокол://пользователь:пароль@домен/адрес_в_домене". Это нормальный такой прикладной адрес сеансового уровня.
А>СЕАНСОВОГО? Ну приехали, конечная...

Адрес? Разумеется сеансового. А ты думал имя юзверя и пароль нужны сырым IP-пакетам? Действительно конечная станция. В общем за сырыми IP-пакетами кому-то явно леса не видно.

таки отвечу на флейм который поскипал

V>Одноранговые сети microsoft могут работать без IP вообще, прямо через Ethernet.
Прямо таки через Ethernet? А может всетаки over IPX?
Впрочем я говорил про случай когда они работают over TCP/IP, но без DNS.


V>-----------
V>Кстати, любитель устраивать ликбез. Вот определения уровней, попытайся еще раз найти место Ethernet, ATM, IP и т.д.

V>Особенно рекомендую обратить внимание на описание ATM, а так же на такую хрень как ethernet on radio. Я вижу некие познания в области IP у тебя (и постоянные попытки поделиться этими познаниями с читателями ), но так же вижу отсутсвие банального технического кругозора. Как ты можешь участвовать в сравнении IP с другими протоколами, если у тебя недостаточно информации о других протоколах?

Отвечу понтами на понты
Я писал реализацию ETHERNET/TCP/UDP/IP, ARP. Реализовав псевдо-IP endpoint на "голом" winpcap. Мне при этом не понадобился DNS
И я непосредственно имею отношение к разработке файрволлов и VPN.
Радиолинки настраивал голыми руками в домашней сети
>Особенно рекомендую обратить внимание на описание ATM, а так же на такую хрень как ethernet on radio
>участвовать в сравнении IP с другими протоколами
Т.е. вы мне предлагаете сравнить "ethernet on radio" с IP ? Это же две совершенно разные вещи.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, <Аноним>, Вы писали:


V>>>Знаешь, что ты забыл упомянуть в плане Ethernet-протокола? Это самое главное: физические параметры ethernet-сигналов. Так что у кого тут каша в голове мы видим.
А>>)
А>>Я сказал про логический ethernet протокол. А физические, коих великая куча — это совершенно отдельная песня. Связи между ними — 0.

V>Боже, какая чушь... Как захватывается медиа в Ethernet? Как осуществляется контроль во время передачи? И никакой связи с логическим уровнем Ethernet? Как переводится аббревиатура MAC в конце концов? (Кстати, то, что этот адрес статический — это лишь конкретная подробность Ethernet-сообщества стандартов, этот адрес не обязан быть статическим или глобальным).

http://en.wikipedia.org/wiki/Ethernet
Ethernet is a large and diverse family of frame-based computer networking technologies for local area networks (LANs). The name comes from the physical concept of the ether. It defines a number of wiring and signaling standards for the physical layer, two means of network access at the Media Access Control (MAC)/Data Link Layer, and a common addressing format.
Итого: ethernet это множество стандартов. Часть описывает физические параметры оборудования, часть логическое взаимодействие. Так вот те первые — это физический уровень. Вторые — канальный.

Далее читаем http://en.wikipedia.org/wiki/OSI_model:

Layer 2: Data Link Layer
The Data Link layer provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the Physical layer. The best known example of this is Ethernet.
.....

Layer 1: Physical Layer
The Physical layer defines all the electrical and physical specifications for devices. This includes the layout of pins, voltages, and cable specifications. Hubs, repeaters, network adapters and Host Bus Adapters (HBAs used in Storage Area Networks) are physical-layer devices. The major functions and services performed by the physical layer are:
.....
Parallel SCSI buses operate in this layer. Various physical-layer Ethernet standards are also in this layer; Ethernet incorporates both this layer and the data-link layer. The same applies to other local-area networks, such as Token ring, FDDI, and IEEE 802.11.

Ну далее скатились на флейм. Кстати почему вы все время мне тыкаете?

Здравствуйте, <Аноним>, Вы писали:

Насчет понтов — аналогично участвовал в разработке стека IP для set top box. (теле-приставки)


>>Особенно рекомендую обратить внимание на описание ATM, а так же на такую хрень как ethernet on radio
>>участвовать в сравнении IP с другими протоколами
А>Т.е. вы мне предлагаете сравнить "ethernet on radio" с IP ? Это же две совершенно разные вещи.

Я обратил твое внимание на четкое разделение задач уровней и подуровней. В принципе, меня в IP раздражает только это — нечеткость уровней. Многие пакеты заворачиваются в IP-пакеты, но остаются на сетевом уровне. Что за бред? Почему код типа пакета не идет первым в потоке? Я именно и говорю, что IP близок к канальному уровню из-за фиксированного формата объемлющего IP-пакета. Кто придумал этот тупой "униформный" способ разметки пакетов, который требует ненужного лишнего заворачивания данных и лишних чексумов?

Здравствуйте, <Аноним>, Вы писали:


А>Итого: ethernet это множество стандартов. Часть описывает физические параметры оборудования, часть логическое взаимодействие. Так вот те первые — это физический уровень. Вторые — канальный.

Именно. А ты расположил его целиком на канальном, явно недопонимая ф-ии канального уровня. Понимаешь, канальный уровень одним своим концом по-любому упирается в физический. Поэтому классичесский канальный уровень по OSI разделен на 2 подуровня. Первый канальный подуровень обычно предназначен для взаимодейтсвия с физикой и потому часто целиком бывает "железячного" исполнения, второй уже можно реализовать программно (сейчас популярна реализация алгоритмов в ввиде сложных конечных автоматов на высокоинтегрированных микросхемах, ввиду требования к современному быстродействию)

А>

А>Layer 2: Data Link Layer
А>The Data Link layer provides the functional and procedural means to transfer data between network entities and to detect and possibly correct errors that may occur in the Physical layer. The best known example of this is Ethernet.
А>.....

А>Layer 1: Physical Layer
А>The Physical layer defines all the electrical and physical specifications for devices. This includes the layout of pins, voltages, and cable specifications. Hubs, repeaters, network adapters and Host Bus Adapters (HBAs used in Storage Area Networks) are physical-layer devices. The major functions and services performed by the physical layer are:
А>.....
А>Parallel SCSI buses operate in this layer. Various physical-layer Ethernet standards are also in this layer; Ethernet incorporates both this layer and the data-link layer. The same applies to other local-area networks, such as Token ring, FDDI, and IEEE 802.11.

Я так и понял, что свои выводы ты сделал из некоего "обзорного материала" по ethernet. Лучше было обратить внимание на классичесские ф-ции канального уровня. Популярные протоколы ethernet и ATM построены весьма грамотно, и идут по классической иерархии OSI. Из-за хорошего разделения ответственности, виртуализация каналов может производиться еще на канальном уровне, вот в чем прикол. Каналы вполне могут вкладываться друг в друга и даже в сетевой уровень — это важно. Я ведь не зря все время VPN-ом тыкаю, ибо виртуальный канал IP образуется совершенно не на том уровне ответственности. От того глючит и тормозит, а мог бы поддерживаться стандартной аппаратурой. Для справки, маршрутизаторы CISCO с поддержкой VPN стоят под десятку зелени... ха-ха, какой классный IP-протокол, все на нем зарабатывают, кроме юзверя.

В общем, на самом деле постоянно обсуждается возможность замены стека протокола IP альтернативами.
Чего люди хотят: упрощения аппаратной реализации, упрощения программной реализации (и даже перевод программной — в дешевую аппаратную), повышение гибкости, управление нагрузкой, отвязка высокоуровневых протоколов от подробностей сетевых стандартов и т.д.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, <Аноним>, Вы писали:


А>>Итого: ethernet это множество стандартов. Часть описывает физические параметры оборудования, часть логическое взаимодействие. Так вот те первые — это физический уровень. Вторые — канальный.

V>Именно. А ты расположил его целиком на канальном, явно недопонимая ф-ии канального уровня.
Цитирую сам себя же парой мессаг назад:

физический — сетевое оборудование, аппаратная архитектура (аппаратные стандарты ethernet 100, 10, F/O etc)
—
канальный — протокол ethernet. Адресация MAC (6 байтные адреса, заголовок 14 байт, нет контрольной суммы)

V>Понимаешь, канальный уровень одним своим концом по-любому упирается в физический. Поэтому классичесский канальный уровень по OSI разделен на 2 подуровня. Первый канальный подуровень обычно предназначен для взаимодейтсвия с физикой и потому часто целиком бывает "железячного" исполнения, второй уже можно реализовать программно (сейчас популярна реализация алгоритмов в ввиде сложных конечных автоматов на высокоинтегрированных микросхемах, ввиду требования к современному быстродействию)
Ладно хватит в терминологии ковырятся. Поговорим об идее OSI это конечно красиво, но практика показывает что прикладные программеры увы любят когда все объединяется в кучу и все может работать через одни и теже механизмы. Ибо я никак инче не могу объяснить ту же фишку с DNS — на в берклиевских сокетах резолвинг идет отдельной функцией, в более высокоуровневых АПИ и библиотеках работы с сетью все это объединяется в одно действие connect. В еще более всокоуровневые позволяют незаметно все это завернуть в какой нить SSL. Потому идея конкретного разделения хороша для четкого понимания и четкой реализации протокола, но плоха для реального применения в виде API для прикладного программиста. Опять же это не мое личное мнение это просто обобщение того что происходит в мире "само собой".

Здравствуйте, <Аноним>, Вы писали:


V>>Именно. А ты расположил его целиком на канальном, явно недопонимая ф-ии канального уровня.
А>Цитирую сам себя же парой мессаг назад:

А>

А>физический — сетевое оборудование, аппаратная архитектура (аппаратные стандарты ethernet 100, 10, F/O etc)
А>—
А>канальный — протокол ethernet. Адресация MAC (6 байтные адреса, заголовок 14 байт, нет контрольной суммы)

Да я понял, что ты откуда-то скопипейстил неграмотный пример относительно уровней OSI, в и-нете полно поверхностных обзоров, что к каким уровням относится. В физической части ethrnet подразумевает не только кабеля и их характеристики, но и источники/приемники сигнала, уровни и формы сигналов, способы кодирования сигналов. Ты что, думаешь по сети вот так прямо нули и единицы бегают из пакетов?


А>Ладно хватит в терминологии ковырятся. Поговорим об идее OSI это конечно красиво, но практика показывает что прикладные программеры увы любят когда все объединяется в кучу и все может работать через одни и теже механизмы. Ибо я никак инче не могу объяснить ту же фишку с DNS — на в берклиевских сокетах резолвинг идет отдельной функцией, в более высокоуровневых АПИ и библиотеках работы с сетью все это объединяется в одно действие connect.

Не знаю насчет "более высокоуровневых АПИ". Нет никаких стандартов. Либо ты сам оформляешь подключение через одну высокоуровневую ф-ию коннект, в которой все это делаешь, либо используешь стороннюю библиотеку. Без стандартов это все на уровне библиотеки барахтается. Получается, что ты завязываешься не на стандарты, а на библиотеки. Но тогда и обсуждать нечего, ибо берем паттерны типа Abstract Factory, и генерим коннекшены как попало, скрещивая хоть ужа с ежом. Однако это не спасает, если встает, например, требование перейти на другой сетевой протокол. Иногда подмена прикладных библиотек по множеству причин невозможна, да и вообще, для C++ этот код чаще всего оказывается скомпиллированным в бинарник прикладной программы из статической либы. Если бы это все было на уровне компонентов OS, было бы проще — пропатчил OS, а все прикладные программы как работали, так и работают, не заметив подмены протокола.


В общем, как я это себе вижу (грубо):
1. Идем с самого верху. Оставляем наработки сеансовых адресов, вроде "протокол://юзер:пароль@домен/адрес_объекта_в_домене"
2. по сути, для высокоуровневых приложений оставляем только такую вещь как символьный домен, т.е. в транспортный уровень для установления связи непосредственно передаем имя домена (никак не сетевой адрес)
3. транспортный уровень превращает символический адрес в сетевой адрес. Как это происходит никакие прикладные библиотеки знать не должны, чтобы иметь возможность при развитии системы сетевых адресов не трогать имеющиеся приложения. (т.е. необходимо сделать возможным процесс развития хотя бы адресации сети, а этот аспект однозначно развивать придется всегда и постоянно)
4. было бы неплохо, чтобы сетевой уровень оперировал только лишь номерами сетей. Саму адресацию сетей сделать адаптивной, например, закодировать номер сети четырмя байтами (современные потребности), если старший бит адреса равен 1, то считаем его 0-м и рассматриваем следущие 4 байта как продолжение адреса сети, в этих 4-х байтах так участвует только 31 бит, а старший — биит признака и т.д. Необязательно сделать кратной 4-м, или закодировать только таким образом. Можно, например, один байт отвести под значащую длину адреса. Важна суть — длина адреса не должна быть фиксированной в разметке пакета. (а про маски сетей вообще забыть как о страшном сне)
5. нафига сетевому уровню номера хостов? Пусть в качестве конечной точки выступает канальный адрес хоста в данной сетке (MAC-адрес). Таким образом получаем требование, чтобы длина адреса канального уровня тоже не фиксировалась в пакетах транспортного уровня.

В системе, где прикладное приложение использует лишь символьное имя домена, не нужны навороты типа нескольких IP-адресов на одном ethernet-соединении, т.е. нет надобности генерировать избыточный и фиксированный номер хоста, мы и так имеем его в рамках сети. Так же надо уходить от понятия виртуальной сети, завязанной на конкретные адреса сетевого уровня. Надо юзать что-то вроде концепции "рабочей группы", т.е. логической именованной сети, которая никак не пересекается с адресами сетевого уровня, ибо задача сетевого уровня — в тупой маршрутизации пакетов. Подобная "рабочая группа", т.е. логическая сеть, была бы прямой заменой VPN.

6. Формат посылки сетевого уровня должен начинаться с кода типа пакета (достаточно короткого однобайтового поля). Вовсе не всегда нужны полные адреса приемника и получателя, иногда достаточно адреса сети или наоборот, достаточен адрес хоста в сети. Иногда нужен лишь один адрес одного из end-point-ов. Пакеты сетевого уровня не должны заворачиваться один в другого как в IP. Достаточно просто разметить поток данных произвольным, вернее, наиболее удобным для кодирования и дальшейшего развития способом. (Ведь за передачу пакета как единицы информации отвечает канальный уровень).

7. Такую хрень как номер порта — выкинуть на хрен. Согласно приведенной схемы адресации достаточно "адрес_объекта_в_домене". Номер конкретного транспортного соединения пусть будет динамическим, пускай его отслеживает транспортный уровень, эта информация не должна быть доступна юзеру.

В общем, вот грубо набор св-в стека протоколов, который позволит развиваться всем сетевым уровням, независимо от прикладного кода. Сейчас де-факто возможности даже просто перейти на IPv6 нет, и еще долго не будет. Будут выжимать из NAT все что можно, а потом будет болезненное расставание с любимыми программами, написанными для IPv4.

Отписался от уведомлений к бененой маме! Флуд один рсдновский... Как всегда.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

Здравствуйте, vdimas, Вы писали:

V>Досвидан сразу. Клоунов из себя строить в другом месте.

Здравствуйте, BlackTigerAP, Вы писали:

BTA>Отписался от уведомлений к бененой маме! Флуд один рсдновский... Как всегда.

Выражать свое ве публично совсем не обязательно. Оно никому не интересно.

Здравствуйте, Nevidim, Вы писали:

N>Вот собственно сабж. Написать новый транспортный протокол.

Сначала определи что тебя не устраивает в TCP?
TCP очень не плох как транспортный протокол общего назначения. Можно предложить решение лучше, но только применительно к конкретному классу задач.

Здравствуйте, WoldemaR, Вы писали:

WR>Через 5 лет появляются первые сетевые устройства поддерживающие эти протоколы.

Устройства поддерживающие транспортные протоколы?

WR>А вообще то, похоже что так оно сейчас и происходит.
WR>WiFi, Bluetooth и прочие на чём основанны?

Все это очень низкий уровень по сравнению с TCP.

Здравствуйте, Nevidim, Вы писали:

N>TCP морально и физически устарел.
N>Взять хотя бы безопасность, использование в мобильных устройствах и т.д. и т.п.

Можно подробнее? В чем его опасность? Может в том, что его используют не по назначению?

N>Судя по высказываниям большинство поддерживает данную точку зрения. Дело за малым,
N>взяться и уничтожить его в ближайшие годы

Ага. ip6 уже лет 5 внедряют. Окончательно он внедриться дай Бог лет через 10-20.
Но ip6 — сетевой уровень он прикладных приложений почти не касается. С TCP все намного сложнее.

Здравствуйте, vdimas, Вы писали:
V>Упссс... Тогда обсуждать нечего, ибо по-твоему эти уровни были выбраны совершенно случайно. На самом деле было взято МИНИМАЛЬНОЕ кол-во уровней, обеспечивающих низкую связанность или даже полное отсутствие связанности протоколов разных уровней. В IP получилось по наихудшему варианту.
Именно что случайно. Просто в комитете было 7 групп. Если бы их было 4, то OSI получилась бы значительно компактнее. А TCP/IP разрабатывался практиками, что и обеспечило ему успех.

IMHO:Интересно то, что прямо на поставленный вопрос никто отвечать не возжелал, а только развели базар на тему "кому это нужно, что тебе не нравится?" вместо того, чтобы помочь...

---

Данное сообщение получено с сайта www.gotdotnet.ru

Здравствуйте, Nevidim, Вы писали:


N>Вот собственно сабж. Написать новый транспортный протокол.
Скажите пожалуйста, а зачем Вам это нужно?

Чем не хватает TCP и UDP?
Честно говоря не вижу в этом большого смысла.

всем привет.
как динозавры подвисли на TCP/UDP.
неужели про SCTP никто не знает?

Здравствуйте, Nevidim, Вы писали:

N>Вот собственно сабж. Написать новый транспортный протокол.

Почитал я тут обсуждение. И не увидел мыслей про будущий протокол. И не увидел поиска МЕГА-КВАЛИФИЦИРОВАННЫХ соучастников.
У меня есть такой вопрос:

А ты способен написать хотя бы свою полнокровную реализацию tcp/ip?
Ну так, чтобы под тобой например ethernet пакеты, а над тобой — сокеты.

Hint: такая реализация имхо будет в любом случае проще чем что-то идеальное по OSI.

Дело в том, что я пробовал. И не раз. (мне надо было встроить какой-нибудь потоковый протокол в приложение с уровня ethernet)
И я отлично (как мне казалось) знал как работает tcp/ip в деталях.
С каждым разом я прорубался дальше и лучше, но осилить ПОЛНУЮ И ХОРОШУЮ реализацию так и не смог.
Даже такая примитивная связка как tcp-ip (с точки зрения OSI) является весьма сложной на самом деле.
Кроме простейших понятий о заголовках и типичных случаях передачи инфы есть ещё куча разных алгоритмов, улучшающих
тот или иной аспект работы tcp/ip.

Действительно ли ты знаешь как работает TCP/IP??
Hint: назови хотя бы 2-3 алгоритма, используемых в tcp-ip для разного рода оптимизаций.

Если да, то от меня — мега уважуха и совет искать не абы кого, а таких же считанных спецов по сетевым протоколам.
Иначе ваш корабль утонет, т.к. никто не будет знать как приплыть хотя бы к tcp/ip.

Здравствуйте, vdimas, Вы писали:

V>Хоть я не автор, но мне конкретно не нравится IP и UDP поверх которого TCP живет.

TCP живет не поверх UDP, а поверх IP.

V> А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.

Напротив, это очень мудрая идея. Порты (отправителя и получателя) занимают в пакете всего 4 байта. Если бы там были, не знаю, имена, процентов 10% траффика съедалось бы только под них (пакеты не такие уж и большие). Причем ничего не мешает аллоцировать порты динамически, и договариваться сторонам о конкретных номерах портов, если хочется иметь не номера, а имена. Это должно делаться на более высоком уровне, чем собственно транспортный уровень.

V> Ну собственно, чего ожидать, если IP-семейство и близко не придерживается модели OSI... От того так сильно зависят друг от друга, и из-за этой взаимной зависимости с таким скрипом развиваются.

Развиваются они быстрее и успешнее любого другого семейства протоколов. Может, как раз от того, что не придерживаются модели OSI?

V>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.

У NAT'а есть много других проблем, но вот именно та проблема, о которой Вы говорите, является чисто умозрительной. В природе такого не случается.

Кстати, прежде, чем критиковать TCP/IP, Вам бы стоило для начала научиться их (TCP и IP) между собой не путать.

V>Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли?

Вообще-то, она допускает "корректирование", ее не обязательно пересчитывать целиком. И уж совсем не понятно, зачем пересчитывать ее 6 раз.

V>А эти RFC по вкладыванию IP в другие протолы — как гимн кривой архитектуре. Ибо, если бы IP-семейство соответсвовало 7-миуровневой модели OSI, то этой тонны дополнительных стандартов можно было бы избежать.

Хоть в 20-уровневой, все равно, информация, содержащаяся в этих RFC, должна быть где-то написана.

Здравствуйте, Ovl, Вы писали:

Ovl>сравнивать модель tcp и osi некорректно, ибо они суть одно и тоже, только в osi — 7 уровней, а в tcp — ну 4 примерно

На самом деле, не совсем. ICMP не очень ложится в простую модель, где каждый слой строится над предыдущими. С одной стороны, ICMP использует IP в качестве транспорта, и в этом смысле параллелен TCP и UDP. С другой — он слишком тесно дружит с IP, чтобы считать его слоем над IP.

Забавно при этом, что строго по модели OSI ни одного живого семейства сетевых протоколов так и не было реализованно. Видимо, не все, что хорошо смотрится на бумажке, столь же хорошо работает в жизни.

Здравствуйте, vdimas, Вы писали:

V>Еще раз для тех, кто в танке. Речь о том, что во-первых, многие IP-протоколы "намертво" завязаны друг на друга, от чего и существуют объективные трудности в развитии протоколов (т.е. по уровню связанности дизайну основных IP-протоколов можно ставить двойку), во-вторых, прикладные сетевые программы, использующие IP, так же намертво привязаны именно к этому протоколу, по той же самой причине — отсутствия четкого деления на уровни. Пример с DNS и АПИ осей относительно IP — это лишь наглядная демонстрация, к какому бреду приводит некачественная архитектура сетевых протоколов.

Вы можете привести пример конкретной проблемы, которая не дает TCP/IP развиваться именно по причине чрезмерной связанности?

Вообще, если честно, Вы производите впечатление студента, которому на прошлой неделе рассказали про 7-уровневую модель OSI, и он проникся. В TCP/IP есть масса реальных проблем, но про них Вы, видимо, не в курсе, и цепляетесь к совершенно воображаемым проблемам. Тем не менее, из всего множества практически реализованный сетевых протоколов семейство TCP/IP по-видимому самое удачное. О чем, в частности, свидетельствует его живучесть.

Здравствуйте, Аноним, Вы писали:

А>всем привет.
А>как динозавры подвисли на TCP/UDP.
А>неужели про SCTP никто не знает?

Ну, во-первых, его ещё нет в винде (AFAIK). Во-вторых — я бы не сказал, что он чем-то глобально лучше и полезнее.

Здравствуйте, vdimas, Вы писали:

V>Хоть я не автор, но мне конкретно не нравится IP и UDP поверх которого TCP живет. А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.

Ну и в чём тут ограничения? (кроме количества бит на порт — 16 действительно мало для больших нагрузок)

V>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.

Это где Вы такую странную реализацию NAT нашли??? Или речь про дефрагментацию перед трансляцией? Ну так во-1) TCP обычно сочетается с DF и PMTUD (вот уж где костыль), так что дефрагментация крайне редка, во-2) там не только id учитьывается.

V>Кстати, берем банальное туннелирование. Сколько раз при передаче пакета просчитывается его контрольная сумма на каждом приемнике/передатчике? Раз шесть? Ну не смешно ли? :xz:

С чего это шесть раз??? По-моему, Вас совсем не туда потянуло. Обычно — только два раза (контроль на приёме и генерация на передаче), только для внешнего заголовка.

V>А эти RFC по вкладыванию IP в другие протолы — как гимн кривой архитектуре. Ибо, если бы IP-семейство соответсвовало 7-миуровневой модели OSI, то этой тонны дополнительных стандартов можно было бы избежать.

Чушь и воронятина (tm). Ну-ка, расскажите, как в строгой модели OSI мне сделать PPP поверх SSH (зачем — ну вот надо было, получать интернет в крайне тяжёлых условиях). А никак — там идея туннелирования отсутствует как класс.

И "несоответствие" TCP/IP модели OSI имеет массу преимуществ. Например, BGP — управляет 3-м уровнем, а в реализации формально можно найти даже 7-й. В OSI надо было бы вместо аккуратной слойки IP — TCP — BGP изобретать локальный велосипед (что и делается).

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Аноним, Вы писали:

А>>всем привет.
А>>как динозавры подвисли на TCP/UDP.
А>>неужели про SCTP никто не знает?

N>Ну, во-первых, его ещё нет в винде (AFAIK).

Есть, кажется, юзерландная реализация в виде библиотеки.

N> Во-вторых — я бы не сказал, что он чем-то глобально лучше и полезнее.

Есть там полезных вещей:
1) multistreaming с общим на все потоки flow and congestion control, но независимой ретрансмиссией
2) multihoming — load sharing'а нет, но есть failover, что уже хорошо.
3) message oriented — удобно
4) мелкая, но важная, приятность — отсутствие TIME_WAIT, как класса
5) расширяемость за счет структурированности на chunks, которые представляют собой TLV тройки; реакция на неизвестные типы chunk'ов программируется старшим битом типа: дропнуть и перейти к следующему chunk'у в пакете, дропнуть с ошибкой в ответ и перейти к следуюшейму чанку, дропнуть и перейти к следующему пакету, дропнуть с ошибкой и перейти к следующему пакету.
7) возможна partial reliability — при посылке сообщения можно указать время его жизни, и, если сообщение не было ack'нуто в течение этого времени, отправитель не будет его (или его куски) ретрансмитить, а пошлет вместо этого skip.

Ну и еще всякое, которое я на память не перечислю.

Здравствуйте, netch80, Вы писали:

Нетч, что за идея откопать эту стюардессу? Я от этого треда еще полтора года назад плакал. Вот теперь всплакнул еще раз.

V>>А реализация NAT для TCP — технология которая доказанно теоретически работает с ошибками (ибо склеивает сообщения по номеру, но этот номер теоретически случайно может совпасть у сообщений двух абонентов внутренней сети), т.е. технология работает не благодаря продуманности, а скорее вопреки... За счет "авось" и дополнительных вычислений контрольных сумм.

N>Это где Вы такую странную реализацию NAT нашли??? Или речь про дефрагментацию перед трансляцией? Ну так во-1) TCP обычно сочетается с DF и PMTUD (вот уж где костыль), так что дефрагментация крайне редка, во-2) там не только id учитьывается.

Очевидно, там учитывается не только id. Но неправильная сборка фрагментов — реальность, к сожалению. Конечно, к NAT'у это не имеет непосредственного отношения, но файрволы, рандомизирующие id, и NAT (вернее PAT) способны увеличить вероятность такой проблемы.

Здравствуйте, Изя Рнет, Вы писали:

ИР>Здравствуйте, netch80, Вы писали:

ИР>Нетч, что за идея откопать эту стюардессу? Я от этого треда еще полтора года назад плакал. Вот теперь всплакнул еще раз.

Это не я. Я шёл по вчерашнему MainList.aspx и смотрел интересные заголовки. А некрофилией занялся кто-то из моих предшественников.
Когда заметил старые даты — остановился.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, Изя Рнет, Вы писали:

ИР>>Здравствуйте, netch80, Вы писали:

ИР>>Нетч, что за идея откопать эту стюардессу? Я от этого треда еще полтора года назад плакал. Вот теперь всплакнул еще раз.

N>Это не я. Я шёл по вчерашнему MainList.aspx и смотрел интересные заголовки. А некрофилией занялся кто-то из моих предшественников.
N>Когда заметил старые даты — остановился.

А. Сорри тогда за наезд.

Впрочем, можем продолжить за SCTP, например. Вдруг что-то интересное удастся обсудить, а не OSIRM, не к ночи будь помянута.

Здравствуйте, netch80, Вы писали:


N>Чушь и воронятина (tm). Ну-ка, расскажите, как в строгой модели OSI мне сделать PPP поверх SSH (зачем — ну вот надо было, получать интернет в крайне тяжёлых условиях). А никак — там идея туннелирования отсутствует как класс.

Туннелирование — это костыль сам по себе, связан с отсутствием "родного" способа построения виртуальных сетей в IP. Более подробно в этой ветке я уже объяснял. Шифрование потока данных — отдельная тема, просто в свалили в одну выгребную яму всё подряд. Я уже делал замечание, что безопасность сейчас завязана на ИМЕНА хостов, в то время как протоколы работают по номерам хостов (IP-адресам). VPN — это классическая выгребная яма, где перемешалось всё, с целью построения костыля для достижения банального, с т.з. OSI сценария работы.

N>И "несоответствие" TCP/IP модели OSI имеет массу преимуществ. Например, BGP — управляет 3-м уровнем, а в реализации формально можно найти даже 7-й. В OSI надо было бы вместо аккуратной слойки IP — TCP — BGP изобретать локальный велосипед (что и делается).

Чушь. 7-ми уровневая архитектура — это просто 7 ролей. Реально вкладывать каналы один в другого можно практически как угодно, т.к. вышестоящим элементам однофигственно, как реализованы нижестоящие. Пример ATM — это просто классика, где уже давно всё изобретено и даны ответы на многие вопросы (далеко не все, но очень многие). Если бы разработчики IP хотя бы малость поизучали другие протоколы, прежде чем лепить своё, то такого результата можно было бы избежать.

Здравствуйте, vdimas, Вы писали:

V>Чушь. 7-ми уровневая архитектура — это просто 7 ролей. Реально вкладывать каналы один в другого можно практически как угодно, т.к. вышестоящим элементам однофигственно, как реализованы нижестоящие. Пример ATM — это просто классика, где уже давно всё изобретено и даны ответы на многие вопросы (далеко не все, но очень многие). Если бы разработчики IP хотя бы малость поизучали другие протоколы, прежде чем лепить своё, то такого результата можно было бы избежать.
Ну то есть за два года, прошедших с этого спора, ты так ничему и не научился. Похвально.

Здравствуйте, Pzz, Вы писали:

V>> А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.
Pzz>Напротив, это очень мудрая идея. Порты (отправителя и получателя) занимают в пакете всего 4 байта. Если бы там были, не знаю, имена, процентов 10% траффика съедалось бы только под них (пакеты не такие уж и большие).
Фигня вопрос.
Можно легко сделать так чтобы с одной стороны колличество портов было не ограничено, а с другой стороны в подавляющем большинстве случаев ограничиться теми же 4мя байтами.
Просто берем старший бит очередных 2х байт и смотрим если 0 то номер порта закончился. Если 1 то смотрим следующие 2 байта.
Один черт порты с номерами больше 32767 используют редко.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Pzz, Вы писали:

V>>> А кривая сущность под названием UDP- и TCP- порт — вообще верх безграмотности проектирования протокола. Это же надо было заложить столько ограничений прямо в базе.
Pzz>>Напротив, это очень мудрая идея. Порты (отправителя и получателя) занимают в пакете всего 4 байта. Если бы там были, не знаю, имена, процентов 10% траффика съедалось бы только под них (пакеты не такие уж и большие).
WH>Фигня вопрос.
WH>Можно легко сделать так чтобы с одной стороны колличество портов было не ограничено, а с другой стороны в подавляющем большинстве случаев ограничиться теми же 4мя байтами.
WH>Просто берем старший бит очередных 2х байт и смотрим если 0 то номер порта закончился. Если 1 то смотрим следующие 2 байта.
WH>Один черт порты с номерами больше 32767 используют редко.

Порты с номерами больше 32767 используют как раз весьма часто: в юниксах есть стандартный приём использования в разных целях разных диапазонов, и даже не заказывая явно номер порта можно запросить, в каком диапазоне он будет выдан. Например, нижний — 600-1023 (предназначен для автоаллокации, когда клиент явно хочет указать наличие у него прав суперпользователя — используется в ряде протоколов), lдефолтный — 1024-5000, верхний — 49152-65535. По умолчанию, например, для современных FreeBSD автовыдача идёт именно из верхнего диапазона.

$ sysctl -a | grep portrange
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 600
net.inet.ip.portrange.first: 49152
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49152
net.inet.ip.portrange.hilast: 65535
net.inet.ip.portrange.reservedhigh: 1023
net.inet.ip.portrange.reservedlow: 0
net.inet.ip.portrange.randomized: 1
net.inet.ip.portrange.randomcps: 10
net.inet.ip.portrange.randomtime: 45

С другой стороны, применений, где 16 бит недостаточно — на сейчас мало, в основном это сверхзагруженные сервера на протоколах со спецификой, где нельзя со стороны сервера использовать один и тот же порт (даже навскидку не скажу, какие это протоколы, кроме разве что голосовых потоков VoIP). Видимо, их настолько мало, что для SCTP предпочли сохранять совместимость с 16-битным sockaddr_in::sin_port, чем ломать её.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, netch80, Вы писали:


N>>Чушь и воронятина (tm). Ну-ка, расскажите, как в строгой модели OSI мне сделать PPP поверх SSH (зачем — ну вот надо было, получать интернет в крайне тяжёлых условиях). А никак — там идея туннелирования отсутствует как класс.

V>Туннелирование — это костыль сам по себе, связан с отсутствием "родного" способа построения виртуальных сетей в IP.

Родных средств там достаточно, но туннелирование — не только IP. Например, оно может связывать на уровне Ethernet (L2) два broadcast segment в один, я знаю, где это построили потому что нужно. Туннелировать можно RS-232 или даже USB. По которому опять побежит что-то другое. Туннелирование есть на L2 (L2TP, QinQ, а главное — MPLS во всех его видах и разновидностях). В общем, весь мир давно за туннелирование, только vdimas почему-то думает, что он один шагает в ногу.

V> Более подробно в этой ветке я уже объяснял. Шифрование потока данных — отдельная тема, просто в свалили в одну выгребную яму всё подряд. Я уже делал замечание, что безопасность сейчас завязана на ИМЕНА хостов, в то время как протоколы работают по номерам хостов (IP-адресам).

Ну вот и хорошо — будет 10 фронтэндов одного сайта с одним именем с общим сертификатом, но на разных IP. В чём проблема-то?

V> VPN — это классическая выгребная яма, где перемешалось всё, с целью построения костыля для достижения банального, с т.з. OSI сценария работы.

Расскажите, как именно "банально" с точки зрения OSI мне связать (пусть, предположим, везде OSI протоколы) две сети на разных континентах в один broadcast segment, как будто между ними стоит просто свич. Прошу сразу детали реализации, а не общие слова.

N>>И "несоответствие" TCP/IP модели OSI имеет массу преимуществ. Например, BGP — управляет 3-м уровнем, а в реализации формально можно найти даже 7-й. В OSI надо было бы вместо аккуратной слойки IP — TCP — BGP изобретать локальный велосипед (что и делается).

V>Чушь. 7-ми уровневая архитектура — это просто 7 ролей.

То-то многие протоколы, как SMTP, предусматривают роли одновременно нескольких уровней OSI.

V> Реально вкладывать каналы один в другого можно практически как угодно, т.к. вышестоящим элементам однофигственно, как реализованы нижестоящие.

Ну вот в случае IP оно тоже "однофигственно" — по крайней мере при соблюдении базовых условий (если реализация претендует на роль L2, она не должна заниматься надёжностью доставки кадров; и ещё несколько подобных условий).

V> Пример ATM — это просто классика, где уже давно всё изобретено и даны ответы на многие вопросы (далеко не все, но очень многие).

Главный вопрос, который они ответили — как реализовать компромисс так, чтобы было плохо обеим сторонам. Это я про размер ячейки.

V> Если бы разработчики IP хотя бы малость поизучали другие протоколы, прежде чем лепить своё, то такого результата можно было бы избежать.

Разработчики IP как раз избежали.

Здравствуйте, netch80, Вы писали:

N>Порты с номерами больше 32767 используют как раз весьма часто: в юниксах есть стандартный приём использования в разных целях разных диапазонов, и даже не заказывая явно номер порта можно запросить, в каком диапазоне он будет выдан. Например, нижний — 600-1023 (предназначен для автоаллокации, когда клиент явно хочет указать наличие у него прав суперпользователя — используется в ряде протоколов), lдефолтный — 1024-5000, верхний — 49152-65535. По умолчанию, например, для современных FreeBSD автовыдача идёт именно из верхнего диапазона.
Тогда бы просто значения для диапозонов были бы другие и все.
В худшем случае было бы не 4 байта, а 6. Что много потеряли если бы размер пакета увиличился бы на 2 байта?

В любом случае я ничего менять не предлогаю.
Просто рассуждаю на тему сферопротокола в вакууме.

И если рассуждать до конца то ИМХО порты вобще нужно отправить в топку.
Достаточно просто сделать адреса иерархическими с копрессией как я расказал.
Тогда скажем город получил бы адрес типа 12452.643132
Домовая сеть или там датацентр 12452.643132.435734, комп в сети 12452.643132.435734.545632, программа на компе 12452.643132.435734.545632.46232
Ну были бы сейчас адреса не 6 байт, а 10-12. Много бы потеряли?
За то при такой схеме проблемы из серии кончились адреса небыло бы никогда. Ибо эти адреса масштабируются на любом уровне.

Здравствуйте, Nevidim, Вы писали:

N>Вот собственно сабж. Написать новый транспортный протокол.
А зачем? Есть, например, http://en.wikipedia.org/wiki/SCTP — там решены множество проблем TCP. И SCTP уже прекрасно поддерживается Линуксом и кучей других операционок.

Вообще, мне лично в TCP больше всего не нравится отсутствие нормальной системы коррекции ошибок. При потере одного пакета — приходится перепосылать все уже отправленые пакеты.

Остальное... Ну в общем, мелочи жизни.

Здравствуйте, netch80, Вы писали:

N>С другой стороны, применений, где 16 бит недостаточно — на сейчас мало, в основном это сверхзагруженные сервера на протоколах со спецификой, где нельзя со стороны сервера использовать один и тот же порт (даже навскидку не скажу, какие это протоколы, кроме разве что голосовых потоков VoIP).

Действительно, таких ситуаций не много. В реальности на это можно наступить, когда одна и та же машина открывает много соединений к другой — при этом из 5-tuple 4 поля фиксированы. Например, http proxy в позе фронтэнда ходит к http серверу. Если учесть, что соединения будут отлеживаться в TIME_WAIT, то 65К соединений может и не хватить.

N>Видимо, их настолько мало, что для SCTP предпочли сохранять совместимость с 16-битным sockaddr_in::sin_port, чем ломать её.

SCTP эту проблему обходит иначе: во-первых, много SCTP associations (это то, к чему относятся порты) между парой машин особого смысла не имеют, поскольку внутри ассоциаций есть стримы, а во-вторых, у SCTP нет TIME_WAIT и похожих явлений.

Здравствуйте, Cyberax, Вы писали:

C>Вообще, мне лично в TCP больше всего не нравится отсутствие нормальной системы коррекции ошибок. При потере одного пакета — приходится перепосылать все уже отправленые пакеты.

Что за волшебное средство отбрасывает на пятнадцать лет назад?

2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S.
Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes
RFC1072) (Status: PROPOSED STANDARD)

Сейчас сложно найти стек, где его не поддерживают.

C>Остальное... Ну в общем, мелочи жизни.

Ну не совсем мелочи.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, netch80, Вы писали:

N>>Порты с номерами больше 32767 используют как раз весьма часто: в юниксах есть стандартный приём использования в разных целях разных диапазонов, и даже не заказывая явно номер порта можно запросить, в каком диапазоне он будет выдан. Например, нижний — 600-1023 (предназначен для автоаллокации, когда клиент явно хочет указать наличие у него прав суперпользователя — используется в ряде протоколов), lдефолтный — 1024-5000, верхний — 49152-65535. По умолчанию, например, для современных FreeBSD автовыдача идёт именно из верхнего диапазона.
WH>Тогда бы просто значения для диапозонов были бы другие и все.
WH>В худшем случае было бы не 4 байта, а 6. Что много потеряли если бы размер пакета увиличился бы на 2 байта?

Да ничего. Я лично за 32-битную статику. И 128-битные sequence numbers. Затрат на них немного, а пользы — дофига.

WH>В любом случае я ничего менять не предлогаю.
WH>Просто рассуждаю на тему сферопротокола в вакууме.

WH>И если рассуждать до конца то ИМХО порты вобще нужно отправить в топку.
WH>Достаточно просто сделать адреса иерархическими с копрессией как я расказал.
WH>Тогда скажем город получил бы адрес типа 12452.643132
WH>Домовая сеть или там датацентр 12452.643132.435734, комп в сети 12452.643132.435734.545632, программа на компе 12452.643132.435734.545632.46232
WH>Ну были бы сейчас адреса не 6 байт, а 10-12. Много бы потеряли?

Известная тема. Идеи про переменную длину адреса витают уже пятьдесят лет (и, кстати, про OSI — в X.25 она таки переменная). Это даже в IPv6 применили — см. routing header — но как почти всё там, через пятую точку. Надо было не 128-битные части переставлять, а 32-битные, и не фиксировать их распределение — тогда действительно получились бы адреса переменной длины. Интернет мог бы спокойно работать с тем, что видно на его глобальном уровне — или 32, или 64, в зависимости от вкусовщины — а локальные сети спокойно бы себе строили дополнительные уровни, если им это нужно, не грузя глобальные сети.

Однако — вместо этого "имеем то, что имеем".

Здравствуйте, netch80, Вы писали:

N>

N>2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S.
N> Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes
N> RFC1072) (Status: PROPOSED STANDARD)

N>Сейчас сложно найти стек, где его не поддерживают.
А вот я такой стек нашёл

Буду дописывать.

C>>Остальное... Ну в общем, мелочи жизни.
N>Ну не совсем мелочи.
Учитывая, что сейчас больше всего популярен HTTP с ещё большими глюками — мелочи

Здравствуйте, Cyberax, Вы писали:

N>>Вот собственно сабж. Написать новый транспортный протокол.
C>А зачем? Есть, например, http://en.wikipedia.org/wiki/SCTP — там решены множество проблем TCP. И SCTP уже прекрасно поддерживается Линуксом и кучей других операционок.

Не совсем осилил сочетание двух характеристик этого протокола:
1) Connection oriented — Yes
2) Preserve message boundary — Yes

Зачем на принимающей стороне знать какими частями передающая сторона посылала данные? Этак и ответы на вопросы типа "не могу принять пакет по TCP" перестанут взывать гневные отповеди "пакетов нет!". Или я неправильно понял термин?

И до кучи: а зачем может понадобиться "Unordered delivery", которая тоже "Yes".

Здравствуйте, McQwerty, Вы писали:

MQ>Зачем на принимающей стороне знать какими частями передающая сторона посылала данные? Этак и ответы на вопросы типа "не могу принять пакет по TCP" перестанут взывать гневные отповеди "пакетов нет!". Или я неправильно понял термин?

Потому что часто прикладному протоколу нужна передача сообщений, а не потока байтов. Если использовать TCP, то приходится самому мучаться с передачей границ сообщений. А SCTP берет эту заботу на себя.

MQ>И до кучи: а зачем может понадобиться "Unordered delivery", которая тоже "Yes".

На случай, если принимать данные в порядке поступления важнее, чем ждать, пока они все придут в правильном порядке.

Здравствуйте, Sinclair, Вы писали:

S>Ну то есть за два года, прошедших с этого спора, ты так ничему и не научился. Похвально.

Не сдержался. Просто пример с туннелированием — самый удивительный в этом топике, в том плане, что этот костыль в IP, нагляднее всего демонстрирующий недостатки системы адресации, снова и снова настойчиво предъявляют как аргумент в пользу того же IP, не понимая, видимо, принципов организации виртуальных сетей как таковых.

Здравствуйте, netch80, Вы писали:


N>Расскажите, как именно "банально" с точки зрения OSI мне связать (пусть, предположим, везде OSI протоколы) две сети на разных континентах в один broadcast segment, как будто между ними стоит просто свич. Прошу сразу детали реализации, а не общие слова.

Это все делается "родным" способом для OSI, т.к. существует отдельное понятие логической сети/подсети. Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

Так же напомню, что адреса в пакетах могут быть произвольной длины, адреса сетей/подсетей используются отдельно от адресов хостов, соотвественно, существуют посылки уровня сети/подсети, твой broadcast. Прикол в том, что сетевой уровень понятия не имеет, broadcast сообщение или нет, он просто доставит пакет в сеть/подсеть, а интерпретацией содержимого займется уже транспортный уровень, на котором и станет понятно, что данный пакет — broadcast.

В принципе, вот здесь

Автор: vdimas
Дата: 01.11.06

я обобщил все свои отдельные высказывания (где-то с середины поста).

Здравствуйте, vdimas, Вы писали:

Я повторю вслед за netch'ем: чушь и воронятина.


V>Здравствуйте, netch80, Вы писали:

N>>Расскажите, как именно "банально" с точки зрения OSI мне связать (пусть, предположим, везде OSI протоколы) две сети на разных континентах в один broadcast segment, как будто между ними стоит просто свич. Прошу сразу детали реализации, а не общие слова.

V>Это все делается "родным" способом для OSI, т.к. существует отдельное понятие логической сети/подсети.

Понятие существует, да. Которое описывает определенные функции. Так вот, должно быть нечто, что выполнит эти функции через "OSI-интернет" для двух сетей на разных континентах. Поэтому надо либо сделать либо реальный subnetwork, либо виртуальный, что и означает туннелирование в конечном итоге.

V> Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

Что это каша? IDRP выполяет функции распространения маршрутной информации между маршрутизационными доменами. Т.е. речь об общей subnetwork, расположенной в двух доменах тут речи не идет.

Кстати, домашнее задание для OSI/ISO-фанатов: выяснить как инкапсулируются BISPDU и с помощью сложных теологических рассуждений доказать, что IDRP не нарушает священную модель OSI, в то время как BGP — это вероотступничество.

Здравствуйте, Изя Рнет, Вы писали:


ИР>Понятие существует, да. Которое описывает определенные функции. Так вот, должно быть нечто, что выполнит эти функции через "OSI-интернет" для двух сетей на разных континентах. Поэтому надо либо сделать либо реальный subnetwork, либо виртуальный, что и означает туннелирование в конечном итоге.

Этим "нечто" является ПО по организации логических подсетей. Логическая подсеть и так всегда виртуальна (совпадение с физической подсеткой может быть случайным ), почему я и говорю, что аналог туннелирования заложен в OSI-модель изначально.


V>> Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

ИР>Что это каша? IDRP выполяет функции распространения маршрутной информации между маршрутизационными доменами.

Естественно, иначе как связать физических участников, расположенных в различных маршрутизационных областях или доменах в логическую подсеть.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Изя Рнет, Вы писали:


ИР>>Понятие существует, да. Которое описывает определенные функции. Так вот, должно быть нечто, что выполнит эти функции через "OSI-интернет" для двух сетей на разных континентах. Поэтому надо либо сделать либо реальный subnetwork, либо виртуальный, что и означает туннелирование в конечном итоге.

V>Этим "нечто" является ПО по организации логических подсетей. Логическая подсеть и так всегда виртуальна (совпадение с физической подсеткой может быть случайным ), почему я и говорю, что аналог туннелирования заложен в OSI-модель изначально.

Туннелирование "заложено" во все что угодно. Ничто, подчеркиваю, ничто, не мешает трактовать payload любого протокола, как PDU любого другого протокола. Ничто, кроме глупой схоластики про Священные Уровни.

На самом деле, конечно, это все растет от некоторого непонимания, что OSIRM — она про функции и интерфейсы между ними, а не про пакетную инкапсуляцию, а инкапсуляция, совпадающая с уровнями OSI — это иногда так, а иногда не так. Есть это понимать, то все противоречия снимаются, но заодно и исчезает всякая польза от самой модели.

V>>> Каждое ES может участвовать в произвольном кол-ве подсетей. На нижнем уровне в твоем примере будет работать IDRP, это ISO-аналог BGP/IP. Для транспортного уровня посмотри ISO протоколы TP2, TP3, TP4.

ИР>>Что это каша? IDRP выполяет функции распространения маршрутной информации между маршрутизационными доменами.

V>Естественно, иначе как связать физических участников, расположенных в различных маршрутизационных областях или доменах в логическую подсеть.

Ну да.

И чего? Где итог? Где неоспоримое доказательство преимуществ OSI-стека над IP-стеком в деле организации VPN?

Здравствуйте, Изя Рнет, Вы писали:


ИР>И чего? Где итог? Где неоспоримое доказательство преимуществ OSI-стека над IP-стеком в деле организации VPN?

IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
— фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата
— ограниченная система адресации.
— мало того, что ограниченная, так еще и избыточная, в том смысле, что на сетевом уровне требуется только номер сети.
— приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.
— в итоге невозможно развивать сам протокол и систему адресации, не рискуя сделать неработоспособными ВСЕ приложения, использующие IP, т.е. вариант "просто пропатчить OS до новой версии протокола" не прокатит. В ближайшие 5-10 лет будет очччень болезненный переход на IPv6.

Если читать топик с начала, то основная критика была именно из-за сильной связанности как самого семейства протоколов, так и зависимости приложений от этого протокола. Собственно, разработчики модели OSI утверждают, что модель разрабатывалась именно с целью ослабления связей м/у уровнями. Такое положение вещей позволяет в модели OSI прозрачно вкладывать транспортные и сетевые протоколы друг в друга (да хоть стократное туннелирование). Для сравнения, IP VPN живёт только в IP-сетях, ибо полностью ограничивается спецификой IP-протокола, начиная от формата пакета и далее по списку, что было уже перечисленно.

Здравствуйте, vdimas, Вы писали:

V> Для сравнения, IP VPN живёт только в IP-сетях, ибо полностью ограничивается спецификой IP-протокола, начиная от формата пакета и далее по списку, что было уже перечисленно.

Ай, ай. L2TP, PPPoE, наверно, мне и миллионам использующих их пользователей приснились, потому что "IP VPN живёт только в IP-сетях".

V>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

А что, любая должна использовать все?
Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

V>- ограниченная система адресации.
V>- мало того, что ограниченная, так еще и избыточная, в том смысле, что на сетевом уровне требуется только номер сети.

Когда IPv4 вводился, 32 бита было типичным машинным словом реального компьютера (не мини/микро), и эта избыточность уже никого не волновала. Сейчас шинные передачи по 64-128 байт — норма процессоростроения, 16 байт адреса IPv6 по сравнению с этим — меньше чиха. Ну не мелочится никто за такими крохами.

V>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.

Приложения уже давно отвязаны, кто хотел. API независимое от размера адреса и прочих деталей уже 10 лет как стабилизировалось.

V>- в итоге невозможно развивать сам протокол и систему адресации, не рискуя сделать неработоспособными ВСЕ приложения, использующие IP, т.е. вариант "просто пропатчить OS до новой версии протокола" не прокатит. В ближайшие 5-10 лет будет очччень болезненный переход на IPv6.

Это вина не авторов протоколов, а тех, кто живёт в 80-х годах и не хочет писать по-новому. Я не верю в приложение, которое само работает с сетью и за 10 лет не развивалось ни разу.

V>Если читать топик с начала, то основная критика была именно из-за сильной связанности как самого семейства протоколов, так и зависимости приложений от этого протокола. Собственно, разработчики модели OSI утверждают, что модель разрабатывалась именно с целью ослабления связей м/у уровнями. Такое положение вещей позволяет в модели OSI прозрачно вкладывать транспортные и сетевые протоколы друг в друга (да хоть стократное туннелирование).

90% приложений хотят чтобы отрабатывался URL и был потоковый сокет. Всё остальное — проблемы ОС.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Изя Рнет, Вы писали:

ИР>>И чего? Где итог? Где неоспоримое доказательство преимуществ OSI-стека над IP-стеком в деле организации VPN?

V>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

В этом есть маленький плюс: можно полагаться, что IS-IS и ES-IS пакеты (NLPID 0x83, 0x82) не придут к нам из-за роутера — от этого произрастает некоторая [довольно сомнительная] секурность. И большие минусы: из-за отдельного формата заголовка возникает совершенно глупая пляска с IIH трех (!) типов в IS-IS, и невозможно сложные и ненадежные процедуры area partition repair в том же IS-IS — нет ни одной реализации, которая поддерживала бы partition repair. И это очень обидно, поскольку IS-IS — единственная грамотно спроектированная часть OSI-стека (поэтому и дожившая до наших дней).

V>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.

Это вопрос к API, а не к протоколу.

V>- в итоге невозможно развивать сам протокол и систему адресации, не рискуя сделать неработоспособными ВСЕ приложения, использующие IP, т.е. вариант "просто пропатчить OS до новой версии протокола" не прокатит. В ближайшие 5-10 лет будет очччень болезненный переход на IPv6.

Будет. Болезненный. Не в последнюю очередь из-за приложений, к которым IPv4 прибит гвоздями. Но и не в первую.

V>Если читать топик с начала, то основная критика была именно из-за сильной связанности как самого семейства протоколов, так и зависимости приложений от этого протокола. Собственно, разработчики модели OSI утверждают, что модель разрабатывалась именно с целью ослабления связей м/у уровнями.

Доослаблялись. OSI-модель и OSI-стек, как воплощение этой модели — яркий пример оверинжиниринга кроме маленького куска всего стека, где ISO-шная амбивалентность пришлась ко двору.

V>Такое положение вещей позволяет в модели OSI прозрачно вкладывать транспортные и сетевые протоколы друг в друга (да хоть стократное туннелирование).

Это везде так.

V>Для сравнения, IP VPN живёт только в IP-сетях

Ась?

А, ну да, конечно. Поскольку не-IP сетей в жизни [почти] не осталось, то IP VPN живет только в IP-сетях. В этом смысле да, правда. А вообще ахинея.

Здравствуйте, netch80, Вы писали:


V>>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

N>А что, любая должна использовать все?
N>Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

Антинаучная ерунда. Есть такие вещи — конечные цифровые автоматы. Простые цифровые автоматы (а требуются очень простые для парсинга PDU большинства современных протоколов, особенно семейства IP) способны работать на тактовых частотах до нескольких гигагерц (до десяти и выше), и еще учтём, что автомат оперирует как минимум байтами, а не битами. Ну и самое главное — конечному автомату глубоко плевать на схожесть различных PDU, просто чем разнообразнее PDU, тем больше "несклеиваемых" конечных состояний автомата. В общем, экономию на лишней десятке состояний трудно считать за аргумент.


N>90% приложений хотят чтобы отрабатывался URL и был потоковый сокет. Всё остальное — проблемы ОС.

Именно, об этом говорил неоднократно в этом топике.

Здравствуйте, Изя Рнет, Вы писали:

ИР>Доослаблялись. OSI-модель и OSI-стек, как воплощение этой модели — яркий пример оверинжиниринга кроме маленького куска всего стека, где ISO-шная амбивалентность пришлась ко двору.

Какого именно куска? Например, физический и канальный, разбиение канального уровня на два слоя с разными ролями, их связь и типичные сценарии взаимодействия — это классика, которой отвечают практически все современные канальные протоколы (Ethernet, Token Ring, FDDI, LLC, X.25, ISDN).

Сетевой уровень самый сложный, абстрактный и т.д. Но это, ИМХО, от того, что IP стал популярнее, и другие альтернативы лишились как внимания, так и банального бабла. Напомню, что первые RFC относительно семейства IP были тоже не ахти (мягко сказано).

Тем не менее, в стек от OSI медленно, но верно вкладывают бабло:

Этот стек протоколов поддерживает правительство США в своей программе GOSIP. Все компьютерные сети, устанавливаемые в правительственных учреждениях после 1990 года, должны либо непосредственно поддерживать стек OSI, либо обеспечивать средства для перехода на этот стек в будущем. Тем не менее, стек OSI более популярен в Европе, а не в США, так как в Европе меньше установлено старых сетей, использующих свои собственные протоколы.

Здравствуйте, vdimas, Вы писали:

N>>А что, любая должна использовать все?
N>>Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

V>Антинаучная ерунда. Есть такие вещи — конечные цифровые автоматы. Простые цифровые автоматы (а требуются очень простые для парсинга PDU большинства современных протоколов, особенно семейства IP) способны работать на тактовых частотах до нескольких гигагерц (до десяти и выше), и еще учтём, что автомат оперирует как минимум байтами, а не битами. Ну и самое главное — конечному автомату глубоко плевать на схожесть различных PDU, просто чем разнообразнее PDU, тем больше "несклеиваемых" конечных состояний автомата. В общем, экономию на лишней десятке состояний трудно считать за аргумент.

Вы это циске расскажите. Которая рассказывает на своей практике то же, что я — что любые подобные автоматы недопустимо усложняют построение маршрутизаторов.

Или покажите от другого производителя маршрутизатор той же производительностью и ценою хотя бы в две цискиных.

N>>90% приложений хотят чтобы отрабатывался URL и был потоковый сокет. Всё остальное — проблемы ОС.
V>Именно, об этом говорил неоднократно в этом топике.

Вот только не надо изображать это так, будто я подтверждаю Вашу точку зрения.:)

Интересно то, что прямо на поставленный вопрос никто отвечать не возжелал, а только развели базар на тему "кому это нужно, что тебе не нравится?" вместо того, чтобы помочь...

По причине бесперспективности . Даже если сделать, никто кроме энтузиастов пользоваться не будет. Я тут недавно с сетевыми протоколами плотно работал, похожая задача стояла. Альтернатив TCP — сотни. И заточенные под десятигигабитки, и под минимальное время отклика, и под... много вообщем. Мало кто ими пользуется.

Покопался в реализации TCP во FreeBSD. Почитал мануали. Разобрал несколько open-source протоколов. Сделал несколько своих моделей. Там, вообщем, не все так просто . Много математики, нюансов работы уже существующих сетей которые надо учитывать, нюансы взаимодействия с ethernet под операционной системой...

Над этим институты годами бьются, и успехов пока не ахти. Смысл 'по фану' этим заниматься?

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Изя Рнет, Вы писали:

ИР>>Доослаблялись. OSI-модель и OSI-стек, как воплощение этой модели — яркий пример оверинжиниринга кроме маленького куска всего стека, где ISO-шная амбивалентность пришлась ко двору.

V>Какого именно куска?

Протокола IS-IS. Который до сегодняшнего дня жив, здоров и широко используется для маршрутизации IP.

V>Сетевой уровень самый сложный, абстрактный и т.д. Но это, ИМХО, от того, что IP стал популярнее, и другие альтернативы лишились как внимания, так и банального бабла. Напомню, что первые RFC относительно семейства IP были тоже не ахти (мягко сказано).

IP стал популярней потому что решал конкретные проблемы, а не реализовывал абстракции, придуманные full time заседателями комитетов по стандартизации.

V>Тем не менее, в стек от OSI медленно, но верно вкладывают бабло:
V>

V>Этот стек протоколов поддерживает правительство США в своей программе GOSIP. Все компьютерные сети, устанавливаемые в правительственных учреждениях после 1990 года, должны либо непосредственно поддерживать стек OSI, либо обеспечивать средства для перехода на этот стек в будущем. Тем не менее, стек OSI более популярен в Европе, а не в США, так как в Европе меньше установлено старых сетей, использующих свои собственные протоколы.

Хи-хи-хи. Вы б еще выкопали нормативный документ 19-го века о дизайне котлов паровозов.

Действительно GOSIP был, формально не отменен, но на него все забили болт и то же самое правительство США замечательно покупает и использует оборудование, которое кроме IP ничего другого не умеет.

Единственное место, где в реальной жизни можно встретить OSI-стек в полном его воплощении (с CLNP, TP*, CMIP и прочими радостями жизни) — это внутренний OAM SDH-сетей некоторых производителей. Да и то, это все переходит на IP, а где еще нет, там просто туннелируется через IP-сети.

Всё. OSI-стек RIP. И к жизни никогда не возвратится. Реализаций, которые могли бы его роутить хоть на каких-нибудь приемлимых на сегодня скоростях не существует. И уже не появится.

А сама модель так и останется моделью сферического коня в вакууме.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, netch80, Вы писали:


V>>>IP стек был критикован здесь не только и не столько за VPN, просто странно, что VPN преподносится как мега-достижение. IP-протокол ругают за:
V>>>- фиксированный формат пакетов (в той же OSI различают ES-ES, ES-SI, SI-SI,...), многие управляющие посылки IP не используют все поля своего формата

N>>А что, любая должна использовать все?
N>>Фиксированный формат — это как раз огромный плюс. Потому что позволяет предельно упростить железную реализацию логики: там, где при фиксированном формате известно, что адрес получателя на смещении N (и пакет ещё только укладываясь в буфер вызывает лукапы в таблицах), при нефиксированном процессор только-только начинает думать, а где же тут искать адрес. И так же с другими полями. Передача на таких скоростях, как для IP сейчас типично (десятки гигабит в секунду — реальность, сотни — ближайшая перспектива) для протокола нефиксированного формата невозможна.

V>Антинаучная ерунда. Есть такие вещи — конечные цифровые автоматы. Простые цифровые автоматы (а требуются очень простые для парсинга PDU большинства современных протоколов, особенно семейства IP) способны работать на тактовых частотах до нескольких гигагерц (до десяти и выше), и еще учтём, что автомат оперирует как минимум байтами, а не битами. Ну и самое главное — конечному автомату глубоко плевать на схожесть различных PDU, просто чем разнообразнее PDU, тем больше "несклеиваемых" конечных состояний автомата. В общем, экономию на лишней десятке состояний трудно считать за аргумент.

Поскольку речь шла именно о форматах ISO-стека, то в данном конкретном случае я соглашусь. Там всего три типа пакета:
ES-IS, IS-IS и CLNP, которые различаются по первому байту. ES-IS и IS-IS — контрольные и поэтому однозначно отправляются заинтересованному процессу. В форвардинговый путь идет только CLNP, а у него адрес начинается с фиксированного смещения. Поэтому в данном случае много типов пакетов и, соответственно, заголовков — само по себе не проблема.

Проблема в самом NSAP адресе. В лучших традициях design by committee он очень гибкий, переменной длины, все его части переменной длины. Без знания (и реализации в роутере!) конкретных правил назначения адресов во всех частях адресного пространства иерархический роутинг просто невозможен. Поэтому все конкретные реализации наложили определенные ограничения на формат адреса и его составных частей.

Здравствуйте, Изя Рнет, Вы писали:

V>>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.
ИР>Это вопрос к API, а не к протоколу.

То есть, на самом деле c IP-протоколами всё в порядке, а всё дело испортили подлые разработчики клиентских API?

Здравствуйте, eugals, Вы писали:

E>Здравствуйте, Изя Рнет, Вы писали:

V>>>- приложения, использующие IP-протоколы очень жёстко завязаны на особенности не только транспортного уровня, но и сетевого.
ИР>>Это вопрос к API, а не к протоколу.

E>То есть, на самом деле c IP-протоколами всё в порядке, а всё дело испортили подлые разработчики клиентских API?

С IP в порядке не все. Но данная проблема — это проблема API, а не протокольного стека.

Здравствуйте, <Аноним>, Вы писали:

E>>То есть, на самом деле c IP-протоколами всё в порядке, а всё дело испортили подлые разработчики клиентских API?

А>С IP в порядке не все. Но данная проблема — это проблема API, а не протокольного стека.
А нельзя ли было её решить уже при проектировании стека протоколов, чтобы у API-писателей просто не было ни одного шанса создать проблемы будущему развитию этих протоколов?