This page is an archived copy on Gagin.ru personal site

InterNet magazine, number 15
Сюжеты | Тема номера
Дмитрий Манин

Может быть, зеленый змий,
а может, крокодил

Что за дивная мечта – соединяешь одно с другим, и они работают вместе. До сих пор деятельность изготовителей аппаратуры больше походила на вредительство, и дивная мечта на практике часто разбивалась об острые (или закругленные – неважно) углы очередного чуда техники. Производители пытаются исправиться. Дмитрий МАНИН, manin@pobox.com

This internet is supposed to be convenient!
("Ведь Интернет должен быть удобным!"
- из письма читателя)

Интернет плавно вошел в число предметов, которыми мы пользуемся, понятия не имея, как они устроены. В отличие от многих других, однако, устройство Интернета вполне доступно неспециалисту. Я бы не взялся объяснять в популярной статье, откуда берется подъемная сила самолетного крыла, а вот Ethernet объяснить можно - и постановку задачи, и ее решение. Польза от этого двоякая: во-первых, многие алгоритмы, лежащие в основе Всемирной Cети, сами по себе красивы, а во-вторых, начинаешь лучше понимать, где реальность, а где мечты.

В этой статье речь пойдет об одной из последних широко разрекламированных новинок от фирмы Sun технологии Jini , призванной (ну конечно!) революционизировать компьютерные сети и Сеть. Поставим Jini в один ряд с уже укоренившимися сетевыми технологиями и сравним их достоинства.

Сверхзадача Jini - превратить сеть из совокупности вычислительных устройств, соединенных коммуникационными каналами, в безграничное море информации и вычислительных мощностей, из которого можно свободно черпать. Стандартный пример: принтер, включенный в сеть, становится поставщиком "услуг по печати", доступных любому компьютеру, программе и пользователю. Причем это должно происходить само собой - в частности, вам не придется устанавливать драйверы и редактировать конфигурационные файлы. Менее традиционный пример: предположим, вы пишете вычислительную программу, которая по ходу дела должна решать большую систему линейных уравнений. Ваша программа может не делать этого самостоятельно, а отдать уравнения первому попавшемуся суперкомпьютеру, который предложит услуги по решению линейных систем. Удобно!

Jini - аббревиатура, что-нибудь вроде "Java InterNetworking Initiative". Ручаться не могу, потому что расшифровки нигде не нашел. Читается "джини", с ударением на первый слог. Любопытно, что в английском языке оказалось два слова, которые так читаются: genie и jinni. Оба обозначают "джинна" (который старик Хоттабыч), только второе, согласно Вебстеру www.m-w. com/ cgi-bin/ dictionary? book= Dictionary&va =jinni+ , заимствовано непосредственно из арабского в 1684-м, а первое - через посредство французского в 1748-м. Мне показалось чрезвычайно подозрительным сходство genie со словом "гений", но словари утверждают, что и русское "гений", и английское genius происходят из латыни (русское слово через посредство немецкого в Петровскую эпоху) и к джинну никакого отношения не имеют. При этом английское слово, как и русское, обозначает не только Эйнштейна, но и "воплощение, олицетворение качества", т.е., например, гений чистой красоты. Получается, Jini все-таки джинн, а никакой не гений.
Эта идея очень созвучна вынесенной в эпиграф фразе, которую я встретил в письме читателя в журнал Art Calendar (читатель-художник сетовал, что многие сетевые художественные конкурсы не принимают изображений в электронном виде, а по старинке требуют присылать слайды). Между тем Интернет создавался вовсе не с расчетом на удобство! Интернет как известно, делали по заказу американских военных как систему связи. Главным пунктом техзадания была надежность. Сообщение должно быть доставлено по назначению, даже если большая часть каналов и узлов связи выведена из строя вероятным противником. Стоит несколько углубиться в детали задачи, чтобы почувствовать, как красиво она решена и как это решение фундаментально плохо подходит для многих новых задач, которые теперь уже ставит бизнес.

Итак, представим себе, что нам нужно спроектировать неуязвимую систему связи. Прежде всего, отметаем вариант, в котором все компьютеры сообщаются через один-два центральных коммутатора. Потому что тогда достаточно уничтожить коммутаторы, и система парализована. Надо, чтобы каждый компьютер был связан со многими соседями, тогда даже если некоторые из них вышли из строя, можно будет, передавая письма по цепочке уцелевших узлов и каналов, доставить их по назначению. Но как найти эту цепочку, если нет центрального узла связи? Даже если потребовать, чтобы каждый компьютер в сети знал, кто с кем связан, и мог вычислить, какому из своих соседей передать письмо с известным адресом, - как обеспечить работу этой системы в условиях, когда конфигурация сети в любой момент может измениться?

Делается это так. Во-первых, все компьютеры, ответственные за передачу сообщений (роутеры, или маршрутизаторы), периодически обмениваются с соседями информацией об известных им изменениях в конфигурации сети. Таким образом, эта информация рано или поздно распространяется повсеместно. Это, однако, не гарантирует своевременного и точного обновления, ведь пока информация распространяется, она может уже устареть. А это значит, что сообщение может и не дойти до адресата, а заблудиться в сети. Поэтому сообщения разбиваются на маленькие кусочки-пакеты, снабженные порядковыми номерами и отправляемые независимо друг от друга. Они могут пойти разными путями: некоторые дойдут быстро, некоторые проблуждают дольше, а какие и затеряются. Чтобы заблудившиеся пакеты не засоряли сеть, в каждом пакете заложен счетчик пересылок; как только количество переходов от машины к машине превысит некоторый порог, пакет выбрасывается. Между тем, адресат получил некоторые из пакетов и может определить порядковые номера недошедших. Тогда он просит отправителя послать потерявшиеся пакеты еще раз. Со временем все дойдет.

Прелесть такой архитектуры (а это и есть TCP/IP) в ее почти биологической гибкости и тотальной децентрализации. Каждый узел сети действует самостоятельно, обменивается информацией с другими и не требует управления извне. Система находится в непрерывном процессе приспособления к меняющимся обстоятельствам, никогда не приходя в точное равновесие со средой, но всегда находясь от него достаточно близко для того, чтобы механизмы защиты от ошибок надежно работали. Не могу удержаться, чтобы не разобрать еще один пример подобного алгоритма, Ethernet, протокол общения компьютеров в локальной сети.

Представьте себе несколько машин, сидящих на одном проводе. Периодически кто-нибудь из них хочет послать другому сообщение (например, вы ввели URL в окне смотрелки, и ваша персоналка посылает запрос ближайшему роутеру). Если все остальные в это время молчат, то все в порядке. Но если другая машина в тот же самый момент тоже выдает сигнал на тот же провод, эти два сигнала наложатся, и никто ничего не поймет. Как этого избежать? Проще всего распределить время: договориться, что каждый компьютер имеет право говорить только в отведенные ему доли секунды. Понятно, чем плохо это решение: если из десятка машин часто говорит только одна, ей все равно оказывается доступна только одна десятая пропускной способности провода. Остальные 90%, отведенные тем, кто все равно молчит, пропадают даром. Более экономный алгоритм (эппловский TokenRing) предусматривает возможность молчуну отказаться от своей очереди в разговоре, передав ее следующему.

А вот Ethernet устроен совершенно по-другому. Нет никаких очередей и ограничений: каждый может начать говорить, когда ему заблагорассудится. Но притом все и слушают. И если два сигнала наложились друг на друга, все замолкают и ждут некоторое случайное время. Это очень важно, что случайное: скорее всего, после этого уже заговорят неодновременно, и все будет в порядке. Но если и опять сигналы наложатся, то все опять замолкают и ждут уже вдвое дольше. Но опять со случайным множителем. В результате, если желающих говорить слишком много, все начнут говорить медленнее, и ровно настолько, насколько необходимо, чтобы не перебивать друг друга. Смотрите, как опять все просто и вместе с тем эффективно получается благодаря тому, что элементы сети действуют самостоятельно, но применяясь к обстоятельствам.

Jini, конечно, не единственный и не первый проект унификации взаимодействия программ и устройств в сети. Программистам хорошо известны CORBA и COM (DCOM) - средства, позволяющие программам, работающим на разных компьютерах, вызывать друг друга. Известно, что Microsoft разрабатывает Universal Plug-and-Play, протокол для автоматического подключения устройств к сети (см., например, www. idg.net/ idg_frames/ english/ content.cgi? vc=docid_9-118 899. html), а также Millenium - инфраструктуру для создания многомашинных вычислительных кластеров, которые с точки зрения программы выглядели бы как одна большая машина. В качестве прямого конкурента Jini в области распределенных вычислений, тоже основанного на Яве, называют Voyager компании ObjectSpace (www.object space.com). В этом направлении работали и работают много; всего не перечислишь. Jini, как идея, имеет два существенных достоинства: во-первых, она естественным образом объединяет PnP и распределенные вычисления (благодаря концепции "вычислительных услуг", куда входит все, что могут делать устройства и программы), и, во-вторых, она не лишена благородной простоты. Важность последнего обстоятельства оценит всякий, кому приходилось работать с CORBA или COM. Именно сложность как программирования, так и конфигурации пока препятствoвала широкому использованию этих стандартов.
Поистине парадоксально, что военный заказ привел к созданию такой совершенной анархической архитектуры (Вебстер определяет анархизм так: a political theory holding all forms of governmental authority to be unnecessary and undesirable and advocating a society based on voluntary cooperation and free association of individuals and groups - "политическая теория, согласно которой все формы государственного управления не нужны и не желательны; отстаивает идею общества, основанного на добровольном сотрудничестве и свободном объединении личностей и групп"). Еще более парадоксально, что бизнесу (которому, вообще говоря, централизация чужда) эта архитектура подходит очень плохо, причем на самых разных уровнях. Вот только два типичных примера.

В архитектуре Интернета не предусмотрено никаких средств для установления льгот и привилегий. Подросток, качающий многомегабайтную игрушку, на равных делит канал связи с многонациональным банком, переводящим деньги из одного места в другое. Это, конечно, условно; на самом деле банки для таких дел пользуются своими специальными сетями. Но они очень хотели бы приспособить общедоступный и дешевый Интернет. Беда в том, что никто не может гарантировать им пропускной способности, хотя они и готовы за нее заплатить сверху. Это создает чрезвычайное напряжение: с одной стороны, есть платежеспособный спрос, а с другой - нет никакой возможности его удовлетворить. Лучшие умы трудятся над тем, чтобы интегрировать механизмы гарантированной пропускной способности в отчаянно сопротивляющуюся этому архитектуру. Интересующиеся могут почитать про протокол RSVP - www.isi.edu/div7/rsvp/overview.html.

Второй пример гораздо более очевиден, но сводится опять в конечном счете к невозможности купить что-то за деньги. А именно купить выгодное положение в Паутине. Просто потому, что в Паутине все места одинаковые. Супермаркетам, например, крупные фирмы платят бешеные деньги за то, чтобы их товары положили на полку на уровне груди покупателя. А вот поисковая машина не может себе позволить за деньги подтасовывать результаты поиска в пользу заплатившего, потому что потеряет доверие сразу же. А других выгодных мест, кроме искалок, в Паутине уж точно нет. (Рекламу оставим в стороне - это тема отдельная и крайне противоречивая.)

Вернемся к Jini. По существу, Jini тоже является набором протоколов (протокол - это алгоритм взаимодействия между объектами), только на очень высоком уровне. Грубо говоря, Ethernet определяет, как электрические сигналы посылаются по проводам, безотносительно к тому, что эти сигналы "означают". TCP/IP определяет, как пакеты передаются от машины к машине, безотносительно, с одной стороны, к электрическим сигналам, из которых эти пакеты состоят, и с другой стороны, к содержанию сообщений, переносимых пакетами. Существует множество протоколов следующего уровня, которые регламентируют такие действия, как, например, пересылку и хранение новостей в электронных конференциях. Jini претендует на роль универсального протокола по обмену вычислительными услугами.

Идея тут опять же крайне проста. Когда вы подключаете к сети новое устройство, оно сообщает, что оно умеет делать и как его можно попросить это сделать. Точнее, оно предоставляет в общее пользование небольшую программу (на языке Ява), которую надо запустить, если вы ("вы" - пользователь, или "вы" - другая программа) хотите воспользоваться услугами устройства. Тут, конечно, встает извечная проблема совместимости: программа, откомпилированная для одной операционной системы, не будет работать на другой; что говорить, даже числа представляются на разных системах разными комбинациями нулей и единиц. Эту проблему решает Ява, язык программирования, который потенциально может быть (и вероятно, будет) установлен на любом устройстве. Собственно, это почти все. Дьявол, однако, в деталях, как говорят англоязычные.

Проблемы можно грубо разделить на два класса: связанные с отождествлением и вызовом услуг и связанные с регистрацией и отысканием исполнителей. Займемся сначала первым. Допустим, мы опять хотим распечатать документ. Мы вызываем программу, которую нам предоставил принтер, и даем ей наш документ. Казалось бы, все? Не тут-то было. Мы хотим распечатать документ в две колонки на горизонтальном листе. Как сообщить об этом принтеру? Наверное, программа... нет, назовем наконец лопату лопатой... наверное, интерфейс, предоставленный нам принтером, должен предусматривать такую возможность. Но мы хотим, чтобы интерфейсы всех принтеров были совершенно одинаковые, иначе от искомой простоты ничего не останется. А ведь принтеры-то все разные, и одни умеют то, чего другие не умеют, и наоборот. И все производители принтеров должны согласиться на том, что включить в интерфейс, а чего не включать. Это уже большая проблема, как техническая, так и политическая. Конечно, у производителей есть стимул к стандартизации: стандартные устройства имеют больший шанс преуспеть на рынке. Но история показывает, как непросто бывает прийти к согласию даже при наличии такого стимула. Если бы авторы Jini придумали какое-нибудь гениальное решение этой проблемы, цены бы этой технологии не было. Но увы.

Второй круг проблем еще досаднее. Что делает принтер, который мы подключаем к сети? В идеологии Jini, он сразу посылает запрос всем-всем-всем: "Где тут у вас регистрация?" В каждой, условно говоря, локальной сети должен присутствовать компьютер, занимающийся регистрацией устройств. Он откликается на запрос, и наш принтер посылает ему свой интерфейс и перечень оказываемых услуг. После чего всякий, кто желает воспользоваться этими услугами, должен обращаться в регистратуру. Фу, как централизованно! А что если регистратура зависла? А что если она перегружена запросами? А что, если ее база данных по услугам сломалась? А как переместить регистратуру на другой компьютер? Нет, это явный шаг назад по сравнению с замечательным изобретением 20-летней давности, TCP/IP. Подумать только, люди, воплощающие в жизнь идею Сети как безграничного моря услуг и информации, где каждый может воспользоваться всем, что есть в наличии, - не придумали ничего лучше, чем центральный распределитель.

Любопытно, что при этом они позаботились о том, чтобы никто не потребовал неположенного. В Jini заложен механизм контроля и учета, ограничивающий доступ к услугам на основании черных списков. Ну ладно, не черных, а просто списков контроля за доступом. Хоть горшком назови.

Мечта, которую Jini призвана сделать былью, - красивая и полезная мечта. Безусловно, рано или поздно она осуществится, так же как уже осуществилась в Интернете мечта о мгновенном доступе ко всей сокровищнице знаний, накопленных человечеством. То есть с такой же приблизительностью. Но я думаю, что случится это еще не сейчас и не с помощью Jini.


В оглавление номера This page is an archived copy on Gagin.ru personal site