Здравствуйте, WolfHound, Вы писали:
WH>Про протокол как я понимаю ты ничего так и не прочитал.
Посмотрел полуторами глазами.
F>>Хм... это как-то стрёмно. Даже в случае постоянного контента могут быть случаи, когда нужно совершать разные действия (например, в случае tcp дропать пакеты в случае атаки и т.д.) WH>Ну и дропай сколько влезет. Но если решил ответить то позаботься чтобы ответ был тем-же.
Вот и тут будут проблемы — одно "зеркало"/нода/кеш/etc решит ответить, другое дропнуть — синхронизация очень нетривиальна, и никуда ты от неё не денешься, как только захочешь что-то кешировать. И не важно, на каком уровне ты это будешь делать — базовых пакетов или целой транзакции.
Дальше, предвижу проблемы с анонсом сервисов наружу. Даже сейчас при "простой" организации ipv4 с этим случаются проблемы — а при потенциально неорганиченной сменной иерархии CNN будет вообще труба.
F>>В смысле? почему сеть должна упасть при нынешней архитектуре и данном стеке протоколов? WH>По тому что TCP/IP не масштабируется в случае исли большое колличество народа спрашивает один и тот же контент.
Судя по тому, что я прочитал, CCN прекрасно масштабируется лишь при магическом условии, что разные части находятся в согласованном состоянии.
WH>А по утверждению автора CCN это 90% трафика в современной сети. WH>И CCN способен этот трафик значительно скукоржить.
Ну дык, и не надо это делать на уровне tcp. Я так понимаю, что под 90% трафика автор понимал медиа-контент. Ну так для этого нужно что-то типа торрентов — и рулить всем этим делом сверху, т.е. на уровне приложений, а не на уровне пакетов. При этом неважно, что будет внизу.
F>>Это только потому, что VoXXX — робастный и избыточный протокол. WH>Там до избыточности VoXXX дело не дошло. Все замаскировал CCN.
Ну, при простом переключении 2 однородных каналов — верю, это как-то можно сделать. В случае если их будет 1000, 10000, 100000 — сомневаюсь
F>>В частности это отностится к якобы плюшке с верификацией контента. Чтобы не повторяться — сюда применимы все возражения, которые обычно приводят при критике структуры master/slave. WH>Причем тут вообще master/slave? F>>Кстати, насколько я понимаю, сейчас всё больше от неё отходят — тот же gfs по слухам (т.е. источник не помню, а искать несколько лениво ) всё чаще упоминается в конфигурации без slave'ов. WH>Ты про какой GFS?
Который googlefs, bigtable и куча других страшных слов.
F>>Имхо не стоит вкладывать в низкоуровневый протокол какие-то интеллектуальные вещи, которые должны быть одним-двумя-тремя уровнями выше. WH>А что посчитать цифровую подпись уже в интеллектуальные вещи записали? Не знал.
На каждый пакет?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, SergH, Вы писали:
SH>На торренты похоже.
Именно на торенты, а не на HTTP как думают некоторые.
Ибо и CCN и торенты ориентированны на контент, а нет на получение ответа от конкретной машины.
SH>А вообще прикольно, спасибо за наводку, надо будет почитать. SH>Правда, пока я скептически к этому отношусь.
Посмотрим что получится.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
CC>В современной сети полным полно VPN, SSL, Torrent и прочего шифрованного трафика. Который по определению никакими силами не скукожить.
Угу процентов 10%...
Кстати торенты при желании можно скукоржить.
CC>Ну а вообще вся эта CCN задумка очень похоже на yet another web accelerator.
Ну что поделать если именно это и надо ускорять в современных условиях.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Откуда он это знает?
Примерно от туда же откуда роутер знает куда IP пакеты маршрутизировать.
M>Что мешает реализовать это знание в HTTP?
Не поверишь. IP протокол.
M>Ну дык, Amazon S3 и сейчас так, емнип, работает. Упал где-то амазоновский сервер, все продолжило качаться
Ага конечно. Новые запросы оно может переправить на другой сервер. А вот запросы которые обломились в процессе закачки отваляться ибо чудес не бывает.
M>Поправьте меня, если на download точно так же не работают CDN'ы, load-balancer'ы и т.п.
Они могут переправить новые запросы на живые серверы. А те запросы которые обломились в середине умирают. Ибо протокол не позволяет и в чудеса я не верю.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, frogkiller, Вы писали:
WH>>Про протокол как я понимаю ты ничего так и не прочитал. F>Посмотрел полуторами глазами.
Чем посмотрел?
F>Вот и тут будут проблемы — одно "зеркало"/нода/кеш/etc решит ответить, другое дропнуть — синхронизация очень нетривиальна, и никуда ты от неё не денешься, как только захочешь что-то кешировать. И не важно, на каком уровне ты это будешь делать — базовых пакетов или целой транзакции.
Если одна нода дропнула, а другая ответила то клиент получит ответ.
Зачем тут нужны синхронизации не ясно.
Ты точно понимаешь как протокол работает?
F>Дальше, предвижу проблемы с анонсом сервисов наружу. Даже сейчас при "простой" организации ipv4 с этим случаются проблемы — а при потенциально неорганиченной сменной иерархии CNN будет вообще труба.
Можешь рассказать подробней?
F>Судя по тому, что я прочитал, CCN прекрасно масштабируется лишь при магическом условии, что разные части находятся в согласованном состоянии.
А с какого перепуга они будут не согласованы?
F>Ну дык, и не надо это делать на уровне tcp. Я так понимаю, что под 90% трафика автор понимал медиа-контент. Ну так для этого нужно что-то типа торрентов — и рулить всем этим делом сверху, т.е. на уровне приложений, а не на уровне пакетов. При этом неважно, что будет внизу.
Как я понимаю автор имеет в виду вообще весь трафик который генерируется статическим контентом.
Впрочем динамический контент типа телевизионной трансляции CCN тоже прекрасно скукорживает.
В случае VoCNN конференции уже для 3х человек есть шанс сэкономить по сравнению с VoIP. Шифрование не мешает скукорживать трафик.
F>Ну, при простом переключении 2 однородных каналов — верю, это как-то можно сделать. В случае если их будет 1000, 10000, 100000 — сомневаюсь
Это сделано не как-то, а совершенно универсальным способом.
Почему должны быть проблемы на большем масштабе мне не ясно.
F>>>В частности это отностится к якобы плюшке с верификацией контента. Чтобы не повторяться — сюда применимы все возражения, которые обычно приводят при критике структуры master/slave. WH>>Причем тут вообще master/slave?
Ответь пожалуйста на вопрос.
WH>>А что посчитать цифровую подпись уже в интеллектуальные вещи записали? Не знал. F>На каждый пакет?
А что тебя смущает?
Если что роутеры не обязаны считать подписи для всех проходящих через них пакетов.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
WH>>Кстати торенты при желании можно скукоржить. CC>Нет. На транспортном уровне никак. Трафик шифрованый.
Даже параноидально зашифрованный freenet и то скукоржить можно.
Короче нужно просто правильно шифровать чтобы можно было скукорживать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Короче нужно просто правильно шифровать чтобы можно было скукорживать.
Ой таки не смешите мои подковы.
То шо таки ви предлагаете (грубо говоря не использовать IV, что есть weakness) есть вша жОлтая и черти со спины.
На это ни один вменяемый ребе не пойдетЪ
Здравствуйте, WolfHound, Вы писали:
WH>>>Про протокол как я понимаю ты ничего так и не прочитал. F>>Посмотрел полуторами глазами. WH>Чем посмотрел?
Наверное он смотрел вот так: O_o
WH>Шифрование не мешает скукорживать трафик.
Это только если у нас один источник и куча получателей, синхронизированые между собой. Т.е. ключ и IV у них у всех одинаковый.
Да и то это получается обычный броадкаст.
Здравствуйте, CreatorCray, Вы писали:
WH>>Короче нужно просто правильно шифровать чтобы можно было скукорживать. CC>Ой таки не смешите мои подковы. CC>То шо таки ви предлагаете (грубо говоря не использовать IV, что есть weakness) есть вша жОлтая и черти со спины. CC>На это ни один вменяемый ребе не пойдетЪ CC>
Другими словами ты считаешь что freenet уязвим? А можно послушать техническое обоснование?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
CC>Это только если у нас один источник и куча получателей, синхронизированые между собой. Т.е. ключ и IV у них у всех одинаковый.
Я так думаю это верно в подавляющем большинстве случаев.
И в еще большем количестве случаев вообще никакого шифрования не будет.
CC>Да и то это получается обычный броадкаст.
Нука продемонстрируй мне броадкаст на весь интернет?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>>>Про протокол как я понимаю ты ничего так и не прочитал. F>>Посмотрел полуторами глазами. WH>Чем посмотрел?
Чуть более, чем одним глазом — как-то вот так:
F>>Вот и тут будут проблемы — одно "зеркало"/нода/кеш/etc решит ответить, другое дропнуть — синхронизация очень нетривиальна, и никуда ты от неё не денешься, как только захочешь что-то кешировать. И не важно, на каком уровне ты это будешь делать — базовых пакетов или целой транзакции. WH>Если одна нода дропнула, а другая ответила то клиент получит ответ. WH>Зачем тут нужны синхронизации не ясно.
Внимание, вопрос — две ноды ответили по-разному, какое поведение корректное? Если данные оказались маленьние, что поместились в 1 пакет, peer'у будет очень проблематично определить подмену.
WH>Ты точно понимаешь как протокол работает?
Думаю, что понимаю
F>>Дальше, предвижу проблемы с анонсом сервисов наружу. Даже сейчас при "простой" организации ipv4 с этим случаются проблемы — а при потенциально неорганиченной сменной иерархии CNN будет вообще труба. WH>Можешь рассказать подробней?
Ну вот представь, у тебя сеть не из двух трёх машин, а из нескольких тысяч. Анонсы больших маршрутизаторов занимают определённое время — по факту секунды, даже десятки секунд. В это время у тебя сеть находится в неопределённом состоянии — ты должен помнить, как это, например, выглядит в Я., и что при этом происходит. Если же адресация будет символьной/(с неопределённой структурой) это время, полагаю, возрастёт на порядок даже для самых крутых маршрутизаторов.
F>>Судя по тому, что я прочитал, CCN прекрасно масштабируется лишь при магическом условии, что разные части находятся в согласованном состоянии. WH>А с какого перепуга они будут не согласованы?
Ну вот с такого. Была у тебя одна нода, потом раз — и появилась ещё одна с частью контента исходной. Во-первых, появилась — не мгновенно, а за вполне ощутимое время (см. выше), а во-вторых, сколько-то времени уйдёт, прежде чем система поймёт, например, что контент на новой ноде содержит ошибки. А ещё хуже, если она будет "мигать". Всё это время по факту не будет работать вся система, включая исходный сервис.
F>>Ну дык, и не надо это делать на уровне tcp. Я так понимаю, что под 90% трафика автор понимал медиа-контент. Ну так для этого нужно что-то типа торрентов — и рулить всем этим делом сверху, т.е. на уровне приложений, а не на уровне пакетов. При этом неважно, что будет внизу. WH>Как я понимаю автор имеет в виду вообще весь трафик который генерируется статическим контентом. WH>Впрочем динамический контент типа телевизионной трансляции CCN тоже прекрасно скукорживает. WH>В случае VoCNN конференции уже для 3х человек есть шанс сэкономить по сравнению с VoIP. Шифрование не мешает скукорживать трафик.
Как уже говорили выше по ветке, шифрование сильно помешает "скукорживанию", поскольку каждый кусок будет уникальным. И вообще — чем по сути это отличается от обычного броадкаста?
F>>Ну, при простом переключении 2 однородных каналов — верю, это как-то можно сделать. В случае если их будет 1000, 10000, 100000 — сомневаюсь WH>Это сделано не как-то, а совершенно универсальным способом. WH>Почему должны быть проблемы на большем масштабе мне не ясно.
Надеюсь, выше я ответил.
F>>>>В частности это отностится к якобы плюшке с верификацией контента. Чтобы не повторяться — сюда применимы все возражения, которые обычно приводят при критике структуры master/slave. WH>>>Причем тут вообще master/slave? WH>Ответь пожалуйста на вопрос.
При том, что основная (и не решённая до сих пор) проблема — это поддержание системы в согласованном состоянии. Базворды типа master|slave я упомянул из-за сильного сходства проблем, с которыми придётся столкнуться создателям CCN при хоть сколько-нибудь большой нагрузке, с теми, которые имеют место, например при синхронизации БД. Эти проблемы не исчезнут от того, что их с вершины стека протоколов перенесут в середину или в низ. При этом имхо ситуация даже будет хуже.
WH>>>А что посчитать цифровую подпись уже в интеллектуальные вещи записали? Не знал. F>>На каждый пакет? WH>А что тебя смущает? WH>Если что роутеры не обязаны считать подписи для всех проходящих через них пакетов.
и в чём тогда фишка этой фичи?
Если предполагается, что это должны делать peer'ы для полученных данных — то это явно уже задача более высокого уровня, не находишь?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, WolfHound, Вы писали:
WH>Наткнулся тут на интересный проект http://www.ccnx.org/ WH>Автора похоже окончательно достал IP протокол и он решил придумать ему замену. WH>Причем подход к архитектуре сети был выбран фундаментально иным нежели предлагает IP.
Оно жить не будет. По абсолютно простой причине — оно всё требует, чтобы промежуточные маршрутизаторы в CCNx хранили состояние, причём МНОГО состояния. Причём для маршрутизации одного ответа требуется туева хуча действий. Т.е. заменить IP/UDP уже не получится.
Он там говорит про то, что они будут работать в сети с циклами, и им не надо строить spanning tree для маршрутизации. Но это как раз плохо, так как именно представление сети как spanning tree позволяет использовать stateless-маршрутизаторы.
Ещё интересное:
Unlike many other protocols, the CCNx protocol does not have any fixed-length fields. Instead, CCNx data formats are defined by XML schemas and encoded with explicitly identified field boundaries. This design permits field values of arbitrary length, optional fields that consume no packet space when omitted, and nested structures. The use of XML structure does not imply that field values are text strings nor does it require that messages be encoded as human-readable text. Most fields are defined to contain arbitrary binary values, including those that identify content.
Уххх. Какие просторы для DDoS'а, это сложно даже представить!
В общем, не понимаю я что оно даст для динамического контента. Для статического контента всё более-менее понятно и сводится к большой DHT.
Здравствуйте, WolfHound, Вы писали:
WH>Кстати их издевательства над VoCCN прекрасно показывают насколько хорошо CCN маскирует сбои. WH>Смотри этот документ http://www.parc.com/content/attachments/networking-named-content-preprint2.pdf на 10ой странице.
Ерунда, у них даже в этом идеальном случае уже были потери пактов из-за таймаутов.
WH>Еще одна плюшка CCN'а в том что он в сравнении с IP не имеет проблем с мобильными устройствами.
В Mobile IPv6 их тоже нет. К примеру, мой ноутбук с ним переключается между WiFi-соединением, проводным и GPRS'ом без потери открытых SSH-сессий.
Здравствуйте, WolfHound, Вы писали:
G>>Помоему это HTTP на сетевом уровне. WH>А что HTTP уже поддерживает множественные пути доставки?
Да. На уровне IP — и ты этого обычно даже не замечаешь.
Здравствуйте, frogkiller, Вы писали:
F>Внимание, вопрос — две ноды ответили по-разному, какое поведение корректное? Если данные оказались маленьние, что поместились в 1 пакет, peer'у будет очень проблематично определить подмену.
peer подпись проверит.
F>Ну вот представь, у тебя сеть не из двух трёх машин, а из нескольких тысяч. Анонсы больших маршрутизаторов занимают определённое время — по факту секунды, даже десятки секунд. В это время у тебя сеть находится в неопределённом состоянии — ты должен помнить, как это, например, выглядит в Я., и что при этом происходит.
В том то и прикол что все будет хорошо.
В данном случае вообще никаких анонсов небыло. Просто случился таймаут и нода отправила запрос по другому пути.
F>Если же адресация будет символьной/(с неопределённой структурой) это время, полагаю, возрастёт на порядок даже для самых крутых маршрутизаторов.
Не думаю что время обновления будет заметно отличатся от IPv6.
Ибо не с чего.
F>Ну вот с такого. Была у тебя одна нода, потом раз — и появилась ещё одна с частью контента исходной.
Замечательно. Больше путей доставки.
F>Во-первых, появилась — не мгновенно, а за вполне ощутимое время (см. выше),
Конкретная нода через которую ходит узнает о новой ноде в вполне конкретный момент времени.
Так что она появилась сразу.
F>а во-вторых, сколько-то времени уйдёт, прежде чем система поймёт, например, что контент на новой ноде содержит ошибки.
Достаточно проверить подпись.
Плюс возможно реализовать протокол обратного распространения информации об ошибках. Те если нода засекла ошибку то она может не только дропнуть свой пакет но и сказать той ноде откуда она его получила что у нее ошибка.
Ноды которые производят много битых пакетов будут попадать в конец очереди маршрутизации вплоть до бана.
F>А ещё хуже, если она будет "мигать". Всё это время по факту не будет работать вся система, включая исходный сервис.
Мигание вообще не проблема.
Ибо протокол имеет возможность направлять один и тот же запрос по нескольким путям.
Собственно в опыте с VoCCN как раз мигание и было.
Протокол все разрулил чисто на таймаутах.
F>Как уже говорили выше по ветке, шифрование сильно помешает "скукорживанию", поскольку каждый кусок будет уникальным.
Шифруется малая часть контента.
Большую часть шифрованного контента можно шифровать так что скукорживанию это не помешает.
F>И вообще — чем по сути это отличается от обычного броадкаста?
Покажи мне броадкаст на весь интернет.
F>Надеюсь, выше я ответил.
Не ответил.
F>При том, что основная (и не решённая до сих пор) проблема — это поддержание системы в согласованном состоянии. Базворды типа master|slave я упомянул из-за сильного сходства проблем, с которыми придётся столкнуться создателям CCN при хоть сколько-нибудь большой нагрузке, с теми, которые имеют место, например при синхронизации БД. Эти проблемы не исчезнут от того, что их с вершины стека протоколов перенесут в середину или в низ. При этом имхо ситуация даже будет хуже.
Что за проблемы.
Давай конкретно.
Ибо я понимаю все прелести синхронизации БД не не понимаю причем тут CCN?
WH>>Если что роутеры не обязаны считать подписи для всех проходящих через них пакетов. F> и в чём тогда фишка этой фичи?
Фишка в том что могут не проверять, а могут и проверить. И если пакет битый то его дропнут.
F>Если предполагается, что это должны делать peer'ы для полученных данных —
Они должны это делать в обязательном порядке.
F>то это явно уже задача более высокого уровня, не находишь?
Нет. Не нахожу.
Ибо сеть у нас ориентирована не на соединения, а не контент и по этому должна гарантировать сохранность этого самого контента.
Вообще говоря учитывая личность автора не думаю что в этом протоколе можно будет так просто найти фатальные недостатки.
По крайней мере все что находил я не выдерживало критики при вдумчивом анализе.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Оно жить не будет. По абсолютно простой причине — оно всё требует, чтобы промежуточные маршрутизаторы в CCNx хранили состояние, причём МНОГО состояния.
Много состояния нужно только тем роутерам которые решили заняться кешированием.
Остальным нужно только интересы запоминать, а это уже не много.
C>Причём для маршрутизации одного ответа требуется туева хуча действий. Т.е. заменить IP/UDP уже не получится.
Ну IP пакеты тоже не так уж просто маршрутизировать.
C>
C>Unlike many other protocols, the CCNx protocol does not have any fixed-length fields. Instead, CCNx data formats are defined by XML schemas and encoded with explicitly identified field boundaries. This design permits field values of arbitrary length, optional fields that consume no packet space when omitted, and nested structures. The use of XML structure does not imply that field values are text strings nor does it require that messages be encoded as human-readable text. Most fields are defined to contain arbitrary binary values, including those that identify content.
C>Уххх. Какие просторы для DDoS'а, это сложно даже представить!
Как формат пакетов влияет на DDoS?
C>В общем, не понимаю я что оно даст для динамического контента. Для статического контента всё более-менее понятно и сводится к большой DHT.
Ну например VoCCN к DHT не сводится ибо в DHT не может появиться еще не существующий контент.
Тоже самое относится к различным онлайн трансляциям.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Ерунда, у них даже в этом идеальном случае уже были потери пактов из-за таймаутов.
Во первых потерей ну уровне CCN небыло.
Во вторых чтобы сравнение было объективным с CCN стеком нужно сделать тоже самое что с IP стеком те засунуть в ядро и оптимизировать.
C>В Mobile IPv6 их тоже нет. К примеру, мой ноутбук с ним переключается между WiFi-соединением, проводным и GPRS'ом без потери открытых SSH-сессий.
А ты читал как это мобильный IPv6 устроен?
Мрак!
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Cyberax, Вы писали:
C>Да. На уровне IP — и ты этого обычно даже не замечаешь.
C>Вот только что попинговал google.com:
хъ C>Я выделил места, где пакеты попеременно проходили через разные маршрутизаторы.
А ты уверн что ты на банальный лоадбалансер не нарвался?
Их в гугле должно быть много.
C>Предложенный автором вариант подходит в реальности только для статического контента. Этакий eDonkey на стероидах
В реальности для динамического он тоже подходит что автор и продемонстрировал при помощи VoCCN.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Что-то мне по твоему описанию это торренты напомнило. А что — тоже вполне себе content centric сеть. Запросил контент "по имени", а от кого он там конкретно идет тебе по фиг. И все прекрасно реализовано поверх TCP/IP.
) всё чаще упоминается в конфигурации без slave'ов.
