Здравствуйте, 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, должна быть где-то написана.