14 Сентября

Народ в форуме самоутверждается, ишь. :) Оно и к лучшему. Читая выпендрёж, вспоминаю интересные темы. Вот, к примеру, NFS и TCP.

Это чертовски интересная тема. Общеизвестно, что сетевая среда Юникса строилась вокруг TCP - наверное, самого сложного и мощного из популярных Интернетовских протоколов. Он занимается предоставлением "качественной" связи в Интернете - передачей данных с гарантией их доставки, причём именно в том порядке, в котором они были отправлены. TCP - это "труба" через Интернет: с одной стороны роняем в неё байтики, с другой они вываливаются с некоторым запозданием, но без потерь и перепутываний местами.

Огромное количество протоколов, среди них FTP, Telnet, HTTP, SMTP, NNTP и т.д. и т.п. представляют собой лишь несложную нашлёпку на TCP. Тот же SMTP, передающий почту, лишь засовывает в TCP-шный канал письма в нужном формате с одной стороны и вытаскивает их с другой, разбирая, где адрес, а где - тело письма. Работа ерундовая - несложный SMTP-сервер пишется за час. А вот TCP за час не пишется, это эдакая основа основ. И зачастую кажется, что весь поголовно зверинец Интернетовских протоколов сидит на шее у TCP.

Оно почти так и есть. Но почти. Если несколько мелких исключений и, как минимум, одно крупное. Это NFS - Network File System. Доступ к файлам по сети. Сей протокол вообще из ряда вон выходящий - по массе свойств. Ну, опять же, во-первых он не базируется на TCP. :-)

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

Идея заключалась в том, что сервер должен быть в состоянии упасть и подняться, и клиент ничего не должен заметить, кроме, разве, задержки по времени. Оно и естественно - коли между клиентом и сервером нет никакой синхронизации, и каждый запрос - сам по себе, перезапуск сервера не грозит ничем.

Зато кое-чем грозит сама схема взаимодействия с ним. Протокол NFS, и в этом ещё одно его отличие от мира, базируется не просто не на TCP - это не фокус, иные садятся вместо TCP на UDP и организуют перепосылки сами. Наш герой живёт поверх RPC. Это - дистанционный вызов процедур. Это когда программа вызывает функцию, а функция находится на другой машине, в контексте другой программы. Ну примерно как Corba, только слово "объект" отсутствует, а вместо "метод" говорим "функция". :-)

Сам же RPC живёт поверх UDP, ибо поверх TCP ему не вольготно. Жил, точнее. Нынче времена не те, воли RPC не дают - упихали его в TCP-шную трубу, и назад уж не очень пускают. Хотя в принципе возможность выбирать базовый транспорт для NFS есть.

В чём причина? Во-первых, при работе на большие расстояния, через реальный Интернет, TCP справляется лучше - он специально обучен этому делу, и дублировать соответствующую функциональность в RPC - не резон.

Во-вторых, со stateless-ностью всё тоже не так здорово, как казалось. Если короче - оно бы лучше, чтобы у данного клиентского компьютера и у данного сервера совпадали взгляды на то, что происходило вначале, а что - потом. А то недолго и на парадокс нарваться.

Вообще, надо сказать, NFS, по моему мнению, один из наименее удачных протоколов "по сумме баллов". Ну, та же stateless-ность. Зачем такие заморочки, если вовсе несложно клиенту и серверу после падения сервера договориться заново и сообщить серверу всё, что он должен помнить о данном клиенте. Виндовый SMB-протокол это вполне умеет, хотя он и statefull по полной программе.

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

Ну и производительность. Если сервер ничего не помнит о клиенте, оптимизировать производительность трудновато. А если с каждым запросом на три байта передавать имя файла байт на тридцать, трафик будет - просто ой...

Нет, короче говоря, не по нраву мне NFS, даже поверх TCP. Хотя SMB - тоже не фонтан. Надобно что-либо новое - красивое, как NFS, и практичное, как SMB. Бывает ли так....

Возвращаемся к Кобальту.

From: MrBear Subject: About Cobalt... Здравствуй, Дмитрий. В последнем обзоре ты пишешь: "В форуме прозвучало предположение, что Cobalt Cube купят, в первую очередь, "виндузисты", а вот "юниксоиды" - нет. - Если путём установки Кобальта можно сэкономить деньги - его поставят. Если нельзя - не поставят. На западе ставят. И у нас будут. Натуральное хозяйство выгодно только при отсутствии устоявшихся продуктовых ниш и производителей, на них нацеленных. - У нас, поскольку NT не очень-то и покупают, сравнение идёт по стоимости чистого железа, а тут Кобальт проигрывает. Так что на этом рынке Кобальт будет играть лишь как "бессисадминное" железо. Это означает, что ценность его менее очевидна на первый взгляд. Но и только-то." Хотел бы озвучить довольно очевидный момент в системах ценообразования нашего и "ихнего" - компонента з/платы в составе цены конечного продукта. То-есть, для них взять за 1000-2000 ихних долларов единовременно тулзу, которая позволит не платить своему дополнительному админу 3000-5000 тех же долларов ежемесячно, неизмеримо выгоднее, чем для нас ввалить 1500-3000 наших баксов :-), чтобы сэкономить на зарплате в 200-400 (ладно, для Москвы 500-800), которую ещё можно и задержать... Тем более, что остаётся проблема отсутствия саппорта, необходимость всё равно держать кого-то, чтоб хоть кнопкой "повер" щёлкал и т.д. Буржуи вообще давно поняли, что выгоднее роботами делать максимум, а людЯми - минимум. Ну и таки сугубо национально-психологический момент присутствует - не привыкли мы доверять стороннему производителю, когда есть возможность своими ручками всё сваять на коленке... :-) Впрочем, кое-что из этого может быть уже неактуально для Москвы и Питера, отчасти, так что ниша для Кобальтов, видимо, присутствует. Кстати, хотел бы уточнить, что в бОльшей мере всё вышесказанное относится к провайдерам, но кто ж нам мешает и своим клиентам серверок под юнихом поставить за разумные деньги? :-) Sincerely yours MrBear

Спасибо за письмо.

Да, экономическая привлекательность Кобальта тут пониже, факт. Хотя всё равно $1400 окупаются за полгода, а то и меньше, а кнопкой повер ему щёлкать не надо, собственно.

А вот что касается провайдера, которому ничто не мешает "серверок под юнихом поставить за разумные деньги", то это момент серьёзный. Если вспомнить наш опрос по провайдерам на эту тему, то в нём совершенно явственно прозвучала именно такая позиция - нафиг энтый куб, мы клиенту сами всё склепаем.

У неё есть несколько существенных сторон. Во-первых, масштабы бедствия. Когда в кубоподобном железе нуждается один клиент в месяц - можно склепать самим. А если это раз в два дня - уже вопрос, получится ли, клепая самим, их окучить, и нужно ли этим заниматься - фактически, цех открывать...

Второй момент: есть же и юзер, от него тоже кое-что зависит. Если склёпанное провайдером дёшево и удобно - оно выиграет у Куба. А если у Васи склёпанное провайдером виснет или не позволяет себя конфигурить через веб, а Петя сидит весь в белом и тычет мышкой в окошке броузера, а Куб ему там диаграммы загрузки рисует, посмотревший на них Коля ещё вопрос, что предпочтёт, даже если куб и подороже. Чёткого ответа нет, всё в руках того, кто делает конкретное предложение, но вообще у Кубика довольно гибкое и приятное управление, не всякий слепит такое на коленке.

Из чего же, из чего же, из чего же
Сделаны наши Билл Гейтсы.

Потрясающая работа. Если не очевидно, сделайте несколько раз shift-click на любом месте лица Гейтса.

Ссылку прислал Silicon Poltergeist. Спасибо!

Евгений Кроссер, спасибо ему, прислал мне ссылку на фото часов с инфракрасным интерфейсом. Зовут их Casio PCX HBX-100J. Продавец на рынке, увы, врал, что это IrDA - у часов свой собственный протокол, хотя и работает он тоже по инфракрасному лучу. Обидно, надо сказать. Это означает, что обмениваться информацией с кучей стандартного железа с этих часов не получится. Только с родным инфракрасным портом.

А ведь нынче специально для таких применений разработана вариация стандарта IrDA - IrDA Lite, в которой минимизировано и облегчено всё, что только можно, но сохранена совместимость с полными реализациями стандарта. Вообще обвязка IrDA стандартами мне нравится. Вокруг базового IrDA, который занимается собственно приемом-передачей данных, гарантией доставки и обнаружением устройств в рабочем диапазоне оптики, накручено несколько довольно симпатичных протоколов, специфицирующих конкретные способы применения IrDA. Например, описанный случай подпадает под область применения протокола IrMC. IrMC описывает передачу по лучу как раз того, что надо - календарной информации (запланированные встречи, события и т.п.), телефонного справочника и записок. Или вот IrTran-P. Про него я уже писал. Этот протокол сделан специально для цифровых фотоаппаратов и позволяет им обмениваться картинками непосредственно с принтером, к примеру. По сути - ничего особенного, просто способ передавать jpeg-и и сопутствующую информацию, не укладывающуюся в формат JFIF, по лучу. Но особенного и не нужно. Нужно стандартное.