Насколько я понимаю в TCP/IP встроен механизм отбрасывания дублированых пакетов, т.е. имеем ситуацию:

1) клиент отправил пакет на сервер
2) сервер получил пакет
3) сервер отправил клиенту подтверждение на пакет, но подтверждение не дошло
4) клиент отправил тот же пакет на сервер еще раз

Пакет будет отброшен. Я правильно понимаю?

Просто имею какую то необъяснимую ситуацию. Такое впечатление что пакет все таки приходит дважды. С задержкой примерно в 0.3-0.4 сек. Возможно ли что при каких либо обстоятельствах TCP/IP пакет придет дважды?

Поможет ли введение своей нумерации пакетов? Думается что раз такая нумерация уже есть в TCP то введение своей ситуацию не исправит... Или можно уверенно сказать что дублирования пакетов быть не может потому что не может быть никогда и идти править руки?

C>Насколько я понимаю в TCP/IP встроен механизм отбрасывания дублированых пакетов, т.е. имеем ситуацию:
...
C>Пакет будет отброшен. Я правильно понимаю?
Если вы используете существующую реализацию TCP/IP (типа виндовых или юниксовых сокетов) — то забудьте такое слово "пакет"
Если вы пишете свою имплементацию TCP/IP — она у вас явно кривая)

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

C>Насколько я понимаю в TCP/IP встроен механизм отбрасывания дублированых пакетов, т.е. имеем ситуацию:

C>1) клиент отправил пакет на сервер
C>2) сервер получил пакет
C>3) сервер отправил клиенту подтверждение на пакет, но подтверждение не дошло
C>4) клиент отправил тот же пакет на сервер еще раз

C>Пакет будет отброшен. Я правильно понимаю?

Слово "пакет" здесь неуместно. Здесь Вам не UDP и даже не SCTP (как реализация seqpacket).
Пакеты действительно есть. Но не на TCP. А на IP уровне. TCP payload сообщает "передаю данные начиная с позиции X". И если придёт снова такое же, а приёмная сторона ждёт уже позицию X+N, то данные из того пакета не будут отданы в программу. Но это не "отброшен", могут быть другие действия (например, перепосылка ACK).

C>Просто имею какую то необъяснимую ситуацию. Такое впечатление что пакет все таки приходит дважды. С задержкой примерно в 0.3-0.4 сек. Возможно ли что при каких либо обстоятельствах TCP/IP пакет придет дважды?

Как Вы это определили? Одни и те же данные в потоке видите дважды? Или что-то иное?

C>Поможет ли введение своей нумерации пакетов?

Нет. Поможет — понять, чем передача _потока_ (как в TCP и вообще как в SOCK_STREAM) отличается от передачи _пакетов_ (как в SOCK_DGRAM или SOCK_SEQPACKET), хотя тут термин "пакет" таки крив.

C> Думается что раз такая нумерация уже есть в TCP то введение своей ситуацию не исправит... Или можно уверенно сказать что дублирования пакетов быть не может потому что не может быть никогда и идти править руки? :)

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

Да. Согласен слово пакет совершенно неуместно. Да согласен в том, что TCP потоковый протокол. Клиент общается сервером в режиме вопрос — ответ. Очень редко (ну ооочень очень редко) возникает ситуация когда приходит два пакета (поток рубится на пакеты сервером, там CRC32, размеры, криптование и все такое, вероятность ошибочной интерпретации потока — нулевая). Приход двух пакетов определяется косвенно. В логах возникает ситуация когда действие отразилось с временным интервалом <1 сек (0.3-0.4). Но пользователь физически не мог сделать запрос так часто (в силу реализации). Вижу один вариант: дублирование IP пакета. Но подозреваю что это невозможно. Хм.. В общем как то так.

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

C>Да. Согласен слово пакет совершенно неуместно. Да согласен в том, что TCP потоковый протокол. Клиент общается сервером в режиме вопрос — ответ. Очень редко (ну ооочень очень редко) возникает ситуация когда приходит два пакета (поток рубится на пакеты сервером, там CRC32, размеры, криптование и все такое, вероятность ошибочной интерпретации потока — нулевая). Приход двух пакетов определяется косвенно. В логах возникает ситуация когда действие отразилось с временным интервалом <1 сек (0.3-0.4). Но пользователь физически не мог сделать запрос так часто (в силу реализации). Вижу один вариант: дублирование IP пакета. Но подозреваю что это невозможно. Хм.. В общем как то так.

Ещё и с правильным смещением sequence number? Неуместная фантастика, IMHO.
Скорее — глючит или передающая сторона, или принимающая (не так выбрала из потока или дважды обработала буфер).
Снимите детали потока tcpdump'ом и проанализируйте с точки зрения протокола. Можно wireshark'ом для автоматизации парсинга деталей.

C>Да. Согласен слово пакет совершенно неуместно. Да согласен в том, что TCP потоковый протокол. Клиент общается сервером в режиме вопрос — ответ. Очень редко (ну ооочень очень редко) возникает ситуация когда приходит два пакета (поток рубится на пакеты сервером, там CRC32, размеры, криптование и все такое, вероятность ошибочной интерпретации потока — нулевая). Приход двух пакетов определяется косвенно. В логах возникает ситуация когда действие отразилось с временным интервалом <1 сек (0.3-0.4). Но пользователь физически не мог сделать запрос так часто (в силу реализации). Вижу один вариант: дублирование IP пакета. Но подозреваю что это невозможно. Хм.. В общем как то так.
Такого не бывает (с) В пределах допущений современных технологий. У вас слишком мало времени было чтоб на них нарваться, да еще и систематически воспроизвести .
Кстати а какой канал между клиентом и сервером? Вполне реальна ситуация того что конекшн просто гдето "заткнулся" (гусары — молчать), а потом его прорвало (молчать, я сказал и пришло пара пакетов сразу. + тот же nagle, хотя он врядли будет так визуально заметен.

да нету тут систематики. ну раз в месяц, ну в пол месяца возникает такое. При достаточно интенсивном обмене.

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

C>Вижу один вариант: дублирование IP пакета. Но подозреваю что это невозможно.

Да, невозможно. Как бы там не было на уровне пакетов IP, на уровне потока TCP вы никаких дублей не увидите. Какова причина малых интервалов в логах? Да любая. По порядку, от клиента к серверу:
— клиент протормозил с send и две порции данных ушли почти одновременно;
— TCP на стороне пользователя решил подождать с отправкой и две порции данных ушли одним пакетом (Nagle);
— первая порция данных не дошла и была передана повторно (дошла, соответственно, практически одновременно со второй);
— сервер протормозил с recv и получил две порции данных почти одновременно;
— сервер протормозил с обработкой, потому записи в логах появились почти одновременно.
Ну и в этом роде можно еще расширить список раза в два-три.
Примите за аксиому отсутствие ошибок в реализации TCP. Их вероятность выражается настолько малым числом, что у него и названия-то нет (подумайте сколько эксабайт трафика по всему миру было передано по TCP без ваших "дублей")