Отправлено kolobok0 25 января 2006 г. 15:02 В ответ на: скажите, UDP обеспечивает последовательность доставки инфы? отправлено ы 25 января 2006 г. 13:29

UDP - гарантирует передачу пакетов юзверя...
TCP - гарантирует ПОСЛЕДОВАТЕЛЬНУЮ доставку (по принципу поинт-понит) инфы в две стороны.
IP - гарантирует сборку пакетов, разбитых на маршруте следования (естественно если все фрагменты им получены).

TCP не только содержит счётчики. Он содержит команды управления, счётчики, информацию о кадре и вспомогательные поля типа CRC, время жизни и прочее. Данный протокол решает такие проблемы как:
затор, потерю, выбор скорости общения, разрешение конфликтных и прочих ситуаций.

Думаю, для тех кто заинтересуется глыбже - найдут соответствующие документы по данным стандартам.

Если инфа "стреляеться" на UDP уровне - то Вы должны быть готовыми, что инфа в принцепе могёт и не прийти. Как правило проблемы конкретно начинают ощущаться при прохождении пакетом сегмента с интенсивным обменом, либо не исправными(не настроенными) сетевыми ресурсами. Приблизительно понять как будет это выглядеть - может помочь команда ping. Она обеспечиваеться протоколом ICMP (функция эхо-ответа) распологающегося над IP. Кол-во успехов или не успехов она выводит в трэйс. Поставте интересующий Вас размер для тестовых данных - и Вы почуствуете разницу :) шучу. Почуствуете, точнее воспримите пример прохождения Вашими данными того или иного участка сети...

удачи Вам
(круглый)

• Я с — scorpion   (25.01.2006 15:11 83.237.20.84, 138 байт)
  • Дело в том, что TCP работает НЕ ПАКЕТАМИ, а ПОТОКОМ !! прошу не путать ! (-) — kolobok0   (25.01.2006 16:03 195.208.79.250, пустое)
    • Имееться ввиду срез TCP-User. По сетке бегают пакеты ессесвенно. Но данная РЕАЛИЗАЦИЯ скрыта в самом протоколе.(-) — kolobok0   (25.01.2006 16:07 195.208.79.250, пустое)
  • В TCP если один фрагмент не пришел, он будет запрашивать его до опупения, даже не смотря на то что пришло 10 следующих. Это по идее и есть гарантия последовательности. — bp   (25.01.2006 15:20 81.3.189.234, пустое)
    • Апсалютно верно. Более того, передатчик ДОЛЖЕН (по протоколу TCP) ПРЕКРАТИТЬ передачу, когда размер окна достигнет предела (в случаи НЕ подтверждения).Это ессесвенно маленькая часть механизации TCP... — kolobok0   (25.01.2006 16:10 195.208.79.250, пустое)
    • Совсем нет - ведь предыдущие уже приняты. — scorpion   (25.01.2006 15:31 83.237.20.84, пустое)
      • Вопрос...Вы знаете ИЛИ ПРЕДПОЛОГАЕТЕ ? Если знаете - прошу дать ссылку на документ...(-) — kolobok0   (25.01.2006 16:05 195.208.79.250, пустое)
      • и куда он их денет? пользователю передавать не имеет право без этого потерявшегося, только когда получит последний фрагмент или все фрагменты сразу в случае переповтора передатчиком — ы   (25.01.2006 15:36 80.92.98.211, пустое)
        • Зависит от — scorpion   (25.01.2006 16:16 83.237.20.84, 212 байт)
          • ну приемник и похерит, и ничего подтверждать не будет, потом передающая сторона перешлет начиная с первого неподтвержденного пакета, вот и получится и гарантия доставки, и гарантия последовательности — радиолюбитель без лицензии   (25.01.2006 16:31 62.64.81.146, пустое)
            • Да, это — scorpion   (25.01.2006 17:17 83.237.20.84, 613 байт)
        • Никуда. Он, после заполнения окна приёма будет отбрасывать все пакеты за исключением необходимого и командных. При этом отвечать будет командами с размером приёмного фрэйма в нуле ! смотрите доки народ...ё-моё чаво же просче ? — kolobok0   (25.01.2006 16:12 195.208.79.250, пустое)
          • спокойствие. это не было собвственно вопросом для меня. я знаю что он их не денет никуда. про механизмы TCP я немного знаю потому что он основан на HDLC или в паралелль делался. а там есть кадрик SREJ (дай мне тот единственный из 10 в окне ) так что все путем. — ы   (25.01.2006 16:17 80.92.98.211, пустое)
            • сорьки...(-) — kolobok0   (25.01.2006 17:03 195.208.79.250, пустое)

E-mail: info@telesys.ru