Tcp synchronization / nonsynchronization в реальной жизни

Вроде я tcp знаю, но.. что такое non-synchonization?

Имхо чисто теоретический пэйпр на тему «чтобы было если бы...».

Я так понял речь о том что если tcp нормально работает на полной скорости то udp теряется чаще чем если канал простаивает из-за косяков клиентов. Это же очевидно, не?

Короче, не забивай голову.

Да, документ ппц как устарел. Там речь о 10Мбит скоростях.

И это при том что с тех времён tcp (в плане реализации) уже сто раз перелопатили и смысла в старых измерениях четырнадцатилетней давности нет вообще.

Я имел ввиду, встречается ли в *современных* реализациях tcp такой эффект, как Tcp synchronization / nonsynchronization и, если встречается, то какой из них встречается чаще?

На счет очевидности - я бы не сказал, поскольку, если не брать во внимание реализацию tcp reno, то можно запросто потерять тот самый эффект скользящего окна.

Тем более, никогда нельзя говорить о замерах, не замерив их.

чисто теоретический пэйпр

Судя по тексту, они проводили симуляцию на реальном железе.

Смысл документа в том что на забитом канале пакетов теряется больше. Вот и всё.

никогда нельзя говорить о замерах, не замерив их.

Зато можно сказать что с тех пор всё слишком изменилось. К тому же они на одном линке у себя дома померяли и опубликовали результаты, верно? Ахренеть эксперимент поставили.

Опять-таки, всё это теоретическая хрень. Там сказано что на стабильных линках проблем меньше чем на нестабильных. Копетаны.

Реально говорю, то что тогда было передним краем науки сейчас стало очевидным.

Ты какую задачу решаешь? :)

они проводили симуляцию на реальном железе.

симуляцию

На одном стенде. Супер. А вдруг если задержка не 50мс а 100 ситуация совершенно другая? А вдруг у хостов в сети разные реализации tcp, что тогда?

Всё что говорит этот тест это то что участники сети могут влиять друг на друга в условиях использования общих линков. Фантастика.

они проводили симуляцию на реальном железе.

Судя по тексту они использовали «REAL 4.0» прогу для симуляции. Она даже гуглится. Не пахнет у них там ни чем серьёзным.

REAL 4.0

Это она - http://www.cs.cornell.edu/skeshav/real/overview.html ?

Цель моя - мм, абстрактна :) Наткнулся на блог http://gafferongames.com/networking-for-game-programmers/ (как раз недавно реализовывал упрощенную версию rtp-протокола для айфонов - решил поискать инфы для поднятия скилла) - там в первой статье ссылка на искомую статью.

И, да, если знаешь хороших годных ссылок-манов по сетевому программированию с уклоном в реалтайм (динамические игры, аудио, видео), но не для начинающих, а для товарищей поумнее ;) - давай, буду благодарен!

На счет устаревшей инфы - почему ты решил, что измерения устаревшие? По веб2.0 :) или по «97» в заголовке? Если это таки старая хрень, то ты, скорее всего, прав.

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

Да, еще такой момент. Автор той статьи утверждает, что выгоднее передавать больше мелких удп-пакетов нежели меньше крупных. Это тоже *уже не актуально*?

... В доп. к пред. коменту. ...

Ведь автор в статье как раз и дает объяснение этому факту - почему лучше передавать мелкие пакеты.

1) Очень старая хрень. Этого, в принципе, достаточно :).

2) Сейчас нет тех проблем с полосой пропускания что были раньше. Теперь видео гонять по сети это сущий пустяк в 99% случаев.

По поводу реал-тайма... Могу накидать референсов про p2p-телевидение. Вряд ли это то что тебе нужно, но если требуется оптимизировать логическую топологию (оверлей) под минимальные задержки то http://scholar.google.it/scholar?q=napa-wine&hl=it&btnG=Cerca&lr=

Качаешь любой пейпр, сразу лезешь в референсы и понеслась. За неделю станешь профессионалом :)

А если речь идёт о end-to-end коммуникациях то тут особо-то и оптимизировать нечего (имхо), ведь управлять трафиком по пути ты не можешь. Можно, правда, попытаться выжать что-то большее на линках с высокими потерями (частично этого вопроса касался твой пейпр) путём засылки дублей или управлением максимальной длиной пакета (фрагментацией). Это то из того что я слышал по этой области. Возможно поможет поиграться с QoS и приоритезацией трафика. Большее на ум ничего не приходит при архитектуре клиент-сервер.

В играх (особенно стратегиях) вместо передачи по сети полного состояния игры передают только активность пользователя. Ну а остальное реконструируется, тут помогает генератор псевдо-случайных чисел. С ходу не нашёл статью по этой теме, но должно попастся. Больше ничего не знаю :)

выгоднее передавать больше мелких удп-пакетов нежели меньше крупных.

Так уже давно все делают. См., например, sip. Но, опять таки, это всё очевидно. Я уверен это даже 15 лет назад не было новостью. Просто чувак в очередной раз открыл америку. Мелкие пакеты с большим рейтом всегда пролазят лучше на нестабильных линках. И все эти инсинуации с tcp не нужны чтобы это объяснить. Просто мелочь лучше влазит в мелкие буфера, меньше вероятность потери пакета из-за помех (потому что он меньше) итд итп.

Min 70% публикаций и статей говно. Так что не заморачивайся так из-за одной статьи :).

Но, опять таки, это всё очевидно

Когда опыт есть - это очевидно. Я же только учусь :)

За линк спасибо - поизучаю.

А если речь идёт о end-to-end коммуникациях

Я знаю пир2пир и клиент-сервер. end2end - судя по твоему тексту - это клиент2сервер?

---

Я был на семинаре длинк по воип-телефонии - так они чуть-ли не «визжали» о том, что передачу видео их специализированный voip-роутер не осилит. Зато аудио осиливает более-менее. Понятно, что с несжатыми данными так и получится. Но ведь есть множество кодеков, которые хорошо ужимают видео.

Собственно, где подвох - в утверждении специалистов длинка о том, что передача видео - это очень сложно, или твое утверждение о том, что передавать видео - это не сложно? ;) Наверняка следует ожидать от тебя вопросов по поовду модели роутера и качества специалистов.

И, да, может быть ты знаешь, а то сходу не нагуглил - какая реализация Tcp используется в текущих ядрах линукса-шиндовс-еtc?

о том, что передачу видео их специализированный voip-роутер не осилит.

A voip оборудование производит обработку пакетов, поэтому у них (цитирую какого-то чувака) нагрузка на проц в 6 раз выше чем для остального трафика. Но на самом деле это всё фигня, скайп работает поверх обычного оборудования, причём для меня нормально :)

А те чуваки скорее всего говорили не об интернете а об операторских сетях. Там тоже пакетная передача данных, но со своими нюансами и оборудованием. Там просто другие требования к задержкам и качеству обслуживания. И там оборудование стоит больших денег просто потому что оно для операторов.

В общем, вопрос в том какого качества и какой ценой ты хочешь получить :). Лично я считаю что качества обычных ip-сетей скоро будет достаточно для всего.

end2end - судя по твоему тексту - это клиент2сервер?

Ну это когда не вовлечены другие узлы в передачу данных. Просто с точки зрения tcp нет клиентов и серверов, оба конца равноправны. Но это уже мелочи.

какая реализация Tcp используется в текущих ядрах линукса-шиндовс-еtc?

$ sysctl -a | grep conge
net.ipv4.tcp_congestion_control = cubic

В других осях всё (может быть) по-другому. А для линухов кубик уже несколько лет.

И да, я тоже не спец по этим вопросам :). У меня сугубо потребительское отношения к tcp/ip.

Во, по end-to-end можно сдесь прочитать: http://www.faqs.org/rfcs/rfc3724.html (я сам не читал. в инете были научпоп статьи на эту тему, но я сходу не нашёл)

Не думаю что стоит читать всё, просто пару абзацев что это даёт и зачем это нужно. Строго говоря такие вещи как explicit congestion notification и stateful фаерволы уже не позволяют считать tcp end-to-end...

точки зрения tcp нет клиентов и серверов, оба конца равноправны

Я бы так не сказал. Один *слушает*, другой *соединяется* со слушающим. Тот, кто слушает - сервер. Кто соединяется - клиент. Равноправность начинается с полным дуплексом, когда обе стороны и слушают, и соединяются. Но атомарно - кто-то все равно слушает, а кто-то подключается.

Ну да, есть нюансы :). Но это только на этапе установке соединения, дальше они равноправны.

Прочитал бегло текст по ссылке - end2end - это больше принцип, абстракция нежели что-то более конкретное, как peer2peer или client2server. Да, конечно, так же можно сказать и про них - но это уже разговор философский и терминологический.

Короче говоря, идея в том, что обоим абонентам не интересно, как устроен канал связи между ними, поскольку для них он - абстракция с одним входом и одним выходом. Как-то так.

Но это только на этапе установке соединения, дальше они равноправны

Согласен!

Вот только я не понимаю, почему explicit congestion notification ( http://tools.ietf.org/html/rfc3168#section-5 )

не позволяют считать tcp end-to-end

Как раз таки с точки зрения обоих абонентов все прозрачно и таки end2end. А *что* там в середине - in middle - уже ХЗ, и их не волнует.

идея в том, что обоим абонентам не интересно, как устроен канал связи между ними

Да. И фишка в том что это не самая оптимальная стратегия. Только вот почему-то ничего не нашлось из альтернативщины.

К сожалению альтернативные решения не выживают если у них нет совместимости хотя бы c ip ибо таково требования рынка. А жаль, щас бы могли иметь совсем другое качество связи.

Так ECN посылается middle box. Т.е. появляется третья сторона которая вмешивается в процесс передачи данных и сигнализирует о проблемах на линии. В «классическом» tcp контроль трафика ведётся исключительно на основе замера задержек и потерь пакетов. Поэтому это уже не end2end.

это не самая оптимальная стратегия

На самом деле, а какие возможны альтернативы? На мой взгляд, лучше всего, когда каждый делает только то, что выгодно и полезно ему, то есть, оконечные станции - передают данные и только; промежуточные роутеры, свичи етц - коммутируют, маршртизируют, фаирволят и т.д.

Я хочу сказать, что это и есть *самая оптимальная* стратегия, когда каждый занимается только своим делом. Этот принцип используется очень широко в линуксе, наверняка ты знаешь :) про утилиты, которые «делают только одну вещь, но делают ее хорошо».

С точки зрения инженера-проектировщика - это наиболее гибкий вариант, как мне кажется.

Так ECN посылается middle box

Middle router ведь всего лишь *модифицирует* два бита в пакете, не более. То есть, он сам ничего не шлет, а прсто *помогает* общающимся сторонам узнать о проблемах в канале без дополнительных пакетов с его стороны.

Да, является ли такая схема end2end или нет - вопрос дискутабельный и больше ориентирован на восприятие и философию, нежели на строгий технарьский инжеенрный подход :)

А мой вопрос таков: что чаще встречается в реальной жизни - tcp-synchronization

tcp-synchronization это как джекпот

То есть, он сам ничего не шлет

Он сигнализирует. Появляется обратная связь. Как именно это делается неважно.

это и есть *самая оптимальная* стратегия

У меня тыща контр-аргументов. Если бы это не работало то технологии бы и не внедрялись.

Этот принцип используется очень широко в линуксе

Угу, и это источник проблем. Щас от этого уже уходят. Хороший пример: модель OSI. Она никогда не работала. Зато на её основе много чего натворили. Посмотри вокруг, тупые решения себя изживают. Конкретно где тупой подход не работает: балансировка нагрузки (с учётом загруженности узлов), mpls, stateful-фаерволы, тот же QoS... Даже видео сжимается не по кадрам а с учётом предыдущих и последующих кадров. Хотя как было бы удобно с точки зрения реализации сжимать каждый кадр независимо... Unix-концепция работает хорошо только на тупых конвеерных задачах. Причём конвеер только один и это тоже плохо. При той же обработке видео т.к. видео это как минимум два потока: картинка и звук. Короче, в чистом виде сложную систему из независимых кирпичиков не сделать.

Кооперация между различными уровнями абстракции позволяет достичь большего чем стэк изолированных прослоек.

Да, является ли такая схема end2end или нет - вопрос дискутабельный и больше ориентирован на восприятие и философию, нежели на строгий технарьский инжеенрный подход :)

Ну почему же. Если есть третья сторона то это уже не end2end. Всё строго. Этот термин применяется в rfc, куда уж ему быть более инженерным :).

Я почему про видео вспомнил... С gstreamer и его пайплайнами в своё времяя натрахался :)

Почему «тупые конвейеры» не работают для балансировки нагрузки, wow etc?

Я не уверен - мало опыта разработки, но мне кажется, что если конвейер не работает, то просто неверно организован конвейер.

Потому что в конвеере (по крайней мере в unix pipeline) поток информации идёт только в одну сторону.

Допустим у тебя слёг бэкенд. Так вот без обратной связи балансировщик так и будет туда слать запросы. В реальности есть обратная связь в виде мониторинга. Это значит что это уже нифига не конвеер :).

С unix-пайпами вообще всё весело. Там в общем случае без костылей не узнать exit status проги запущенной где-то посередине. У bash есть PIPESTATUS, а вот в других шеллах это проблема. Другой косяк - буфер между прогами всего 4кб что ужас как мало в в наше время. Правда, это проблемы конкретных реализаций.

Резюме: концепция «моя хата с краю» на практике плохо работает и нужны связи между различными уровнями абстракции.

Я тебя понял, спасибо за раЗвернутый ответ. Но можешь привести *реальные* примеры, где прямолинейныйконвейер не работает и пришлось разрабатывать более сложную систему с внутренними взаимно связями.

Дык уже тыщу привёл :). gstreamer (http://gstreamer.freedesktop.org/images/RTP-gst.png). Или посмотри 16-ю страницу презентации p2p-телевидения http://www.napa-wine.eu/workshop/presentations/Leonardi_NAPA-WINE_architettur... :).

Щас пишу По для управления кластером (облаком), там ни разу не пайплайн. А как бы хотелось таски раскидать по нодам и забыть о них. Но нет, их выполнение надо мониторить, при изменении нагрузки её надо консолидировать или новые тачки включать, при падении ноды надо другую на замену поднимать итд итп. И это без вопросов управления трафиком и мы считаем что вопросы с сетевым хранилищем уже решены.

Короче, очень много внутренних зависимостей и разруливать их очень сложно.

В общем, я давно уже не видел straight-forward программ.

Ну так у тебя получается не просто пайплайн, а иерархический пайплайн, когда верхний уровень как-то руководит нижним. Но все равно таки пайплайн :)

Короче говоря, в каких-то пределах пайплайн реализуем, в тех, которых не реализуем - делается «контроллер», «менеджер» и т.п. сущности, который где-то внутри пайплайн, и т.д.

Сложно, мутно, но - правда. В общем, надо смотреть конкретные случаи - рассусоливать общие материи - не интересно.

Короче говоря, все что хотел, я узнал. И спасибо тебе за интересную дискуссию!

иерархический пайплайн

когда верхний уровень как-то руководит нижним

Это ключевые отличия. И не только верхний, нижний тоже может управлять. Появляются вертикальные связи. В рамках «юникс-философии» (в том смысле как мы её определяем) это реализовать невозможно, что делает её очень ограниченно применимой в реальной жизни.

Если тебе это кажется простым и очевидным... это хорошо :)

Удачи в начинаниях! :)

да открой ты для себя уже fifo

да открой ты для себя уже то что стандартные шелловские утилиты об этом фифо знать не знают, для них что stdout, что фифо, что любой другой дескриптор - один хрен.