Наткнулся тут на интересный проект 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'ы и т.п.
Разве что это будет не на уровне «роутер у юзера», а на уровне «роутер у сервера»