> Чаво? Потери? На TCP? В tcp теряться ничего не может, на то он и TCP.Теоретически - да. Практически - TCP при этом начинает работать с RTT в 2 минуты из-за того что congestion control думает что пинг 2 секунды и выпадения пакетов - от перегруза сети. А когда оно через 5 минут мучений отлипает наконец по таймауту - попродуй угадать: дошло твое сообщение к вон тому перцу или нет.
> И вообще, сообщения IM это вообще не те данные, для которых нужно на UDP переходить.
Однако на UDP можно получить нормальный latency. Даже на поганом канале с выпадением пакетов и прочая (заранее зная что данных мало - переотправку и таймауты можно сделать куда агрессивнее TCPшных). И это работает даже во всяких дypацких операционках типа винды, где всякие setsockopt(...TCP_NODELAY...) для хоть какого-то приведения TCP в адекват и то сделать не прокатит.
> Время доставки вообще не критично, плюс несколько секунд
> к доставке - никакой роли не играют.
TCP, думающий что выпадение пакетов и пинг 2 секунды это перегруз сети - может догнать таймауты до, натурально, минут. И вместо IM получается нечто, работающее со скоростью хуже емыла. Когда перекидывается одно сообщение в пять минут - это нифига не instant, извините.
> Даже эти несколько секунд могут быть на TCP только в самом худшем случае,
Угу, попробуй погонять TCP на жпрс где RTT бывает до 2...30 секунд. Или на еле ловящейся вайле. С потерями 30% пакетов. Вот тогда узнаешь за что не любят TCP. Он делался под другие реалии. И если в линухе это еще частично лечится выбором алгоритма congestion control + TCP_NODELAY, лечится оно таки только на 50%, кроме того - это не для всех операционок работает. И если тебе нувотнадоблин переписываться с виндузоидом, оказавшимся на вафле с выпадением пакетов в кафешке, и от него сообщения по 5 минут тупят - это таки будет и твоя проблема в том числе.
при огромных
> потерях пакетов. Здесь критична гарантия доставки.
