Наткнулся тут на интересный проект http://www.ccnx.org/ Автора похоже окончательно достал IP протокол и он решил придумать ему замену.
Причем подход к архитектуре сети был выбран фундаментально иным нежели предлагает IP.
Если IP заточен на разговор 2х машин то CCN'у нет дела до конкретных машин. Он построен вокруг именованных данных.
Те запросы идут не к машине с адресом ХХХХХХ, а к сети и выглядят как: Дай мне данные с таким то именем.
И клиенту совершенно все равно кто именно отдаст эти данные.
Роутерам разрешено кешировать ответы что приводит к тому что если 2 или более машин из локальной сети запросили одни и те же данные то наружу уйдет один запрос. И так будет на каждом CCN роутере. Как следствие всякие youtube'ы больше не будут ставить раком весь интернет плюс нагрузка на серверы резко снизится.
VoCCN тоже возможен. Причем он получился даже проще, гибче и вероятно надежнее чем VoIP.
Минус этого протокола в том что он понимает только pull семантику. А вот с push придется извращаться. Придется делать запрос который пнет сервер чтобы он запросил у клиента данные.
Еще одна засада это то что существующим приложениям которые работают с сетью придется даже не переписывать сетевое взаимодействие, а полностью менять его философию чтобы полностью раскрыть потенциал CCN'а.
Но идея в целом мне нравится.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Если IP заточен на разговор 2х машин то CCN'у нет дела до конкретных машин. Он построен вокруг именованных данных. WH>Те запросы идут не к машине с адресом ХХХХХХ, а к сети и выглядят как: Дай мне данные с таким то именем. WH>И клиенту совершенно все равно кто именно отдаст эти данные.
CORBA?
Имхо, не взлетит.
Во-первых, потому, что смена нынешней архитектуры везде на принципиально новую будет стоить ну просто невообразимую сумму, а в отдельно взятой "квартире" смысла в этом никакого нет.
Во-вторых, сама идея мне представляется сомнительной — при внешней красоте она потребует значительно больших внутренних затрат на синхронизацию — чтобы в случая сбоя вся система целиком находилась в согласованном состоянии.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, WolfHound, Вы писали:
WH>Наткнулся тут на интересный проект http://www.ccnx.org/ WH>Автора похоже окончательно достал IP протокол и он решил придумать ему замену. WH>Причем подход к архитектуре сети был выбран фундаментально иным нежели предлагает IP. WH>Если IP заточен на разговор 2х машин то CCN'у нет дела до конкретных машин. Он построен вокруг именованных данных. WH>Те запросы идут не к машине с адресом ХХХХХХ, а к сети и выглядят как: Дай мне данные с таким то именем. WH>И клиенту совершенно все равно кто именно отдаст эти данные. WH>Роутерам разрешено кешировать ответы что приводит к тому что если 2 или более машин из локальной сети запросили одни и те же данные то наружу уйдет один запрос. И так будет на каждом CCN роутере. Как следствие всякие youtube'ы больше не будут ставить раком весь интернет плюс нагрузка на серверы резко снизится. WH>VoCCN тоже возможен. Причем он получился даже проще, гибче и вероятно надежнее чем VoIP.
WH>Минус этого протокола в том что он понимает только pull семантику. А вот с push придется извращаться. Придется делать запрос который пнет сервер чтобы он запросил у клиента данные.
Здравствуйте, frogkiller, Вы писали:
F>CORBA?
Нет. Не корба.
Тут в отличии от корбы контент неизменяемый.
Те на один и тот же запрос сервер должен отдавать один и тот же ответ.
F>Имхо, не взлетит.
А выбора нет... иначе сеть упадет.
F>Во-первых, потому, что смена нынешней архитектуры везде на принципиально новую будет стоить ну просто невообразимую сумму, а в отдельно взятой "квартире" смысла в этом никакого нет.
CNN умеет жить поверх IP... Те инфраструктуру можно поднимать параллельно причем на том же железе. Знай себе меняй прошивки роутерам.
И туннели (UDP обыкновенный) через IP сеть тоже никто не отменял.
F>Во-вторых, сама идея мне представляется сомнительной — при внешней красоте она потребует значительно больших внутренних затрат на синхронизацию — чтобы в случая сбоя вся система целиком находилась в согласованном состоянии.
А подробней? Ибо с моей точки зрения оно будет надежнее.
Кстати их издевательства над VoCCN прекрасно показывают насколько хорошо CCN маскирует сбои.
Смотри этот документ http://www.parc.com/content/attachments/networking-named-content-preprint2.pdf на 10ой странице.
Еще одна плюшка CCN'а в том что он в сравнении с IP не имеет проблем с мобильными устройствами.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Наткнулся тут на интересный проект http://www.ccnx.org/
Самому лень читать, зато может быть тебе будет интересно
Вот ещё такой товарищ схожими вещами занимается: http://www.inf.usi.ch/carzaniga/
Там у него куча публикаций и даже какой-то вроде софт есть.
Здравствуйте, gandjustas, Вы писали:
G>Помоему это HTTP на сетевом уровне.
А что HTTP уже поддерживает множественные пути доставки?
Поддерживает интерактивную работу без страшных хаков типа COMET?
Или может быть в HTTP завелись широковещательные рассылки?
А как насчет встроенной в протокол проверки целостности и подлинности данных?
...
Короче на HTTP оно маленько походит но не более того.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, gandjustas, Вы писали:
G>>Помоему это HTTP на сетевом уровне. WH>А что HTTP уже поддерживает множественные пути доставки?
Вообще да. Каждый запрос на один и тот же ресурс может быть обработан разными серверами (цепочкой прокси).
WH>Поддерживает интерактивную работу без страшных хаков типа COMET?
Ну так сам же сказал что с push проблемы, аналогично и для http.
WH>Или может быть в HTTP завелись широковещательные рассылки?
Ну HTTP как бы протокол другого уровня.
WH>А как насчет встроенной в протокол проверки целостности и подлинности данных?
Это накручивается поверх HTTP.
WH>Короче на HTTP оно маленько походит но не более того.
Ну настолько насколько может протокол сетевого уровня походить на протокол уровня прикладного.
Здравствуйте, gandjustas, Вы писали:
G>Вообще да. Каждый запрос на один и тот же ресурс может быть обработан разными серверами (цепочкой прокси).
Не все так просто.
Если сервер рухнет во время обработки сообщения то в случае с HTTP пользователь получит фигу, а в случае с CCN машина пользователя может даже не узнать что где-то там что-то упало.
G>Ну так сам же сказал что с push проблемы, аналогично и для http.
С push проблема ровно одна: Клиент должен попросить сервер вытянуть с него данные.
В случае с HTTP приходится городить один большой хак.
G>Это накручивается поверх HTTP.
Практика показывает что поверх чего угодно можно накрутить что попало.
Вот только это накручивание инфраструктура поддерживать не будет.
G>Ну настолько насколько может протокол сетевого уровня походить на протокол уровня прикладного.
Дались тебе эти уровни... практика показывает что разобрать где какой уровень на практике весьма не просто.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, SergH, Вы писали:
SH>Самому лень читать, зато может быть тебе будет интересно
Я конечно еще почитаю но оно как-то подозрительно выглядит:
2 Model of a Content-Based Network
We model a content-based network as a finite connected undirected (Вот так прямо и не ориентированный?) graph G = (V,E) where a vertex v ∈ V represents a processor and an edge e ∈ E represents a reliable (они где надежные каналы видели?) bidirectional (а что широковещательные рассылки отменили?) communication link between two processors. Without loss of generality, we assume that a processor acts both as a host, producing and consuming messages, and as a router, forwarding messages on behalf of other processors. We assume that processors are given numeric identifiers, so hereafter we let n = |V | and V = {1, . . . , n}.
Плюс предикаты какие то да и написано оно так чтобы никто не понял о чем речь... те расшифровывать придется. Мануалы по зависимым типам и то проще читаются.
Короче очень сильно на сферолошадь походит.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH> G>Вообще да. Каждый запрос на один и тот же ресурс может быть обработан разными серверами (цепочкой прокси).
WH> Не все так просто. WH> Если сервер рухнет во время обработки сообщения то в случае с HTTP пользователь получит фигу, а в случае с CCN машина пользователя может даже не узнать что где-то там что-то упало.
Pависит от сервера. Потому что CDN'ы и вообще cloud-сервисы расчитаны на то, что где-то что-то упадет
Здравствуйте, WolfHound, Вы писали:
WH>Я конечно еще почитаю но оно как-то подозрительно выглядит:
Х.з., я не вдавался в его научную деятельность. Просто знаю, что чем-то таким занимается.
Я его лично видел, мне очень понравилось, как он лекции по сетям читает (по обычным TCP). И сам он тоже очень понравился.
WH>We model a content-based network as a finite connected undirected (Вот так прямо и не ориентированный?)
Ну, связи двусторонние. Пакетики в обе стороны ходят.
WH>graph G = (V,E) where a vertex v ∈ V represents a processor and an edge e ∈ E represents a reliable (они где надежные каналы видели?)
Этого не знаю.
WH>bidirectional (а что широковещательные рассылки отменили?)
Э, про адреса ничего не было. Ты же можешь отправить сразу по всем. Или они могут пересылать друг другу. Или ты про коаксиальный кабель, к которому подсоединены сразу много машин? Во-первых, не актуально, во-вторых, можно моделировать его узлом.
WH>Короче очень сильно на сферолошадь походит.
Это вполне возможно.
Множество хороших мужиков и множество хороших исследователей пересекаются, но не совпадают (даже если не считать женщин).
Здравствуйте, Mamut, Вы писали:
M>Pависит от сервера. Потому что CDN'ы и вообще cloud-сервисы расчитаны на то, что где-то что-то упадет
Не зависит. Это я тебе как бывший разработчик подобных сервисов говорю.
Замаскировать 100% сбоев в случае с HTTP можно только если этим будет заниматься клиент.
Ты что ни разу не видел как закачка файлика обламывалась на середине? Так вот: абсолютно тоже самое может произойти с чем угодно.
И ни HTTP ни TCP/IP ни какие серверные навороты тут не помогут.
А в CCN разруливание таких ситуаций заложено в самый фундамент.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH> Замаскировать 100% сбоев в случае с HTTP можно только если этим будет заниматься клиент. WH> Ты что ни разу не видел как закачка файлика обламывалась на середине? Так вот: абсолютно тоже самое может произойти с чем угодно. WH> И ни HTTP ни TCP/IP ни какие серверные навороты тут не помогут. WH> А в CCN разруливание таких ситуаций заложено в самый фундамент.
Хм. И как же будет разруливаться ситуация с той же закачкой файлов (кстати, закачка — upload или download?)
Здравствуйте, WolfHound, Вы писали:
F>>CORBA? WH>Нет. Не корба. WH>Тут в отличии от корбы контент неизменяемый. WH>Те на один и тот же запрос сервер должен отдавать один и тот же ответ.
Хм... это как-то стрёмно. Даже в случае постоянного контента могут быть случаи, когда нужно совершать разные действия (например, в случае tcp дропать пакеты в случае атаки и т.д.)
F>>Имхо, не взлетит. WH>А выбора нет... иначе сеть упадет.
В смысле? почему сеть должна упасть при нынешней архитектуре и данном стеке протоколов?
F>>Во-вторых, сама идея мне представляется сомнительной — при внешней красоте она потребует значительно больших внутренних затрат на синхронизацию — чтобы в случая сбоя вся система целиком находилась в согласованном состоянии. WH>А подробней? Ибо с моей точки зрения оно будет надежнее. WH>Кстати их издевательства над VoCCN прекрасно показывают насколько хорошо CCN маскирует сбои.
Это только потому, что VoXXX — робастный и избыточный протокол. В случае уникальных данных несогласованность различных частей системы будет гораздо более критичной. В частности это отностится к якобы плюшке с верификацией контента. Чтобы не повторяться — сюда применимы все возражения, которые обычно приводят при критике структуры master/slave. Кстати, насколько я понимаю, сейчас всё больше от неё отходят — тот же gfs по слухам (т.е. источник не помню, а искать несколько лениво ) всё чаще упоминается в конфигурации без slave'ов.
Имхо не стоит вкладывать в низкоуровневый протокол какие-то интеллектуальные вещи, которые должны быть одним-двумя-тремя уровнями выше.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Про протокол как я понимаю ты ничего так и не прочитал.
F>Хм... это как-то стрёмно. Даже в случае постоянного контента могут быть случаи, когда нужно совершать разные действия (например, в случае tcp дропать пакеты в случае атаки и т.д.)
Ну и дропай сколько влезет. Но если решил ответить то позаботься чтобы ответ был тем-же.
F>В смысле? почему сеть должна упасть при нынешней архитектуре и данном стеке протоколов?
По тому что TCP/IP не масштабируется в случае исли большое колличество народа спрашивает один и тот же контент. А по утверждению автора CCN это 90% трафика в современной сети.
И CCN способен этот трафик значительно скукоржить.
F>Это только потому, что VoXXX — робастный и избыточный протокол.
Там до избыточности VoXXX дело не дошло. Все замаскировал CCN.
F>В случае уникальных данных несогласованность различных частей системы будет гораздо более критичной.
А давай ты про протокол почитаешь.
Или видео посмотришь. Оно интересно даже без относительно CCN. Там еще и про историю и эволюцию сети рассказывают.
F>В частности это отностится к якобы плюшке с верификацией контента. Чтобы не повторяться — сюда применимы все возражения, которые обычно приводят при критике структуры master/slave.
Причем тут вообще master/slave?
F>Кстати, насколько я понимаю, сейчас всё больше от неё отходят — тот же gfs по слухам (т.е. источник не помню, а искать несколько лениво ) всё чаще упоминается в конфигурации без slave'ов.
Ты про какой GFS?
F>Имхо не стоит вкладывать в низкоуровневый протокол какие-то интеллектуальные вещи, которые должны быть одним-двумя-тремя уровнями выше.
А что посчитать цифровую подпись уже в интеллектуальные вещи записали? Не знал.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Mamut, Вы писали:
M>Хм. И как же будет разруливаться ситуация с той же закачкой файлов (кстати, закачка — upload или download?)
В CCN всегда download.
А разруливаться будет просто.
Вот стоят 2 сервера с одним и тем же файликом.
Роутер знает что этот файлик можно скачать с обоих серверов.
Теперь этот файлик начал качать некий клиент генерируя кучу запросов вида "хочу кусок файла номер Н".
Сначала роутер все отправлял на сервер 1. На середине закачки сервер номер 1 умер и роутер перестал получать от него ответы.
Выждав некий таймаут но начал переправлять запросы на второй сервер.
Вся инфраструктура которая была до этого роутера ничего не заметила.
С уникальным контентом конечно будут проблемы но тут теоретически ничего не поделать.
С динамическим контентом сложно но при достаточной ловкости рук тоже можно разобраться.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>По тому что TCP/IP не масштабируется в случае исли большое колличество народа спрашивает один и тот же контент. А по утверждению автора CCN это 90% трафика в современной сети.
В современной сети полным полно VPN, SSL, Torrent и прочего шифрованного трафика. Который по определению никакими силами не скукожить.
Ну а вообще вся эта CCN задумка очень похоже на yet another web accelerator.
Здравствуйте, WolfHound, Вы писали:
WH>С динамическим контентом сложно но при достаточной ловкости рук тоже можно разобраться.
С динамическим контентом будет геморрой размером со слона.
С контентом в виде торрентов — полная хана. Там на транспортном уровне весь контент уникальный за счет шифрования.
WH> M>Хм. И как же будет разруливаться ситуация с той же закачкой файлов (кстати, закачка — upload или download?)
WH> В CCN всегда download. WH> А разруливаться будет просто. WH> Вот стоят 2 сервера с одним и тем же файликом. WH> Роутер знает что этот файлик можно скачать с обоих серверов.
Откуда он это знает? Что мешает реализовать это знание в HTTP? Разве что это будет не на уровне «роутер у юзера», а на уровне «роутер у сервера»
WH> Теперь этот файлик начал качать некий клиент генерируя кучу запросов вида "хочу кусок файла номер Н". WH> Сначала роутер все отправлял на сервер 1. На середине закачки сервер номер 1 умер и роутер перестал получать от него ответы. WH> Выждав некий таймаут но начал переправлять запросы на второй сервер. WH> Вся инфраструктура которая была до этого роутера ничего не заметила.
Ну дык, Amazon S3 и сейчас так, емнип, работает. Упал где-то амазоновский сервер, все продолжило качаться
WH> С уникальным контентом конечно будут проблемы но тут теоретически ничего не поделать. WH> С динамическим контентом сложно но при достаточной ловкости рук тоже можно разобраться.
Поправьте меня, если на download точно так же не работают CDN'ы, load-balancer'ы и т.п.
Здравствуйте, 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.
Здравствуйте, 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 лучше использовать уже существующие технологии.
Здравствуйте, WolfHound, Вы писали:
C>>Ерунда, у них даже в этом идеальном случае уже были потери пактов из-за таймаутов. WH>Во первых потерей ну уровне CCN небыло. WH>Во вторых чтобы сравнение было объективным с CCN стеком нужно сделать тоже самое что с IP стеком те засунуть в ядро и оптимизировать.
Ты читал какие там машины использовались? У меня мобильный IPv6 работает с достаточной для трансляции _видео_ скоростью на MIPSовой железяке с 150MHz CPU.
C>>В Mobile IPv6 их тоже нет. К примеру, мой ноутбук с ним переключается между WiFi-соединением, проводным и GPRS'ом без потери открытых SSH-сессий. WH>А ты читал как это мобильный IPv6 устроен?
Я его себе задеплоил для экспериментов.
WH>Мрак!
Нормально устроен. По умолчанию тебе просто форвардится траффик через третюю сторону (т.е. обычный "triangle routing"). Но есть возможность оптимизации маршрута, если обе стороны понимают IPv6 Mobile.
Здравствуйте, WolfHound, Вы писали:
C>>Я выделил места, где пакеты попеременно проходили через разные маршрутизаторы. WH>А ты уверн что ты на банальный лоадбалансер не нарвался? WH>Их в гугле должно быть много.
Нет. Заметь, что они ещё в трассе задолго до Google'а. Т.е. это и есть load ballancing и multipath, но уже прямо на уровне IP. Можешь поспрашивать сетевиков, такой подход — достаточно частая практика.
Причём оно работает настолько хорошо, что ты даже об этом не знаешь.
C>>Предложенный автором вариант подходит в реальности только для статического контента. Этакий eDonkey на стероидах WH>В реальности для динамического он тоже подходит что автор и продемонстрировал при помощи VoCCN.
Уже ответил.
Да, в реальных телефонных сетях, где нужно гарантировать качество, используются более другие подходы для обеспечения надёжности.
Здравствуйте, 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 — протокол не контента, а соединения, в котором есть фичи для управления этим соединением, на основе контента. Не так?
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, WolfHound, Вы писали:
WH>Другими словами ты считаешь что freenet уязвим?
Что такое freenet? И как он относится к тому, что ты предлагаешь ослабить шифрование контента ради непонятной выгоды ("чтобы можно было скукорживать").
Если уж трафик зашифрован это означает что его хотят защитить.
WH> А можно послушать техническое обоснование?
Берешь любую книгу по криптографии и читаешь.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, CreatorCray, Вы писали:
CC>>Это только если у нас один источник и куча получателей, синхронизированые между собой. Т.е. ключ и IV у них у всех одинаковый. WH>Я так думаю это верно в подавляющем большинстве случаев.
Это будет верно только если программеры наплевали на все security guidelines и реализовали шифрование через задницу.
Шифрование появляется там, где надо защитить контент.
WH>И в еще большем количестве случаев вообще никакого шифрования не будет.
Но мы то сейчас обсуждаем твоё "WH>Шифрование не мешает скукорживать трафик."
CC>>Да и то это получается обычный броадкаст. WH>Нука продемонстрируй мне броадкаст на весь интернет?
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, 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 получается проще, гибче и может масштабироваться.
Не может. У них даже в идеальном случае уже потери пакетов идут.
Здравствуйте, Cyberax, Вы писали:
C>Нет. Заметь, что они ещё в трассе задолго до Google'а. Т.е. это и есть load ballancing и multipath, но уже прямо на уровне IP. Можешь поспрашивать сетевиков, такой подход — достаточно частая практика. C>Причём оно работает настолько хорошо, что ты даже об этом не знаешь.
Если бы...
Я с такими железками дело имел.
Они не спасают если:
1)Сервер умер посередине ответа даже если отдавалась статика и ее можно взять с соседнего.
2)Некоторое время после смерти сервера балансировщик продолжает гнать на него новые запросы. Те получаем еще кучу народа которые получат облом.
3)Если сервер ушел в кому те принимает соединения и не отвечает то балансировщик так и будет отправлять на него запросы. Те без ответов останется куча народа.
C>Да, в реальных телефонных сетях, где нужно гарантировать качество, используются более другие подходы для обеспечения надёжности. C>К примеру: http://en.wikipedia.org/wiki/MPLS_local_protection
ГЫ! CCN так умеет. Достаточно на уровне стратегий реализовать соответствующее поведение.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, CreatorCray, Вы писали:
WH>>Другими словами ты считаешь что freenet уязвим? CC>Что такое freenet?
Тебя в гугле забанили? http://en.wikipedia.org/wiki/Freenet
CC>И как он относится к тому, что ты предлагаешь ослабить шифрование контента ради непонятной выгоды ("чтобы можно было скукорживать").
Ну почитай про модель защиты контента freenet'ом поймешь.
Если коротко то там ключ для шифрования файла генерируют на основе хеша от не зашифрованного файла.
Таким образом если два файла отличаются одним битом то в зашифрованном виде они будут полностью разными.
Но если файлы одинаковые то во freenet они попадут одинаковыми даже если их туда загрузили разные люди в разное время.
В такой модели трафик прекрасно скукорживается CCN'ом.
CC>Если уж трафик зашифрован это означает что его хотят защитить.
Только это не мешает скукорживанию.
WH>> А можно послушать техническое обоснование? CC>Берешь любую книгу по криптографии и читаешь.
Ты выдвинул тезис тебе его и доказывать.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, 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) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Если IP заточен на разговор 2х машин то CCN'у нет дела до конкретных машин. Он построен вокруг именованных данных. WH>Те запросы идут не к машине с адресом ХХХХХХ, а к сети и выглядят как: Дай мне данные с таким то именем.
DFS (Distributed File System) ? Построен вокруг именованных в сети данных, запросы идут к этим данным куда-то в сеть, куда — вообще-то и не знаю. Более того, имена еще и иерархично построены. Конечно, уровень не тот, но сама идея похожа. Она, кстати, в домене Windows давно существует.
Здравствуйте, WolfHound, Вы писали:
WH>В данном случае вообще никаких анонсов небыло. Просто случился таймаут и нода отправила запрос по другому пути.
Для того, чтоб направить по другому пути ноде надо знать что есть другой путь и какой из путей тот самый "другой"
Так что похоже анонсы все таки нужны.
F>>Во-первых, появилась — не мгновенно, а за вполне ощутимое время (см. выше), WH>Конкретная нода через которую ходит узнает о новой ноде в вполне конкретный момент времени. WH>Так что она появилась сразу.
Не похоже. Впрочем реализуют — увидим. А пока теоретизировать нет смысла.
WH>Ноды которые производят много битых пакетов будут попадать в конец очереди маршрутизации вплоть до бана.
Они хотят переизобрести торрент?
WH>Большую часть шифрованного контента можно шифровать так что скукорживанию это не помешает.
Еще раз тебе говорю: это глупость!
F>>И вообще — чем по сути это отличается от обычного броадкаста? WH>Покажи мне броадкаст на весь интернет.
Кому нафиг надо броадкаст на весь интернет?
WH>Вообще говоря учитывая личность автора не думаю что в этом протоколе можно будет так просто найти фатальные недостатки. WH>По крайней мере все что находил я не выдерживало критики при вдумчивом анализе.
Люди есть люди, и они совершают ошибки.
Давай подождем версию, работающую не в тепличных условиях.
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]!!!
Этож вообще капец! Нахрен такие протоколы.
А то инетокапец наступит досрочно.
Здравствуйте, 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.
Это один-в-один повторяет то, что я делал несколько лет назад — ну не нужно для этого чего-то хитрого на нижнем уровне.
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, WolfHound, Вы писали:
WH>>>Другими словами ты считаешь что freenet уязвим? CC>>Что такое freenet? WH>Тебя в гугле забанили?
Не, работы много, некогда надолго отвлекаться.
WH>Если коротко то там ключ для шифрования файла генерируют на основе хеша от не зашифрованного файла.
А как генерят IV?
WH>Таким образом если два файла отличаются одним битом то в зашифрованном виде они будут полностью разными.
Соответственно одинаковые файлы будут одинаковыми.
Для чего они их шифруют тогда?
Здравствуйте, 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)Случай далеко не идеальный.
Абсолютно идеальный. В рельности всё жёстче.
Разве что это будет не на уровне «роутер у юзера», а на уровне «роутер у сервера»
Флаг в руки, поднимай CCN — уверен, в случае с числом нод > 10 ты во всей красе всё ощутишь. 
