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-протокола.