нейтральность сетей

[xoid]

Никак не пойму я , чего боится гугл.

Если какой-то хитрый кабельщик перекроет своим юзерам доступ к нему,

он только пол-рта успеет раскрыть, чтобы сказать "давай гугль гони монету за доступ"

как его собственные юзеры распнут и порвут на британский флаг.

 

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

кабельщикам ни цента ни при каком раскладе, чтоб те сидели и не рыпались.

 

Кроме того, контентщики могут пригрозить кабельщикам:

1 Помощью юзерам в судебном преследовании

2 Антирекламой. Юзер заходит на Гугль, а там написано "Ваш провайдер такой-то зажимает вам доступ на столько-то, вот телефон хорошего провайдера в вашем районе, который так не делает"

 

Нужно быть безумцем, чтобы поставить на кабельщиков в этом противостоянии.

 

Зачем же законы?

[Nag]

Ну вот в России всего два с половиной магистральщика.

В штатах могу соврать, но вроде 3 или 4...

Они могут вполне элементрано договориться. :-)

[leiden]

Не платящий ни цента никому ни от кого не получает услуг.

А Гуглу нужна полная связность со всем миром.

Поэтому пока он сам себе не сможет обеспечить полную связность со всем миром (а этого никогда не случится) - он будет платить.

И битва идет не по вопросу "платить Гуглу или нет", а по вопросу "Гуглу платить больше чем другим или столько-же". Не путайте эти вопросы.

[GateKeeper]

урл хоть дайте, что ли...

[hcube]

Вообще говоря, провадер может прописать в договоре разные скорости 'наружу' и 'до себя', причем разные в разы. Тогда естественным образом неуникальный контент будет выгоднее качать с ресурсов провайдера, а не с гугла.

[Nag]

Вообще говоря, провадер может прописать в договоре разные скорости 'наружу' и 'до себя', причем разные в разы. Тогда естественным образом неуникальный контент будет выгоднее качать с ресурсов провайдера, а не с гугла.

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

Кто тут 5-ти мегабитным анлимитом размахивал? ;-) На этом уровне уже бесполезно - пользователь будет качать строго оттуда,... Откуда он нашел по поиску того же гугля.

[leiden]

Наг, на самом деле не совсем так.

P2P - будут качать больше все равно с того, что близко. Особливо если таки уговорить в клиентов вставить алгоритм приоритета выбора пира по близости.

И, вполне очевидно, через некоторое время все что тяжелое и выражаемо в виде файла - будут раздавать по схеме P2P. Сейчас меня мучает только один вопрос - как бы сделать P2P на потоках, а не на файлах. Тогда и P2P-TV может появиться - а это даст ОЧЕНЬ сильную экономию на магистралях.

[Гoсть]

Ты думаешь они перестанут засирать винчестера что-бы брать сразу в голову? Сомнительно. Ты не то что-бы сэкономишь на магистралях, а ровно наоборот.

[Sonne]

Я думаю вопрос нейтральности сетей стоит в аспекте QoS и касается прежде всего видеоконтента и IP-телефонии.

 

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

 

Итак, имеем две чаши весов. С одной стороны - владение сетями доступа, с другой стороны владение контентом, к которому этот доступ нужен. Что важнее?

 

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

 

На западе, где расстояния поменьше, а платежеспособный спрос побольше вопрос совсем не очевиден.

 

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

[Nag]

P2P - будут качать больше все равно с того, что близко. Особливо если таки уговорить в клиентов вставить алгоритм приоритета выбора пира по близости.

А что, в р2р как-то можно опеределить "близость"?

И когто-то сильно волнует скорость скачки, настолько, что будут сравнивать?

[Прохожий]

Сейчас меня мучает только один вопрос - как бы сделать P2P на потоках, а не на файлах. Тогда и P2P-TV может появиться - а это даст ОЧЕНЬ сильную экономию на магистралях.

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

 

А вообще - чем больше думаю над этим - тем более возможным мне это кажется :)

[Sonne]

Не получится p2p на потоках увы.

 

Есть такая вещь как синхронизация. Нужные кадры должны прийти в строго опредленное время. Резать кадр на половинки нельзя, накапливать в буфере - нельзя.

[leiden]

В P2P можно определить близость по метрике "хопы". Ее вполне хватит.

 

А что касается синхронизации - синхронизировать потребление одного источника разными потребителями - ВОВСЕ не обязательно. Отсюда и рекомендую Sonne немного подумать. :)

А буферить из-за этого - можно. :)

[Sonne]

Так-с..

 

Включаем трансляцию... 1 узел.

 

К нему приконекчиваются 2 узла и начинают накапливать кадры в буфере. Могут ли они образовать третий поток чтобы соединить ветви этого простейшего дерева? НЕТ! Поскольку каждый из них имеет более свежие кадры напрямую из корня.

 

Допустим они могут отдавать уже задержанный поток вниз.

Но тогда мы получаем классический ретранслятор! Заставить клиента множить получаемые данные остальным нереально.

В p2p сетях клиенту это выгодно т.к. отдавая скачанные куски он освобождает очередь для нужных ему кусков.

 

В трансляции p2p невозможно по простой причине - онлайн репортаж матча полуфинала мира по футболу часовой давности никому уже не нужен, т.к. это уже в прошлом, а увидеть будущее с ТВ качеством пока никому не удавалось.

[Прохожий]

Сонни, задержку трансляции даже в 10 секунд ты не сильно заметишь... Особенно, если все это будет бесплатно ;)

 

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

 

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

 

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

 

С другой стороны, учитывая объемы памяти современных компьютеров, то и FullView BGP займет лишь малую ее толику... Плюс тенденции... Так что все возможно!

 

Не, мысль очень интересная.

[Гoсть]

Ну вы блин даете!

Кто будет вещателем-первоисточником и как "узлы" будут это хранить (в виде потоков)? Клиенты будут смотреть по расписанию? По чьему расписанию? Как клиент будет переключать "каналы"? Кто кому и за что будет платить бапки? Зачем спижженый фильм показывать однократно в реал-тайме? И тд и тп..

[Прохожий]

Ну вы блин даете!

А что, нельзя?

Кто будет вещателем-первоисточником

Любой узел...

и как "узлы" будут это хранить (в виде потоков)?

А хранить и не надо, достаточно ретранслировать. Хранить - буфер для выравнивания потока перед показом

Клиенты будут смотреть по расписанию?

Ну мы же про вещание, зачит именно так...

По чьему расписанию?

По расписанию вещателя, ясное дело...

Как клиент будет переключать "каналы"?

А как он сейчас выбирает файлы для загрузки?

Кто кому и за что будет платить бапки?

А кто кому платит сейчас в P2P?

Зачем спижженый фильм показывать однократно в реал-тайме? И тд и тп..

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

 

С у влечением послушаю и т.д. и т.п.

 

Коллега, это новые возможности. Если таковая технология окажется эффективной - это вообще может изменить многое, как многое изменил P2P файлообмен. И я еще раз повторюсь, что чем больше задумываюсь - тем более реальным мне это кажется. Правда, начинаю резко чувствовать недостаток прикладных знаний. Если на уровне принципов реализации и внутренней логики у меня уже многое складывается, то на уровне КАК КОНКРЕТНО - пока еще вовсе нет.

 

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

Edited September 8, 2006 by Прохожий

[Nag]

В P2P можно определить близость по метрике "хопы". Ее вполне хватит.

Можно. Но нужно ли это клиенту?

 

 

Коллега, это новые возможности. Если таковая технология окажется эффективной - это вообще может изменить многое, как многое изменил P2P файлообмен. И я еще раз повторюсь, что чем больше задумываюсь - тем более реальным мне это кажется. Правда, начинаю резко чувствовать недостаток прикладных знаний. Если на уровне принципов реализации и внутренней логики у меня уже многое складывается, то на уровне КАК КОНКРЕТНО - пока еще вовсе нет.

По хорошему, на этой идее надо срочно хреначить стартап.

Такая штука может замочить IPTV в его теперешнем виде напрочь.

За сколько там Скайп продался? 4 ярда?

А в Скайпе то же трафик по узлам как-то хитро транзитится...

[hcube]

Ну и чего? Анлим 5 мбит, а на внутренние ресурсы - 20. Или 50. Причем анлим можно чуточку подгадить - просто подержать пакеты этак порядка 20-30 ms ;-). И тогда все П2П алгоритмы переведутся на локал. Ну, не все, но многие.

 

Кстати, трансляция - это же отдельные кадры. Или мелкие кусочки. Но IMHO проще пропускать через локальный ретранслирующий роутер, чем делать систему типа P2P. Дешевле и проще расставить по ретранслятору на каждые 50-100 пользователей, чем писать софт, который этих же пользователей в качестве ретрансляторов использует ;-)

 

А как сделать - да очень просто. Надо загнать видеопоток в транспорт с избыточностью (скажем, 20%), порезать на мелкие кадры и раздать пользователям. Кадры пронумеровать сковозной нумерацией скажем на 15 секунд вперед. За счет избыточности сделать надежность при переключении источников сигнала и ресинхронизации. Только все равно не понимаю, нафига оно надо ;-)

Edited September 8, 2006 by hcube

[Прохожий]

Паша, гаси тему, потом мочи тех, кто успел прочитать :) Пошли новый Скайп создавать :)

[hcube]

Кстати говоря в скайпе есть ретрансляция сообщений и потоков - раз, и там же есть видео. Так что все уже украдено до нас (с) ;-).

 

Вообще, конечно, идея смотреть 'TB вскладчину' не лишена привлекательности. Т.е. каждый юзверь тянет скажем по 128к, всего их 8, и они добирают каждый недостающие 960к через локалку. Как средство экономии трафика - кстати - интересная штука. С ней выражение 'сообразим на троих?' приобретает новый смысл. Единицей становится 'компоканал' - т.е. комп подключенный в локальной области к некоторому каналу. Кстати, поскольку каждый комп получает поток, даже если качает пренебрежимо малую часть в случае большого числа одновременно подключенных компов - то можно делать например такую фишку как цифровая видеозапись определенного контента из этого общего канала. Т.е. комп 'слушает' что происходит в сети и интересный контент скидывает на диск - хозяева потом посмотрят.

 

Но для этого нужно чтобы ИСТОЧНИК мог определенным образом отдавать ЧАСТЬ потока. Причем в идеале - МАЛУЮ часть. Видимо проще всего это сделать раскадровкой потока - компы просто будут договариваться кто какие кадры качает, а потом меняться тем что накачали. Еще видимо полезно назначать 'ответственные компы' - которые аккумулируют весь поток и потом его фигачат в сеть мультикастом. А то при росте размера сети загруженность растет чуть быстрее квадрата размера.

 

Блин, а ведь такой штукой можно вообще говоря что угодно качать так. Например, свести полдюжины GPRS в мегабитный канал.

Edited September 8, 2006 by hcube

[Прохожий]

Это называется "обратным мультиплексированием" и изветсно давно. Мы совсем не о том. В принципе.

[Гoсть]

Прохожий, сначала неплохо бы ответить на вопрос ДЛЯ ЧЕГО, а уже потом КАК. Цель обозначь.

[Виктор С. Грищенко]

http://en.wikipedia.org/wiki/P2PTV

 

The term P2PTV refers to peer-to-peer software applications designed to redistribute video streams on a p2p network, typically TV stations across the world. The draw to these applications is significant because they have the potential to make every TV channel in the world global.

The benefit of using peer-to-peer technology is similar to that of standard peer-to-peer software. Each user, while downloading, is also uploading, thus contributing to the overall available bandwidth. The video quality of the channels typically depend on how many users are watching; the video quality is better if there are more users.

[Гoсть]

Интересная ссылка, спасибо. Оказывается там уже и реализации есть.

Однако я сильно сомневаюсь что именно эта технология когда-нибудь станет убийцей мультикастинга и завоюет телевизоры казуалов.