Мерси, че ми каза. Не бях се сещал. И какво прави TCP/IP протокола, ако например извадиш кабела за 30 секунди?

Впрочем, поредният номер (sequence) служи за правилното подреждане на пакетите, а не за оправяне на загуби. Ако пакет с номер 5 пристигне преди номер 4, това все още не е гаранция, че номер 4 се е загубил - той може просто да дойде по-късно, защото е минал по различен маршрут. Загубите се контролират чрез изчакване на потвърждение за всеки пакет и повтарянето му, ако това потвърждение не дойде за някакъв интервал от време (например 30 секунди). И още нещо TCP протоколът ти гарантира, че няма да получиш грешни данни, но не ти гарантира, че ще получиш всички данни. Ако например се загуби FIN пакетът, сесията може да остане "полу-затворен", т.е. от едната страна машината да я мисли за затворена, а от другата - за отворена. Бъгав софтуер или бъгава ОС може и да не се справят достатъчно добре с тази ситуация и да загубят част от данните.

Но това не отговаря на оригиналния въпрос, защото такава ситуация може да се появи случайно и вероятността да се повтори със същия файл е нулева. Файлът е обект, с който борави четвъртото (application) ниво, затова и се насочих към евентуално прозрачно прокси. Подобен проблем съм наблюдавал когато то не разбира от persistent connections и затваря сесията, докато по същото време клиентът или сървърът очакват да продължат да предават данни през същата tcp сесия. Ако прблемът е на трето (ip) или второ (ethernet) ниво, би трябвало да се появява или случайно с различни файлове, или постоянно с всички файлове.

Митко