Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Вот сеня услышал что в этом протоке есть какое подтверждение, доставил он инфу или нет. В чем она заключается и в чем ее отличие от TCP подтверждения?
TCP — это виртуальный канал, который существует на все время связи.
Там подтверждения необходимы организации достоверности передачи.
UDP — дейтаграммный протокол и недостоверен.
Подтвержденние нужно для особо опасных случаев, что бы не изобратать снова.
Здравствуйте, old->*Plutonia_Experiment(), Вы писали:
O>TCP — это виртуальный канал, который существует на все время связи. O>Там подтверждения необходимы организации достоверности передачи.
Как тут происходит алгоритм подтверждения
O>UDP — дейтаграммный протокол и недостоверен. O>Подтвержденние нужно для особо опасных случаев, что бы не изобратать снова.
В TCP все просто — обратно отсылаются квитанции принятых пакетов (в виде номер следующего ожидаемого байта данных, насколько я помню). Из чего делается вывод, какие пакеты в текущем окне не доползли до получателя. Точнее, там несколько сложнее, это все можно и нужно почитать на http://www.soslan.ru/tcp/ либо на http://ed.rk.tusur.ru/doc/TcpIp/ (soslan в последнее время подтормаживает).
O>>UDP — дейтаграммный протокол и недостоверен. O>>Подтвержденние нужно для особо опасных случаев, что бы не изобратать снова.
MS>И как тут
В UDP подтверждения доставки нет и быть не может. Есть один ньюанс. Если хост-получатель не создал слушающего сокета на UDP порту, а туда посылается пакет, то обычно система посылает отправителю ICMP уведомление о том, что такого порта нет (ICMP Port Unreachable Error). Хотя на нормальных реализациях стека IP можно настроить реакции системы в таких случаях.
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Вот сеня услышал что в этом протоке есть какое подтверждение, доставил он инфу или нет. В чем она заключается и в чем ее отличие от TCP подтверждения?
протокол UDP определен рекомендацией RFC 768, в которой говорится "UDP does not recover from lost data through retransmission". есть случай, когда по коммутируемому соединению "точка-точка" проводится попытка передать дейтаграмму, но принимающий конец отвалился — winsock выдаст ошибку WSAESHUTDOWN, WSAECONNRESET и т.п.
AS>В UDP подтверждения доставки нет и быть не может. Есть один ньюанс. Если хост-получатель не создал слушающего сокета на UDP порту, а туда посылается пакет, то обычно система посылает отправителю ICMP уведомление о том, что такого порта нет (ICMP Port Unreachable Error). Хотя на нормальных реализациях стека IP можно настроить реакции системы в таких случаях.
Подтверждение часто есть в дейтаграммных протоколах для экстремальных ситуаций.
Точно также в протоколах с виртуальным каналом часто есть способ отправки дейтаграммы.
В UDP itself подтверждения нет. И быть не может. Читаем RFC 768.
The protocol is transaction oriented, and delivery and duplicate protection
are not guaranteed. Applications requiring ordered reliable delivery of
streams of data should use the Transmission Control Protocol (TCP)
Там есть исключительные ситуации — когда порт на получателе отсутствует либо ошибка при формировании/получении пакета. Все это оговаривается в RFC на ICMP, его и надо читать. Кроме той ситуации, которую я уже описывал, еще есть ICMP собщение "требуется фрагментация". Собственно, кажется это почти все, что может указать нам о том, что UDP пакет не доставлен. Однако. Повторюсь. Нормальные реализации IP стека _позволяют_ прописать реакцию системы/маршрутизатора не посылать подобных ICMP откликов. Это первое соображение. Второе — ICMP относится к сетевому уровню, тогда как UDP — к транспортному. Вкупе с первым соображением — подобные отклики никак нельзя считать свойством протокола UDP.
Да, подтверждения о доставке есть во многих протоколах, использующих в качестве транспорта UDP (например, та же icq98 и TFTP), однако все это делается "ручками". Т.о. — UDP — протокол с негарантированной доставкой сообщений.
Единственное свойство UDP, которое хоть как то можно считать полезным (это глубоко мое мнение) — простой мультикаст.
Собственно, вопрос был о том, есть ли в UDP механизм подтверждения доставки. Ответ — нет.
O> O>Подтверждение часто есть в дейтаграммных протоколах для экстремальных ситуаций. O>Точно также в протоколах с виртуальным каналом часто есть способ отправки дейтаграммы.
UDP — протокол _без_ установления соединения и более того — не точка-точка. В нем есть мультикаст. Поэтому принимающий конец тут "отвалиться" не может. Может быть ошибка при фрагментации пакета либо ошибка отсутствия порта. Всё. Но они не входят в сам UDP — это ICMP сообщения. И второе — у меня довольно сильные сомнения, что send, положим, возвратит ошибку при отправке на несуществующий порт. Точнее, уверенность, что не возвратит. Я так сам делаю в реализации traceroute. Т.о. для того, чтобы отловить такую ситуацию — надо принимать ICMP сообщения, что и делается в traceroute. А это требует raw сокетов и админа под NT-2000. И пользуясь только UDP сокетом никак не узнать на уровне UDP, получил ли удаленный хост наше послание.
SCS>есть случай, когда по коммутируемому соединению "точка-точка" проводится попытка передать дейтаграмму, но принимающий конец отвалился — winsock выдаст ошибку WSAESHUTDOWN, WSAECONNRESET и т.п.
Это все применимо к TCP.
Здравствуйте, Andrew S, Вы писали: AS>UDP — протокол _без_ установления соединения и более того — не точка-точка. В нем есть мультикаст. Поэтому принимающий конец тут "отвалиться" не может. Может быть ошибка при фрагментации пакета либо ошибка отсутствия порта. Всё.
помимо broadcast и multicast всегда есть возможность послать unicast дейтагамму( ), т.е. когда ip:port получателя определены однозначно — "точка-точка" — вот в этом случае и возможна сигнализация ICMP.а вот в первых двух случаях — этого нет.
Точка-точка подразумевает соединение. Тут его нет. Поэтому ни о какой точке-точке речи и быть не может. Тут похоже point-to-any. Точка-точка — это TCP. Далее. Как я уже говорил, для отлова ICMP сообщения об ошибке приходится применять совсем другие средства, чем UDP сокет. На нем же это _никак_ не сказывается. Удаленную систему легко настроить так, чтобы не слать ICMP сообщения вообще. Так что про них можно и нужно в данном случае забыть. Их нет
К сожалению — мы _вынуждены_ полагаться в данном случае на удачу, а также на "ручную" реализацию механизма подтверждения (как в TFTP), которая заведомо хуже того же TCP. (например, тот же TFTP настолько криво сделан, что различные реализации просто не работают друг с другом...).
SCS>помимо broadcast и multicast всегда есть возможность послать unicast дейтагамму( ), т.е. когда ip:port получателя определены однозначно — "точка-точка" — вот в этом случае и возможна сигнализация ICMP.а вот в первых двух случаях — этого нет.
Здравствуйте, Andrew S, Вы писали:
AS>И второе — у меня довольно сильные сомнения, что send, положим, возвратит ошибку при отправке на несуществующий порт. Точнее, уверенность, что не возвратит.
В Win2K это обрабатывается, вернее вот так — If sending a datagram using the sendto function results in an "ICMP port unreachable" response and the select function is set for readfds, the program returns 1 and the subsequent call to the recvfrom function does not work with a WSAECONNRESET (10054) error response. In Microsoft Windows NT 4.0, this situation causes the select function to block or time out.
Угу. А по-другому это называется неопределенное поведение
S>В Win2K это обрабатывается, вернее вот так — If sending a datagram using the sendto function results in an "ICMP port unreachable" response and the select function is set for readfds, the program returns 1 and the subsequent call to the recvfrom function does not work with a WSAECONNRESET (10054) error response. In Microsoft Windows NT 4.0, this situation causes the select function to block or time out.
Кстати, поведение NT в этом случае явно более правильное (мое мнение). Тут же нет виртуального канала, поэтому удаленная сторона может открывать/закрывать порт по своему желанию. Отражаться на нашем сокете это явно не должно.
Например, мы послали датаграмму на удаленный хост и ждем ответа. В это время удаленный хост в дауне. Под NT все будет ОК — мы будем ждать ответа. И получим его, когда удаленый хост поднимется и разошлет всем датаграммы о том, что он был в дауне (броадкастом). А под 2k мы вывалимся из ожидания с обломленым сокетом и необходимостью пересоздать потоки приема и ожидания наново... Нда, молодцы MS, интерсно, как Berkeley стандарт смотрит на это. Все реализации трайсроута, что я видел, спокойно ждут приема select'ом, либо recvfrom, не боясь за свой рассудок.
Где бы почитать на эту тему (MSDN не предлагать )
S>В Win2K это обрабатывается, вернее вот так — If sending a datagram using the sendto function results in an "ICMP port unreachable" response and the select function is set for readfds, the program returns 1 and the subsequent call to the recvfrom function does not work with a WSAECONNRESET (10054) error response. In Microsoft Windows NT 4.0, this situation causes the select function to block or time out.
Здравствуйте, MikaRSDN Soukhov, Вы писали:
MS>Вот сеня услышал что в этом протоке есть какое подтверждение, доставил он инфу или нет. В чем она заключается и в чем ее отличие от TCP подтверждения?
MS>Заранее благодарю
Первый раз слышу, чтоб UDP что-нибудь подтверждал...
Зачем нужен второй TCP?
), т.е. когда ip:port получателя определены однозначно — "точка-точка" — вот в этом случае и возможна сигнализация ICMP.а вот в первых двух случаях — этого нет.
