Re[3]: Content-Centric Networking (CCN)
От: Cyberax Марс  
Дата: 18.11.09 17:59
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

C>>Оно жить не будет. По абсолютно простой причине — оно всё требует, чтобы промежуточные маршрутизаторы в CCNx хранили состояние, причём МНОГО состояния.

WH>Много состояния нужно только тем роутерам которые решили заняться кешированием.
WH>Остальным нужно только интересы запоминать, а это уже не много.
Любое состояние на магистральных роутерах уже неприемлимо. Они часто вообще реализуют switching logic прямо в железе, даже не в микрокоде.

C>>Причём для маршрутизации одного ответа требуется туева хуча действий. Т.е. заменить IP/UDP уже не получится.

WH>Ну IP пакеты тоже не так уж просто маршрутизировать.
ОЧЕНЬ просто. Ты идёшь по таблице маршрутов и проверяешь маски (понятно, что оно немного сложнее в реальности).

C>>Уххх. Какие просторы для DDoS'а, это сложно даже представить!

WH>Как формат пакетов влияет на DDoS?
Посылаем небольшой пакет с фальсифицированного адреса, а в ответ приходит тонна информации.

C>>В общем, не понимаю я что оно даст для динамического контента. Для статического контента всё более-менее понятно и сводится к большой DHT.

WH>Ну например VoCCN к DHT не сводится ибо в DHT не может появиться еще не существующий контент.
WH>Тоже самое относится к различным онлайн трансляциям.
Это решается для практических задач элементарно — посылаем "сигнальную информацию" (хэш очередного пакета) по TCP, а дальше используем обычный DHT.

Это всё имеет смысл, если есть кэширующие серверы. Т.е. для вещей типа роликов на YouTube, чтобы очередной вирусный ролик брался из ближайшего кэша, а не летел из США.

А для VOiP лучше использовать уже существующие технологии.
Sapienti sat!
Re[5]: Content-Centric Networking (CCN)
От: Cyberax Марс  
Дата: 18.11.09 18:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Ерунда, у них даже в этом идеальном случае уже были потери пактов из-за таймаутов.

WH>Во первых потерей ну уровне CCN небыло.
WH>Во вторых чтобы сравнение было объективным с CCN стеком нужно сделать тоже самое что с IP стеком те засунуть в ядро и оптимизировать.
Ты читал какие там машины использовались? У меня мобильный IPv6 работает с достаточной для трансляции _видео_ скоростью на MIPSовой железяке с 150MHz CPU.

C>>В Mobile IPv6 их тоже нет. К примеру, мой ноутбук с ним переключается между WiFi-соединением, проводным и GPRS'ом без потери открытых SSH-сессий.

WH>А ты читал как это мобильный IPv6 устроен?
Я его себе задеплоил для экспериментов.

WH>Мрак!

Нормально устроен. По умолчанию тебе просто форвардится траффик через третюю сторону (т.е. обычный "triangle routing"). Но есть возможность оптимизации маршрута, если обе стороны понимают IPv6 Mobile.
Sapienti sat!
Re[5]: Content-Centric Networking (CCN)
От: Cyberax Марс  
Дата: 18.11.09 18:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Я выделил места, где пакеты попеременно проходили через разные маршрутизаторы.

WH>А ты уверн что ты на банальный лоадбалансер не нарвался?
WH>Их в гугле должно быть много.
Нет. Заметь, что они ещё в трассе задолго до Google'а. Т.е. это и есть load ballancing и multipath, но уже прямо на уровне IP. Можешь поспрашивать сетевиков, такой подход — достаточно частая практика.

Причём оно работает настолько хорошо, что ты даже об этом не знаешь.

C>>Предложенный автором вариант подходит в реальности только для статического контента. Этакий eDonkey на стероидах

WH>В реальности для динамического он тоже подходит что автор и продемонстрировал при помощи VoCCN.
Уже ответил.

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

К примеру: http://en.wikipedia.org/wiki/MPLS_local_protection
Sapienti sat!
Re[9]: Content-Centric Networking (CCN)
От: frogkiller Россия  
Дата: 18.11.09 21:42
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, frogkiller, Вы писали:


F>>Внимание, вопрос — две ноды ответили по-разному, какое поведение корректное? Если данные оказались маленьние, что поместились в 1 пакет, peer'у будет очень проблематично определить подмену.

WH>peer подпись проверит.

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

F>>Ну вот представь, у тебя сеть не из двух трёх машин, а из нескольких тысяч. Анонсы больших маршрутизаторов занимают определённое время — по факту секунды, даже десятки секунд. В это время у тебя сеть находится в неопределённом состоянии — ты должен помнить, как это, например, выглядит в Я., и что при этом происходит.

WH>В том то и прикол что все будет хорошо.
WH>В данном случае вообще никаких анонсов небыло. Просто случился таймаут и нода отправила запрос по другому пути.

Откуда нода узнала о существовании другого пути? Статически зарание прописали и опросили доступность? Ха! Если б в реальной жизни всё так просто было...

F>>Если же адресация будет символьной/(с неопределённой структурой) это время, полагаю, возрастёт на порядок даже для самых крутых маршрутизаторов.

WH>Не думаю что время обновления будет заметно отличатся от IPv6.
WH>Ибо не с чего.

Как раз есть с чего — нефиксированная структура адреса, и главное — значительно более сложно выбирать маршруты.

F>>Ну вот с такого. Была у тебя одна нода, потом раз — и появилась ещё одна с частью контента исходной.

WH>Замечательно. Больше путей доставки.

F>>Во-первых, появилась — не мгновенно, а за вполне ощутимое время (см. выше),

WH>Конкретная нода через которую ходит узнает о новой ноде в вполне конкретный момент времени.
WH>Так что она появилась сразу.

У меня складывается впечатление, что ты думаешь, что живёшь в идеальном мире Нужно рассматривать не одну ноду изолированно и с предположением, что за её пределами всё хорошо, а потом по индукции "доказать" что хорошо будет везде. Такой вариант может быть только на полносвязной топологии сети. В действительности же всё несколько хуже. Я уже назвал порядок времени, которое требуется для анонса нового маршрута в реальных системах с реальной топологией. В случае CCN информации, которую нужно передать между нодами будет существенно больше — и она будет более сложной по структуре. Следовательно данное действие также будет занимать сущетсвенно больше времени.

F>>а во-вторых, сколько-то времени уйдёт, прежде чем система поймёт, например, что контент на новой ноде содержит ошибки.

WH>Достаточно проверить подпись.
WH>Плюс возможно реализовать протокол обратного распространения информации об ошибках. Те если нода засекла ошибку то она может не только дропнуть свой пакет но и сказать той ноде откуда она его получила что у нее ошибка.
WH>Ноды которые производят много битых пакетов будут попадать в конец очереди маршрутизации вплоть до бана.

Это довольно сложная логика. Ну не надо её делать на таком низком уровне.

F>>А ещё хуже, если она будет "мигать". Всё это время по факту не будет работать вся система, включая исходный сервис.

WH>Мигание вообще не проблема.
WH>Ибо протокол имеет возможность направлять один и тот же запрос по нескольким путям.
WH>Собственно в опыте с VoCCN как раз мигание и было.
WH>Протокол все разрулил чисто на таймаутах.

Не, в том опыте было не мигание, а переключение — таймауты были гораздо меньше времени между переключениями. И, кстати, всегда RTO >= 3 сек, а в опыте таймауты были значительно меньше. Имхо опыт получается несколько искусственным.

F>>Как уже говорили выше по ветке, шифрование сильно помешает "скукорживанию", поскольку каждый кусок будет уникальным.

WH>Шифруется малая часть контента.
WH>Большую часть шифрованного контента можно шифровать так что скукорживанию это не помешает.

Это как так? Если его можно "скукоржить", значит, он стистически неравномерен, и чем больше его можно сжать — тем легче взломать.

F>>И вообще — чем по сути это отличается от обычного броадкаста?

WH>Покажи мне броадкаст на весь интернет.

И здесь это отнюдь не на весь интернет.

F>>При том, что основная (и не решённая до сих пор) проблема — это поддержание системы в согласованном состоянии. Базворды типа master|slave я упомянул из-за сильного сходства проблем, с которыми придётся столкнуться создателям CCN при хоть сколько-нибудь большой нагрузке, с теми, которые имеют место, например при синхронизации БД. Эти проблемы не исчезнут от того, что их с вершины стека протоколов перенесут в середину или в низ. При этом имхо ситуация даже будет хуже.

WH>Что за проблемы.
WH>Давай конкретно.
WH>Ибо я понимаю все прелести синхронизации БД не не понимаю причем тут CCN?

Ещё раз — проблемы имеют одну и ту же природу — требуется поддержание согласованного состояния сложных структур. Уж извини, не буду на пальцах показывать: этот байт сюда, этот сюда, здесь поменялось, отсюда спросили — кручу-верчу, какой где. Если моё объяснение в прошлом посте не устраивает — я не знаю, как по другому объяснить, не нарисовав кучи диаграмм Флаг в руки, поднимай CCN — уверен, в случае с числом нод > 10 ты во всей красе всё ощутишь.

F>>то это явно уже задача более высокого уровня, не находишь?

WH>Нет. Не нахожу.
WH>Ибо сеть у нас ориентирована не на соединения, а не контент и по этому должна гарантировать сохранность этого самого контента.

Имхо ты сам себе противоречишь. CCN — протокол не контента, а соединения, в котором есть фичи для управления этим соединением, на основе контента. Не так?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[11]: Content-Centric Networking (CCN)
От: CreatorCray  
Дата: 19.11.09 07:02
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Другими словами ты считаешь что freenet уязвим?

Что такое freenet? И как он относится к тому, что ты предлагаешь ослабить шифрование контента ради непонятной выгоды ("чтобы можно было скукорживать").
Если уж трафик зашифрован это означает что его хотят защитить.

WH> А можно послушать техническое обоснование?

Берешь любую книгу по криптографии и читаешь.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Content-Centric Networking (CCN)
От: CreatorCray  
Дата: 19.11.09 07:02
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, CreatorCray, Вы писали:


CC>>Это только если у нас один источник и куча получателей, синхронизированые между собой. Т.е. ключ и IV у них у всех одинаковый.

WH>Я так думаю это верно в подавляющем большинстве случаев.
Это будет верно только если программеры наплевали на все security guidelines и реализовали шифрование через задницу.
Шифрование появляется там, где надо защитить контент.

WH>И в еще большем количестве случаев вообще никакого шифрования не будет.

Но мы то сейчас обсуждаем твоё "WH>Шифрование не мешает скукорживать трафик."

CC>>Да и то это получается обычный броадкаст.

WH>Нука продемонстрируй мне броадкаст на весь интернет?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Content-Centric Networking (CCN)
От: WolfHound  
Дата: 19.11.09 07:31
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Любое состояние на магистральных роутерах уже неприемлимо. Они часто вообще реализуют switching logic прямо в железе, даже не в микрокоде.

А таблицы маршрутизации у них тоже прямо в железе прошиты?

WH>>Ну IP пакеты тоже не так уж просто маршрутизировать.

C>ОЧЕНЬ просто. Ты идёшь по таблице маршрутов и проверяешь маски (понятно, что оно немного сложнее в реальности).
Вот тут тоже будет примерно также.

WH>>Как формат пакетов влияет на DDoS?

C>Посылаем небольшой пакет с фальсифицированного адреса, а в ответ приходит тонна информации.
Понятно. Про протокол ничего не читал, но осуждаешь...
1)Обратного адреса нет. Фальсифицировать нечего.
http://www.ccnx.org/releases/latest/doc/technical/InterestMessage.html
http://www.ccnx.org/releases/latest/doc/technical/ContentObject.html
2)На один запрос приходит не более одного ответа. Те тонны информации не будет в любом случае.
3)Запросы и ответы идут по одному и тому же маршруту. Все что нужно сделать роутеру чтобы обнаружить и удавить ДоС это считать отношение запросов и полученных ответов для конкретного фейса. Фейсов у роутера не много.

C>Это решается для практических задач элементарно — посылаем "сигнальную информацию" (хэш очередного пакета) по TCP, а дальше используем обычный DHT.

VoIP через DHT. Да ты хоть представляешь с какой скоростью эта самая DHT работает?
Это даже не смешно.

C>Это всё имеет смысл, если есть кэширующие серверы. Т.е. для вещей типа роликов на YouTube, чтобы очередной вирусный ролик брался из ближайшего кэша, а не летел из США.

Это примерно 90% трафика в сети...

C>А для VOiP лучше использовать уже существующие технологии.

Не уверен. VoCCN получается проще, гибче и может масштабироваться.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[5]: Content-Centric Networking (CCN)
От: Cyberax Марс  
Дата: 19.11.09 07:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

C>>Любое состояние на магистральных роутерах уже неприемлимо. Они часто вообще реализуют switching logic прямо в железе, даже не в микрокоде.

WH>А таблицы маршрутизации у них тоже прямо в железе прошиты?
Ага. Они прямо в железо в аналоги регистров загоняются.

Понятное дело, что я не говорю об управляющих каналах, изменения таблиц маршрутизации проходят по обычному BGP через TCP/IP.

WH>>>Ну IP пакеты тоже не так уж просто маршрутизировать.

C>>ОЧЕНЬ просто. Ты идёшь по таблице маршрутов и проверяешь маски (понятно, что оно немного сложнее в реальности).
WH>Вот тут тоже будет примерно также.
Примерно, да не такое.

C>>Посылаем небольшой пакет с фальсифицированного адреса, а в ответ приходит тонна информации.

WH>Понятно. Про протокол ничего не читал, но осуждаешь...
WH>1)Обратного адреса нет. Фальсифицировать нечего.
Как нет? А куда ответ-то пойдёт? Вот пришёл на сервер TheGlobalServer запрос на объект с ключом SAJHASKJDHAKSJDH, как будет выглядеть ответ на сетевом уровне?

WH>2)На один запрос приходит не более одного ответа. Те тонны информации не будет в любом случае.

WH>3)Запросы и ответы идут по одному и тому же маршруту. Все что нужно сделать роутеру чтобы обнаружить и удавить ДоС это считать отношение запросов и полученных ответов для конкретного фейса. Фейсов у роутера не много.
Сейчас глобальная таблица BGP содержит что-то около 300000 аннонсированых префиксов. Которые постоянно меняются. Как будем DDoS обнаруживать?

C>>Это решается для практических задач элементарно — посылаем "сигнальную информацию" (хэш очередного пакета) по TCP, а дальше используем обычный DHT.

WH>VoIP через DHT. Да ты хоть представляешь с какой скоростью эта самая DHT работает?
WH>Это даже не смешно.
А нафиг VoIPу DHT?

C>>Это всё имеет смысл, если есть кэширующие серверы. Т.е. для вещей типа роликов на YouTube, чтобы очередной вирусный ролик брался из ближайшего кэша, а не летел из США.

WH>Это примерно 90% трафика в сети...
Оптимистично.

C>>А для VOiP лучше использовать уже существующие технологии.

WH>Не уверен. VoCCN получается проще, гибче и может масштабироваться.
Не может. У них даже в идеальном случае уже потери пакетов идут.
Sapienti sat!
Re[6]: Content-Centric Networking (CCN)
От: WolfHound  
Дата: 19.11.09 07:51
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Нет. Заметь, что они ещё в трассе задолго до Google'а. Т.е. это и есть load ballancing и multipath, но уже прямо на уровне IP. Можешь поспрашивать сетевиков, такой подход — достаточно частая практика.

C>Причём оно работает настолько хорошо, что ты даже об этом не знаешь.
Если бы...
Я с такими железками дело имел.
Они не спасают если:
1)Сервер умер посередине ответа даже если отдавалась статика и ее можно взять с соседнего.
2)Некоторое время после смерти сервера балансировщик продолжает гнать на него новые запросы. Те получаем еще кучу народа которые получат облом.
3)Если сервер ушел в кому те принимает соединения и не отвечает то балансировщик так и будет отправлять на него запросы. Те без ответов останется куча народа.

C>Да, в реальных телефонных сетях, где нужно гарантировать качество, используются более другие подходы для обеспечения надёжности.

C>К примеру: http://en.wikipedia.org/wiki/MPLS_local_protection
ГЫ! CCN так умеет. Достаточно на уровне стратегий реализовать соответствующее поведение.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Content-Centric Networking (CCN)
От: WolfHound  
Дата: 19.11.09 08:24
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>А с подписью и в случае сбоя/атаки всё нормально будет — ведь подписываться часть будет после доставки на ноду — иначе тебе потребуется очень большая куча ненужных действий и операция подписвания несколько нелинейна.

Каждое слово в отдельности понятно. Но все вместе

F>Опять-таки — проверять подпись кадого пакета — это проще убиться сразу, чтоб не мучиться. Проверять подпись всех данных — задача более высокого уровня.

Вот представь себе качаешь ты гиг данных и пара пакетов пришла побитой... Что будешь сначала качать?
Кстати посмотри на торенты... они примерно тем же самым и занимаются.

F>Откуда нода узнала о существовании другого пути? Статически зарание прописали и опросили доступность? Ха! Если б в реальной жизни всё так просто было...

А откуда маршрутизаторы узнают о пути?
Тут все тоже самое. Только путей может быть больше одного.

F>Как раз есть с чего — нефиксированная структура адреса,

И че?

F>и главное — значительно более сложно выбирать маршруты.

Не вижу с чего бы.

WH>>Плюс возможно реализовать протокол обратного распространения информации об ошибках. Те если нода засекла ошибку то она может не только дропнуть свой пакет но и сказать той ноде откуда она его получила что у нее ошибка.

WH>>Ноды которые производят много битых пакетов будут попадать в конец очереди маршрутизации вплоть до бана.
F>Это довольно сложная логика.
Чего в ней сложного?

F>Ну не надо её делать на таком низком уровне.

А на каком уровне это делать?

F>Не, в том опыте было не мигание, а переключение — таймауты были гораздо меньше времени между переключениями. И, кстати, всегда RTO >= 3 сек, а в опыте таймауты были значительно меньше. Имхо опыт получается несколько искусственным.

Чего в нем искусственного?
Уровень стратегий волен выбирать маршруты как ему вздумается.
Если он решил что на одном из маршрутов пошли тормоза он тут же переключился на другой.
Более того если ты посмотришь на график то увидишь что были случае когда маршруты переключались спонтанно после экспериментов уровня стратегий с посылкой запроса сразу по двум маршрутам.

F>Это как так? Если его можно "скукоржить", значит, он стистически неравномерен, и чем больше его можно сжать — тем легче взломать.

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

F>>>И вообще — чем по сути это отличается от обычного броадкаста?

WH>>Покажи мне броадкаст на весь интернет.
F>И здесь это отнюдь не на весь интернет.
Именно что на весь но только тем кто хочет эти данные.

F>Ещё раз — проблемы имеют одну и ту же природу — требуется поддержание согласованного состояния сложных структур.

Вот не понимаю откуда ты это требование выкопал.

F>Флаг в руки, поднимай CCN — уверен, в случае с числом нод > 10 ты во всей красе всё ощутишь.

Ну раз технические аргументы закончились и пошло ИМХО на ИМХО то тебе придется спорить с ним http://en.wikipedia.org/wiki/Van_Jacobson

F>Имхо ты сам себе противоречишь. CCN — протокол не контента, а соединения, в котором есть фичи для управления этим соединением, на основе контента. Не так?

Цитату в студию.
Ибо все что я читал про CCN ни про какие соединения ничего не содержит.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Content-Centric Networking (CCN)
От: WolfHound  
Дата: 19.11.09 08:36
Оценка:
Здравствуйте, CreatorCray, Вы писали:

WH>>Другими словами ты считаешь что freenet уязвим?

CC>Что такое freenet?
Тебя в гугле забанили?
http://en.wikipedia.org/wiki/Freenet

CC>И как он относится к тому, что ты предлагаешь ослабить шифрование контента ради непонятной выгоды ("чтобы можно было скукорживать").

Ну почитай про модель защиты контента freenet'ом поймешь.
Если коротко то там ключ для шифрования файла генерируют на основе хеша от не зашифрованного файла.
Таким образом если два файла отличаются одним битом то в зашифрованном виде они будут полностью разными.
Но если файлы одинаковые то во freenet они попадут одинаковыми даже если их туда загрузили разные люди в разное время.
В такой модели трафик прекрасно скукорживается CCN'ом.

CC>Если уж трафик зашифрован это означает что его хотят защитить.

Только это не мешает скукорживанию.

WH>> А можно послушать техническое обоснование?

CC>Берешь любую книгу по криптографии и читаешь.
Ты выдвинул тезис тебе его и доказывать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Content-Centric Networking (CCN)
От: WolfHound  
Дата: 19.11.09 09:16
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Ага. Они прямо в железо в аналоги регистров загоняются.

А регистры это у нас уже не состояние?

C>Как нет? А куда ответ-то пойдёт? Вот пришёл на сервер TheGlobalServer запрос на объект с ключом SAJHASKJDHAKSJDH, как будет выглядеть ответ на сетевом уровне?

Из какого фейса пришел в тот и уйдет.

C>Сейчас глобальная таблица BGP содержит что-то около 300000 аннонсированых префиксов. Которые постоянно меняются. Как будем DDoS обнаруживать?

Причем тут вообще BGP?
Обнаружение идет чисто локально.
Если некий фейс генерирует кучу интересов на которые не приходят объекты с данными значит этот фейс пытается досить.
Если досить запросами существующих данных то эти данные просто расползутся по кешам и опять никакого ДДоСа не получится.

C>>>Это решается для практических задач элементарно — посылаем "сигнальную информацию" (хэш очередного пакета) по TCP, а дальше используем обычный DHT.

WH>>VoIP через DHT. Да ты хоть представляешь с какой скоростью эта самая DHT работает?
WH>>Это даже не смешно.
C>А нафиг VoIPу DHT?
Это у тебя нужно спросить. Ибо именно ты притянул DHT к VoIP. См выделенное.

WH>>Это примерно 90% трафика в сети...

C>Оптимистично.
Я эту цифру взял у Van Jacobson'а.

WH>>Не уверен. VoCCN получается проще, гибче и может масштабироваться.

C>Не может. У них даже в идеальном случае уже потери пакетов идут.
1)Потери пакетов небыло.
2)Случай далеко не идеальный.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Content-Centric Networking (CCN)
От: Pavel Dvorkin Россия  
Дата: 19.11.09 09:21
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Если IP заточен на разговор 2х машин то CCN'у нет дела до конкретных машин. Он построен вокруг именованных данных.

WH>Те запросы идут не к машине с адресом ХХХХХХ, а к сети и выглядят как: Дай мне данные с таким то именем.

DFS (Distributed File System) ? Построен вокруг именованных в сети данных, запросы идут к этим данным куда-то в сеть, куда — вообще-то и не знаю. Более того, имена еще и иерархично построены. Конечно, уровень не тот, но сама идея похожа. Она, кстати, в домене Windows давно существует.
With best regards
Pavel Dvorkin
Re[9]: Content-Centric Networking (CCN)
От: CreatorCray  
Дата: 19.11.09 10:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>В данном случае вообще никаких анонсов небыло. Просто случился таймаут и нода отправила запрос по другому пути.

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

F>>Во-первых, появилась — не мгновенно, а за вполне ощутимое время (см. выше),

WH>Конкретная нода через которую ходит узнает о новой ноде в вполне конкретный момент времени.
WH>Так что она появилась сразу.
Не похоже. Впрочем реализуют — увидим. А пока теоретизировать нет смысла.

WH>Ноды которые производят много битых пакетов будут попадать в конец очереди маршрутизации вплоть до бана.

Они хотят переизобрести торрент?

WH>Большую часть шифрованного контента можно шифровать так что скукорживанию это не помешает.

Еще раз тебе говорю: это глупость!

F>>И вообще — чем по сути это отличается от обычного броадкаста?

WH>Покажи мне броадкаст на весь интернет.
Кому нафиг надо броадкаст на весь интернет?

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

WH>По крайней мере все что находил я не выдерживало критики при вдумчивом анализе.
Люди есть люди, и они совершают ошибки.
Давай подождем версию, работающую не в тепличных условиях.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Content-Centric Networking (CCN)
От: CreatorCray  
Дата: 19.11.09 10:13
Оценка:
Здравствуйте, Cyberax, Вы писали:

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.

Ух какой [censored]!!!
Этож вообще капец! Нахрен такие протоколы.
А то инетокапец наступит досрочно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[11]: Content-Centric Networking (CCN)
От: frogkiller Россия  
Дата: 19.11.09 10:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

F>>Опять-таки — проверять подпись кадого пакета — это проще убиться сразу, чтоб не мучиться. Проверять подпись всех данных — задача более высокого уровня.

WH>Вот представь себе качаешь ты гиг данных и пара пакетов пришла побитой... Что будешь сначала качать?
WH>Кстати посмотри на торенты... они примерно тем же самым и занимаются.

Ну дык, я как раз и говорю, что это дело не транспорта, а приложения.

F>>Откуда нода узнала о существовании другого пути? Статически зарание прописали и опросили доступность? Ха! Если б в реальной жизни всё так просто было...

WH>А откуда маршрутизаторы узнают о пути?
WH>Тут все тоже самое. Только путей может быть больше одного.
F>>Как раз есть с чего — нефиксированная структура адреса,
WH>И че?
F>>и главное — значительно более сложно выбирать маршруты.
WH>Не вижу с чего бы.
WH>>>Плюс возможно реализовать протокол обратного распространения информации об ошибках. Те если нода засекла ошибку то она может не только дропнуть свой пакет но и сказать той ноде откуда она его получила что у нее ошибка.
WH>>>Ноды которые производят много битых пакетов будут попадать в конец очереди маршрутизации вплоть до бана.
F>>Это довольно сложная логика.
WH>Чего в ней сложного?
F>>Ну не надо её делать на таком низком уровне.
WH>А на каком уровне это делать?

OSPF и далее по ссылкам.

F>>Ещё раз — проблемы имеют одну и ту же природу — требуется поддержание согласованного состояния сложных структур.

WH>Вот не понимаю откуда ты это требование выкопал.

Откуда-откуда — жизнь такая. Несколько лет назад я делал что-то отдалённо похожее, правда поверх tcp. Эта штука может быть очень полезна в отдельно взятых задачах, но не более. Ну никак она не может быть заменой tcp/ip — слишком сложные проблемы у такой архитектуры. Оттого, что кто-то эти проблемы игнорирует, они не исчезнут.

F>>Флаг в руки, поднимай CCN — уверен, в случае с числом нод > 10 ты во всей красе всё ощутишь.

WH>Ну раз технические аргументы закончились и пошло ИМХО на ИМХО то тебе придется спорить с ним http://en.wikipedia.org/wiki/Van_Jacobson

Делать мне больше нечего как с кем-то спорить. Я высказал своё мнение, услышали — хорошо, не услышали или не поняли — ну что я могу поделать

F>>Имхо ты сам себе противоречишь. CCN — протокол не контента, а соединения, в котором есть фичи для управления этим соединением, на основе контента. Не так?

WH>Цитату в студию.
WH>Ибо все что я читал про CCN ни про какие соединения ничего не содержит.

Целый набор цитат:

CCN provides an
excellent vehicle to implement a routing protocol’s transport: at the
heart of most routing transport protocols is something very simi-
lar to CCN’s information-oriented guided-diffusion flooding model
since they have to function in the pre-topology phase of networking
where peer identities and locations are not known.

There is a behavioral difference between IP and CCN in what
happens when there are multiple announcements of the same pre-
fix. In IP any particular node will send all matching traffic to ex-
actly one of the announcers. In CCN all nodes send all matching
interests to all of the announcers. This arises from a semantic dif-
ference: An IP prefix announcement from some IGP router says
“all the hosts with this prefix can be reached via me”. The equiv-
alent announcement from a CCN router says “some of the content
with this prefix can be reached via me”. Since IP has no way of
detecting loops at the content level, it is forced to construct loop-
free forwarding topologies, i.e., a sink tree rooted at the destination.
Since a tree has a single path between any two nodes, an IP FIB has
only one slot for ‘outgoing interface’. So all the hosts associated
with a prefix have to be reachable via the node announcing a pre-
fix because all traffic matching the prefix will be sent to that node.


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

As described in Section 2, CCN explicitly models multiple con-
nectivity via per-FIB-entry face lists. Since there is no one-size-
fits-all strategy for using multiple faces, the design intent is for
each CCN FIB entry to contain a program, written for an abstract
machine specialized to forwarding choices, that determines how to
forward Interests. The ‘instructions’ for this machine should in-
clude a small subset of the normal load/store, arithmetic, and com-
parison operators plus actions that operate on sets of faces such
as sendToAll, sendToBest, markAsBest, and triggers such as inter-
estSatisfied, interestTimedOut, faceDown that can be used to in-
voke lists of actions when significant events occur. Faces will have
an (open-ended) set of attributes such as BroadcastCapable, is-
ContentRouter, UsageBasedCharging, PeakUseLimited that can be
used to dynamically construct the sets for use by the actions.


Это один-в-один повторяет то, что я делал несколько лет назад — ну не нужно для этого чего-то хитрого на нижнем уровне.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re[13]: Content-Centric Networking (CCN)
От: CreatorCray  
Дата: 19.11.09 12:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>>>Другими словами ты считаешь что freenet уязвим?

CC>>Что такое freenet?
WH>Тебя в гугле забанили?
Не, работы много, некогда надолго отвлекаться.

WH>Если коротко то там ключ для шифрования файла генерируют на основе хеша от не зашифрованного файла.

А как генерят IV?

WH>Таким образом если два файла отличаются одним битом то в зашифрованном виде они будут полностью разными.

Соответственно одинаковые файлы будут одинаковыми.
Для чего они их шифруют тогда?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[7]: Content-Centric Networking (CCN)
От: Cyberax Марс  
Дата: 19.11.09 12:54
Оценка: +2
Здравствуйте, WolfHound, Вы писали:

C>>Ага. Они прямо в железо в аналоги регистров загоняются.

WH>А регистры это у нас уже не состояние?
Как бы нет. Кое-кто вообще на лету перестраивает FPGA для маршрутизации (т.е. логика обхода дерева маршрутизации вообще в железо забивается). Т.е. роутеру пофиг что там в пакетах, оно относительно сетевого траффика является stateless.

Через магистральные роутеры сейчас проходит часто по 100ГБит. Если на каждый килобайт данных записывать по 64 байта, то никакой памяти не хватит.

C>>Как нет? А куда ответ-то пойдёт? Вот пришёл на сервер TheGlobalServer запрос на объект с ключом SAJHASKJDHAKSJDH, как будет выглядеть ответ на сетевом уровне?

WH>Из какого фейса пришел в тот и уйдет.
Низзя. Ты забываешь про циклы, load ballancing, route flapping, policy routing и т.д.

К примеру, ответ может быть необходимо пустить через другой интерфейс.

WH>>>Это даже не смешно.

C>>А нафиг VoIPу DHT?
WH>Это у тебя нужно спросить. Ибо именно ты притянул DHT к VoIP. См выделенное.
Ну и CCN нафиг.

Кстати, BitTorrent _уже_ адаптировали для online-трансляций.

WH>>>Не уверен. VoCCN получается проще, гибче и может масштабироваться.

C>>Не может. У них даже в идеальном случае уже потери пакетов идут.
WH>1)Потери пакетов небыло.
Было. По таймауту.

WH>2)Случай далеко не идеальный.

Абсолютно идеальный. В рельности всё жёстче.
Sapienti sat!
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.