Используемый в QNX4 компактный, но при этом полнофункциональный сетевой протокол FLEET обеспечивает QNX-сети высокую производительность и надежность, а используемый в этой передовой технологии механизм передачи сообщений позволяет представить локальную сеть в виде единого набора ресурсов. Последнее означает, что мы без каких-либо материальных, временных или интеллектуальных (что особенно важно :)) затрат получаем систему, логически эквивалентную кластерному суперкомпьютеру. Это дает нам гибкость и прозрачность сетевых соединений, а главное - элементарное удобство использования. Это и есть тот самый usability, которым так гордятся всякие там виндузятники, не понимая, что все удобства у них, конечно, есть, но - во дворе...
Кстати, это слово (юзабилити) при желании можно перевести как "способность приносить пользу", "полезность", или даже "возможность употребления", "применимость". ИМХО, поганый маздай не соответствует ни одному из этих значений, в отличие от [подставь сюда название своей любимой ОС]. Раз уж мы заговорили о переводе с английского, то попутно замечу, что слово fleet переводится как "флот, флотилия" (с определенным артиклем the - "военный флот"), "парк" (имеется в виду парк автомобилей/ танков/ сельхозтехники, а возможно, что и парк компьютеров), "залив, ручей", в переносном смысле - "лондонская пресса" (на Fleet Street сосредоточены редакции многих лондонских газет), "быстрый", "быстротечный" (поэтическое), "мелкий, неглубокий" (о реке и т.п.), "скользить мимо", а также "протекать, миновать, пролетать" (в смысле - WыNьd0уz в пролете :)). Не знаю, какое именно значение подразумевалось изначально, но по смыслу подходит в любом случае (быстрый военный флот, скользящий мимо по неглубокой реке и доставляющий лондонские газеты всему компьютерному парку? :)). Зато могу точно перевести основные лозунги, начертанные на знамени разработчиков этой прогрессивной технологии:
Fault-tolerant networking (устойчивость сети к сбоям), Load-balancing on the fly (балансировка нагрузки на лету) и Efficient performance (эффективная работа).
В случае отказа какого-либо сетевого устройства данные перенаправляются по альтернативному маршруту (если он, конечно, существует). Как ты знаешь, существует несколько топологических принципов построения сети.
Сети "шина" и "звезда" известны всем, но встречаются гораздо более интересные "дерево" (tree) и "в клеточку" (а как еще перевести "mesh" - сетка, невод, ячейки? убого звучит, да и непонятно). Ну, с древовидной структурой все ясно - по дереву каталогов ты ведь каждый день лазаешь? Вот и представь, что корневой каталог - это самый наиглавнейший сервант, каталоги - это хабы, вторичные сервера и прочий хлам, а файлы - терминалы. "Меш" - это топология, при которой каждый комп связан напрямую со всеми остальными компами. Тоже легко представить - нарисуй на листочке квадрат и проведи в нем диагонали. Представь, что в углах квадрата - компы (на пересечении диагоналей компа нет - кабели там пересекаются, но никак не соединяются). Или нарисуй пентаграмму, вписанную в окружность. Математики называют это не mesh, а "полный граф".
Существует класс математических задач, посвященных графам (поиск наикратчайшего пути в графе, поиск оптимальной конфигурации графа при заданных условиях и тэ дэ). Вообще-то задачи эти относятся к так называемой комбинаторике, но из-за того, что граф является множеством точек, связанных конечным числом дуг, форма которых не имеет никакого значения, топологические методы тоже прекрасно работают. В этой области математики есть свои аксиомы, теоремы и методы решения, которые могут помочь организовать сложную сеть с произвольным графом (компы раскиданы как попало и связаны чем придется :)) и различными весовыми коэффициентами ребер графа (т.е. с различной пропускной способностью между разными компами).
Например, "меш" - самая выгодная с точки зрения скорости работы конфигурация (между любой из вершин графа находится одно, и только одно ребро), но и самая затратная (в каждый комп придется вставлять N-1 сетевых карт, где N - общее количество компов в сети). В кольцевой топологии количество ребер равно количеству вершин, но сигналу может понадобится пройти через все узлы (если передача пакетов происходит только в одном направлении, скажем, по часовой стрелке, а нам нужно передать информацию в следующий против часовой стрелки комп).
Если все узлы сети равноценны, а связи между ними одинаковы, то самая выгодная (с точки зрения математики) топология - гиперкуб. N-мерный куб имеет 2^N вершин, а каждая вершина связана с N другими. Рассмотрим для простоты 3-мерный куб. На самом деле мы можем построить в 3-мерном пространстве, и даже на 2-мерной плоскости граф, топологически эквивалентный (математики говорят - гомеоморфный, но я такие некрасивые слова употреблять не буду :)) и 4-х, и 5-и, и даже 100-мерному кубу. Ну ладно, не мы можем, а я могу :). Точнее, мог бы, если б захотел...
Итак, восемь компов соединены 12 ребрами (отрезками кабеля), каждый из них соединен с тремя другими (т.е. в него вставлены 3 сетевушки), а маршрут между любыми двумя точками не длиннее 3 ребер при условии, что все компы готовы к приему/передаче данных. Допустим, что у нас - единичный куб, одна из вершин которого находится в точке начала координат (0,0,0), а все ребра имеют длину, равную единице. Тогда все возможные наикратчайшие маршруты между наиболее удаленными точками, например (0,0,0) и (1,1,1), будут выглядеть так:
Маршрут1: (0,0,0) - (1,0,0) - (1,1,0) - (1,1,1)
Маршрут2: (0,0,0) - (1,0,0) - (1,0,1) - (1,1,1)
Маршрут3: (0,0,0) - (0,1,0) - (1,1,0) - (1,1,1)
Маршрут4: (0,0,0) - (0,1,0) - (0,1,1) - (1,1,1)
Маршрут5: (0,0,0) - (0,0,1) - (1,0,1) - (1,1,1)
Маршрут6: (0,0,0) - (0,0,1) - (0,1,1) - (1,1,1)
Сеть, построенная по этому принципу, имеет максимальную производительность и надежность при минимуме сетевых интерфейсов. Конечно, если рассматривать только одноранговые сети, не имеющие выделенных серверов (а может, в такую сеть имеет смысл
объединить именно сервера?) и дополнительных сетевых устройств (концентраторы, маршрутизаторы, етц). Допустим, узел (1,0,0) вылетел или просто очень занят, тогда у нас останутся маршруты с 3 по 6, а если еще и на узле, скажем, (1,1,0) опять взглючит эNTя (и кто додумался ее туда поставить? :)), да еще потянет за собой (0,1,1), то нам останется только 5-ый маршрут, что совсем неплохо при трех (из восьми) нерабочих компах (т.е. сеть жива только на 62,5%).
Понятно, что все мои рассуждения - это математические выкладки, далеко не всегда применимые в реальной жизни. Можно представить себе "меш" из 3-4-5 компов, "звезду" из 8-10 и больше, "шину" (и даже "кольцо") на двадцать рабочих станций (но только если они расположены в одной комнате, разумеется, да и то... один мой НЕхороший знакомый чуть ли не полдиплома потерял, когда злобная уборщица с ласковой улыбкой потомственной живодерши ткнула шваброй в самую гущу "пыльных проводочков"). Но в большинстве случаев применяется некий комплекс решений, главная сеть состоит из нескольких подсетей, топологии и интерфейсы которых могут отличаться друг от друга и от главной сети. Подсети могут иметь несколько точек пересечения, так что один и тот же комп (хотя чаще это НЕ комп) принадлежит одновременно нескольким сетям.
Так вот, Кьюникс способен работать (причем грамотно, а местами даже эффективно) и в таких нечеловеческих условиях, обеспечивая не только надежность, но и увеличение скорости (и то, и другое - за счет избыточности сети, разумеется, но ведь за все надо платить, а дополнительный хаб и пара лишних метров кабеля довольная низкая цена за уверенность и комфорт).
Extensible architecture (расширяемая архитектура).
Гибкость FLEET обеспечивается модульной архитектурой QNX. Можно добавлять узлы в сеть или удалять их из сети в любое время, не нарушая целостности остальной сети - перенастроится она автоматически, на лету. Можно подключать к одной сети другие физические сети. Этот механизм получил название "brouting", что очень точно отражает его суть: нечто среднее между маршрутизацией (routing) и коммутацией сегментов через мост (bridge).
Ничего удивительного, что Cisco выбрала именно КНХ для использования в своих сетевых устройствах (не буду
утверждать, что во всех, и не буду утверждать, что именно КНХ 4.х, но все же). Впрочем, ежу понятно, что Киска много чего туда добавила своего. Дело в том, что FLEET вовсе не идеален. Он гораздо проще в использовании и эффективнее, чем TCP/IP, но зато не так универсален. Впрочем, реализация ТиСиПи/АйПи под 4.х есть, причем большая часть кода - это сетевое
программное обеспечения BSD Release 2, портированное под QNX4 без каких-либо компромиссов между функциональностью и хаpактеpистиками pеального вpемени.
Под 6.х еще интереснее - сначала сделали урезанный вариант под названием Micro TCP/IP, который не поддерживал динамические протоколы маршрутизации и сложные таблицы, но зато помещался в 40-50Кб, что для встроенных систем гораздо важнее. Потом, насколько я знаю, была добавлена полная поддержка стека TCP/IP (BSD4-sockets), а также совместимость с FLEET. Вся эта сборная солянка позже была названа Qnet (это означает, как я сильно подозреваю, QNX Net, в смысле - нет кьюниксу!
:).
Qnet - это не только собственные реализации протоколов, это краеугольный камень идеологии QNX. Термин этот скорее не технический, а маркетинговый, означающий summa technologae (сумму технологий), применяемых при организации сети. Кстати, транспортом для КуНет может служить любой протокол, в том числе твоя собственная разработка. Здорово, да? Осталось только свой протокол придумать :).
Все вышеперечисленное вовсе не делает Кьюникс идеальной средой для создания фаерволла или, скажем, проксика. Во-первых, дороговато обойдется (в смысле софт - понадобится как минимум Neutrino PE, а это примерно 14 килобаксов), во-вторых, есть гораздо более простые решения (например, PicoBSD, которая встраиваемой системой не является, но помещается на одну дискету, позволяя построить роутер/ дайлап-сервер/ прокси на 386SX c 4-10 метрами рамы). Кьюникс (особенно QNX4) для этого, строго говоря, вообще не предназначен.
Что же касается Киски, то эта корпорация может себе позволить использование QNX6 (именно "шестерки", насколько я знаю - об использовании "четверки" в сетевых устройствах у меня информации нет, хотя такое вполне возможно, несмотря на все мои домыслы), потому что при массовом выпуске лицензионные отчисления совсем другие (иначе стоимость ПО составляла бы бОльшую часть цены самого устройства), да к тому же у них есть высокооплачиваемые кодеры, которые просто напишут недостающие модули, если понадобится. И вообще, зачем тебе встраиваемая система, да еще реального времени, если для этих целей ты будешь использовать обычный комп, на котором прекрасно работают линукс/ бзд/ етц? Я, конечно, не запрещаю, и не отговариваю - просто предупреждаю, что переплюнуть в этом деле многомиллиардную корпорацию с многолетним опытом разработки сетевых устройств будет нелегко. Вот на этой пессимистичной ноте и закончим :(.
(продолжение следует)
