Прежде чем начать очередное повествование, которое будет абсолютно неинтересно любителям смехуечек (делегация фишкинет встала и молча вышла из зала) - небольшое лирическое отступление. Мне на мыло написал чувак с забавным вопросом, мол где я, везучий сукин сын, нахожу столько проектов под малоизвестный и нераспространенный ноде. Отвечаю: проектов под эту платформу практически нет, языком программирования это назвать нельзя, это скорее server-side runtime environment для javascript, инструментарий для решения определенного круга задач. Меня находят совершенно по другим критериям (мой рост, соотношение размера ступни к диаметру зрачка, могу говорить, как Сталоне, ну вы поняли), я лишь выбираю NodeJS для реализации. А мог бы выбирать ерланговские Mochiweb, Misultin, Cowboy (показывающие даже более быстрые результаты) или пайтоновский Tornadoweb, но мне родной JS как-то ближе к телу, к тому же под него есть отличный репозитарий готовых велосипедов на все случаи жизни под названием NPM. Хотя, возможно, в ближайшем будущем тут появятся посты и про вышеназванные технологии. Интересно? Жми на +1.

Итак, как меня учили в гуманитарном ВУЗе, начнем с постановки проблематики. Ко мне обратился мой знакомый, подрядчик одной крупной фирмы в Британии со следующим вопросом: есть 40 GB документов в HTML формате (при ближайшем рассмотрении, размер сократился до 18 GB, что тоже немало, столько примерно весит html дамп русскоязычной википедии состоянием на 2008 год), информация крайне конфиденциальная (дневники принцесс и королей, ага) и собиралась за столетнюю историю компании, лет 5-6 тому назад фирма перешла на какую-то свою систему хранения документации, но старый дамп остался статичным и требовал индексации для поиска по нему. Интранет не позволял использовать Google, импортировать все в новую систему документооборота никто не хотел, кому нужен информационный мусор при какие-то результаты санитарных анализов воды в Нью-Гэмпшире за 1928 год? Нужно отдать должное сотрудникам этой конторы, они усердно оцифровывали все и толково составляли каталоги вручную, а значит к каждому документу был доступ по какой-то гиперссылке с другой страницы. Готовые решения я даже не искал по определенным техническим причинам, было принято решение делать свой crawler + indexer, что в наше время оказалось вполне тривиальной задачей.

Самого паука, который будет путешествовать по пыльному архиву, написать, как два пальца об асфальт, об этом мы поговорим чуточку позже, остановимся лучше на технологии поиска и хранения индекса. Всякие реляционные базы данных отпали сразу после того, как я выполнил du -sh в директории с каталогом. Хотел было попробовать сделать что-то свое на основе NoSQL, но из всех известных мне движков не позволял мне искать подобным образом (чуть позже я случайно наткнулся на Riak, увы, было уже поздно), только MongoDB мог похвастаться поддержкой регулярок при выборке, а про полноценный же full text и речь не шла, в официальном мануале советовали разбивать текст на ключевые слова, но это ужасное решение. Именно поэтому было принято решение хотя бы здесь не изобретать двухколесные механизмы и использовать готовые удобные решения. Я успел посмотреть на Apache Solr и ElasticSearch, которые построены на Java Lucene и на Sphinx. Последний сразу отпал, так как его преимущества в виде ненужных мне индексации SQL баз данных и своего Query Language для сложных выборок были сведены на нет необходимостью писать отдельную XML pipe для добавления статики. Solr, имеющий великолепный административный интерфейс, большое коммьюнити, возможность индексировать DOC и PDF (ну мы и сами можем использовать Apache Tika в любом другом движке) показался каким-то слишком сложным для быстрого старта и избыточным, плюс ему не хватало внятной документации (доки в wiki это FFFUUUU). Поэтому я и остановился на ElasticSearch, который может похвастаться великолепным REST API на основе JSON, русской морфологией из коробки, различными текстовыми анализаторами и возможностью сочетать их в любой последовательности, либо даже создавать свои собственные, встроенными языками скриптования (js или python) для выборки и фильтрации, многими вариантами storage для нашего индекса, кучей параметров сортировки и ранжирования, подсвечиванием результатов, wildcard запросами и AND, OR ключевыми словами, простым созданием кластера и репликацией между нодами, даже возможность использования поискового движка в качестве key-value хранилища данных при правильном маппинге. И да, все работает без малейшей конфигурации в стиле load`n`run, я только изменил network.host на 127.0.0.1 и после запуска получил работающее хранилище нашего индекса. А еще у еластика есть, если и не идеальная, то хотя бы внятная документация и крутое Java API, которое, впрочем, нам не понадобится.

Теперь можем переходить непосредственно к написанию нашего crawler-а, который будет переходить по ссылкам и отправлять данные в ElasticSearch. Прежде всего, я написал свою обертку вокруг RESTа еластика для облегчения процесса индексации и поиска, она очень простая и реализует только функционал двух функций - index (плюс update) и search. Код обвязки можно посмотреть. Его мы будем использовать, как в нашем поисковом боте, так и в серверном приложении, возвращающем ответ пользователю. Теперь непосредственно о преимуществах NodeJS в этой сфере. Прежде всего, это мультипоточность из коробки, разумеется, на всех современных языках можно добиться аналогичного результата (ну разве что кроме похапе, но оно там абсолютно не нужно); и, второй по значимости плюс, - jQuery. Да, я не опечатался, мы будем использовать селекторы и модификаторы jquery на серверсайде. Все это возможно благодаря великолепной библиотеки JSDOM, которая позволяет нам получить виртуальный DOM из кода HTML разметки и эмулировать все вызовы к нему. Почему jQuery? Ответ прост - банальная лень в ущерб определенной производительности, конечно же мы можем использовать регулярки для выборки всех ссылкок, но $('a').each() выглядит проще и симпатичней. Столкнулся с необычной проблемой, которая описана в том числе и в коде самого краулера: ElasticSearch почему-то наотрез игнорировал точки, двоеточия, слешы и прочие символы, поэтому сделать проверку статуса индексации ссылки через ее url не получилось, для этой цели используется md5 хэш. В целом, получилось достаточно быстрое решение, данный блог, скормленный своей главной страницей нашему боту, был полностью добавлен в кеш еластика за полторы минуты всего-то в 3 потока. Я старался, по мере возможности, комментировать исходный код, надеюсь, что у вас не возникнет проблем с его чтением. В идеале, я советую использовать 10 потоков с queueInterval около 100, если ваши сетевая подсистема и процессор выдержат подобные высокие нагрузки, с такими значениями мне удавалось индексировать около трехсот страниц википедии в минуту на средненьком железе и канале в 30 mbit\s. Паук проверяет вхождение домена индексируемой ссылки в разрешенный список и ищет дозволенный content-type в ответе, реализует своеобразный robots.txt при помощи массива регулярок indexQueryPath. К тому же возможна переиндексация при достижении определенного возраста индекса, у меня, по умолчанию, это 100 дней. Процесс индексации в вашей консоли будет выглядеть как-то так. Работающий скрипт в memory leaks замечен не был, но вот JSDOM и jQuery очень любят процессор, будьте готовы к высоким нагрузкам. Для демонстрации я прошерстил этот бложек и написал небольшое приложение поиска по всем постам, состоящее из такой вот серверной части. Его работу можно посмотреть в лаборатории им. Бена Ганна по ссылке.

В заключение, хочу выразить благодарность разработчикам и сообществу NodeJS и ElasticSearch. При всей моей нелюбви к красноглазому opensource, два этих великолепных программных продукта, создаваемых на чистом энтузиазме, помогли мне сделать работу в срок, обрадовать вычурных британцев и купить новую дозу героина. Очень сложно затягивать жгут на руке и писать сюда, до новых встреч, друзья.

Начнем с самого глубокого серверсайда. В распоряжении имелся старенький слабенький сервачок с ненавистным CentOS-ом, ну делать было нечего. Прежде всего, нужно понять, что без иксов нам абсолютно никак не обойтись. Они нужны для виртуальных дисплеев, куда мы будем высаживать наши браузеры. Варианта два: мы можем использовать xorg-x11-server-Xvfb либо же vncserver, который представляет собой perl обертку вокруг Xvnc. Я советую остановиться на втором варианте преимущественно по причине меньшего количества dependencies, возможности удобного удаленного подключения для настройки того же браузера и отсутствия проблем с битностью цвета. К тому же, на старике-центосе Xvfb почему-то постоянно отваливался, а ядро было собрано без поддержки framebuffer, поэтому устройство /dev/fb[0-9] отсутствовало, сводя на нет все преимущества утилит fbdump и fbgrab. После установки vncserver, протестируем его работоспособность, вызвав vncserver :11 -geometry 1920х1200 -depth 24. У вас спросят пароль при первом запуске и, если все прошло без ошибок, то вы счастливчик. Иксы на виртуальном дисплее localhost:11 у вас уже есть. Можете рассказать это своему environment (ненавижу слово "окружение") c помощью export DISPLAY=:11. А еще вы можете запустить xterm и сконектиться через VNC клиент (для виндовса есть отличный бесплатный от RealVNC) и в очередной раз убедиться, что все работает. Теперь нам нужно как-то воровать экран и сохранять его в изображение. В интернетах советуют использовать утилиту import, входящую в набор ImageMagic, но это как перевозить две горошины на грузовом самолете. Вместо нее мы будем использовать xwd из xorg-x11-apps для снятия слепка с виртуального дисплея, и xwdtopnm плюс pnmtopng из netpbm-progs для конвертации его в PNG формат. Тут все еще проще, для получения скриншота вам нужно просто выполнить xwd -root -display localhost:11 | xwdtopnm 2>/dev/null | pnmtopng > screenshot.png. Большая часть серверной магии окончена, осталось сделать небольшой скрипт автоматизации и защиты от дураков. Оговорюсь сразу, что процесс генерации сриншотов будет последователен на основе очереди задач, никакого распараллеливания. О причинах этого мы поговорим чуточку позже. После установки Хромиума, что для ебучего CentOS-а, который сыпется пылью из всех щелей, тоже нихуя не тривиальная задача, мы сделаем небольшой скрипт для облегчения рутины создания скриншотов. Хромиум запускается в инкогнито режиме в фоне, мы ждем открытия страницы 6 секунд (для многих страниц этого времени не хватает, но для тестов сойдет), снимаем скришот и жестко тушим все открытые процессы. Если вам не нужны элементы оформления браузера аля адресная строка или панель табов, то можете добавить ключ --kiosk при запуске хрома. Все пропадет, останется лишь окно с отрендериной страницей, но это выглядит как-то менее эстетично ;). Таким образом, мы собрали все необходимое для создания скриншотов, осталось написать обертку и обертку над оберткой. Пару слов про безопасность: создайте отдельного пользователя из-под которого будете запускать браузер и иксы, отключите все плагины на внутренней странице about:plugins. Клиентская и серверная валидация ссылок в добавок к жесткому ограничению времени исполнения (у нас это 6 секунд) защищает от умников, которые мечтают о stack overflow и arbitrary code execution или пытаются банально загрузить html файл размером с пару гигабайт. От запуска нескольких инстансов браузера для многопоточной генерации пришлось отказаться по этой же самой причине. И да, все настройки хромиума хранятся в JSON формате в файле ~/.config/chromium/Default/Preferences, изменить вам придется параметры размеров окна, потому что даже с ключом --start-maximized у браузера развернуть окно на весь виртуальный экран почему-то не получается.

Часть вторая - middleware или, другими словами, прослойка между сервером-клиентом и своеобразный примитивный менеджер задач. Писать мы ее будем на NodeJS и SocketIO, оба решения мне полюбились event-based моделью. В стандартный набор ноде входит функция spawn объекта child_process для асинхронного запуска дочерних процессов и получения их stdout потоков, которая и будет работать с нашим небольшим bash скриптом. Для создания последовательной модели исполнения, нам нужен какой-то неблокирующий алгоритм task queue и именно поэтому нам не подходит метод Array.forEach. Я, признаться, не стал ебать себе мозг академическими решениями и просто сделал рекурсивную функцию, которая банально вызывала Array.push при добавлении новой задачи и Array.shift при завершении выполнения и переходе на новый цикл итерации с проверкой блокирующей переменной. Решение не идеальное и при больших нагрузках могут возникать проблемы с выпадающими из стека заданиями, но никто больших нагрузок и не ждет - идеальная отговорка для лентяя, который поленился сделать асинхронную модель обработки с помощью setInterval. Чтобы не быть голословным - вот вам код прослойки. Судя по коллекции сохраненных скриншотов, некоторые куллхакеры, думающие, что, выполнив в консоле isURL = function() {return true;}, они обойдут все проверки и удалят мне /etc/passwd, соснули хуйцов и посмотрели веселые картинки на сайте gay.ru. Кекеке!

Последний и самый верхний уровень - clientside не представляет собой ничего особо интересного. Хочу лишь заметить, что при всех преимуществах охуительнейшей библиотеки SocketIO, у нее нету нормальной внятной документации или хотя бы описания API. Лично мне найти не удалось, на гитхабе только описание в примерах, но это не удобно и противоречит законам мироздания. Справедливости ради скажу, что все, описанное мной в этом посте, пахнет влагой и сыростью. Нету ни обработок исключений, ни проверок результата генерации, ни нормальной валидации ссылок, но я лишь даю болванку, а ее обтачивание - дело дорчитателей, которым это необходимо.

Куда ж мы без живых примеров? Никто в наше время тексту не верит. Пришлось перенести все на свой старенький сервачок в далекой Фрицландии, сделать симпатичную обертку на скорую руку и теперь вы можете проверить работу теории на практике в разрастающейся секретной экспериментальной лаборатории интернетовских опытов имени Коли Цискаридзе. Ссылка на ScreenShooter, который старательной описывался в этой статье, работает до последнего посетителя. В качестве бонуса всем, кто дочитал достаточно сложную для формата блога статью, я дарю самодельный уникальный инструмент по раскрутке вашего сайта, известный подписчикам моего твиттера и гуглоплюса. А если серьезно, спасибо всем, кто активно плюсует гуглокнопкой мои посты. Это достаточно приятно и позволяет понять направление дальнейшего развития тематик. Продолжайте в том же духе, нажимайте +1, у меня еще много разнообразных интересностей в черновиках.

Я уже много лет задаюсь одним вопросом: "зачем люди покупают себе устройства на ОС Android"? Возможно, это какой-то дух нонконформизма, заставлявший ваших мам и пап носить брюки клеш, прически под битлов и смешно танцевать под запрещенную музыку на квартирах. Возможно, именно поэтому люди делают себе татуировки на разных интимных и не очень частях тела, или там много пирсинга, лишающего их какой-либо возможности получить нормальную работу. А может быть, корень проблемы нужно искать в стремлении человека не есть мясо, называя это бесчеловечными убийствами, мол помидор боль не чувствует, а корову перед разделкой пытают десяток SSовцев самыми изощренным способами. Сложно сказать, что общее у всех этих кхм "нонконформистов" с владельцами планшетов на андроиде, но одно я могу заявить наверняка - все они хоть раз, да жалели о своем поступке.

Знаете, я за здоровую конкуренцию. Не существуй ее, мы бы с вами сейчас сидели на каменных стульях и деревянными ложками поглощали бы вареное безвкусное мясо, это я вам точно говорю. Именно поэтому, я с умилением и радостью встречаю каждого нового убийцу iPad, который вот-вот и должен скинуть детище Стива Джобса с пьедестала, заняв трон лучшего решения в сегменте. Убийц много, все пытаются всунуться в кабинку, которую занял разжиревший от потока долларов толстяк Apple, некоторые правда только трутся об его тушу, вызывая смех аналитиков и потребителей, а некоторые таки протиснулись, но и им нельзя позавидовать. Давайте начнем с самых ущербных и экзотических экземпляров: таблетки на windows, webos или там там всяких maemo и других линуксах. Прежде всего, производители забывают, что существуют 3 основных вещи, которые необходимы пользователю: время автономной работы от батареи, rich user experience, что в переводе на наш, русский, означает "интуитивно понятный пользователю интерфейс, а не свистоперделки" и, что самое главное, набор готового ПО. Посмотрим на каждый экземпляр: планшеты с windows 7 уебищны от самого своего рождения, их владельцы оправдываются, мол они могут заставить работать на своем подносе любое приложение, которое есть у меня на десктопе. Ну давай, запусти Google Chrome и посмотри, как тормозит, дружок. Смелое заявления, вот только нужно помнить, что никаких ARM процессоров с низким энергопотреблением и тепловыделением там нету, обычно ставят Intel Atom, который мало того, что до жути тормозной, так еще и совершенно не подходит устройствам данного класса по ряду параметров. Я уже молчу о дизайне, сама технология требует от конструкторов приличный по толщине корпус для мощной батареи и теплоотвода, вот и получается, что устройства на Windows 7 мобильны, как парализованный больной на аппарате искусственной вентиляцией легких. Вроде можно с собой взять на вечеринку, показывать друзьям, рассказывать, что он у тебя может все, но мало кто поверит в эти сказки и останется довольным, а больной, скорее всего, умрет через пару часов. Правда, поговаривают, что Windows 8 мало того, что обзаведется поддержкой ARM платформы, так еще и получит пальцеориентированный интерфейс по типу Metro UI в Windows Phone. И вот тут мы можем перейти ко второй группе аутсайдеров во главе с WebOS и прочими альтернативными видениями типа BlackBerry Playbook со своими разноцветными самодельными костылями. Возникает вопрос, зачем? Зачем разработчикам тратить свои человекочасы на изучение абсолютно новой платформы и создавать приложения, когда даже сама платформа нерентабельна и не может окупить ресурсы, потраченные на свое создание. Когда вышел Windows Phone, первое, чем Microsoft пытался заинтересовать пользователей - бесплатные и мощные Developer Tools на базе проверенной годами и любимой многими Visual Studio. Это самый логичный шаг на этапе входа на рынок: разработчикам, которые на самом деле иногда хотят есть или пить, нужно доказать, что приложение, опубликованное в магазине, будут покупать, принося стабильный доход. Если вам поверят, то в ближайшее время ваш Marketplace или Appstore начнет наполняться разнообразным софтом с не менее разнообразным функционалом, нет - будете сидеть такие надутые со своей операционкой, рассказывая про инновационную многозадачность, HDMI порты, какую-то суперсекретную технологию синхронизации и прочую фигню, которая конечному потребителю не упала на половой орган. Или вы думаете, что старина Джобс случайно на каждой конференции не забывает озвучить сумму выплат разработчикам приложений для Appstore или объем их продаж? Вот в чем вся соль, друзья.

Давайте теперь поговорим про планшеты на базе Андроида, которые являются, пожалуй, единственными конкурентами для нелюбимого многими толстяка. Прежде всего, нужно сказать, что любой производитель техники подобной ниши будет идти в форваторе корабля Apple. Нет, разумеется, что не яблочная компания изобрела формат таблеток, подобные решения были задолго до них. Просто они показали, что, упростив все до максимума, лишив пользователя абсолютно ненужного ему доступа к файловой системе или там каким-то глубоким настройкам, можно привлечь миллионы людей, которые не хотят думать о преимуществах Google Chrome над Firefox, а ложатся на диван, кладут себе iPad на пузо и наслаждаются серфингом в интернете и в социальных сетях, ну или чтением новостей, абсолютно не заморачиваясь, сколько у них там свободно оперативной памяти или почему жутко тормозит прокрутка в браузере. По сути, любое решение, появляющееся на рынке, должно иметь что-то, что можно было бы противопоставить iPad-у. Чем хвастают производители андроидных таблеток? Открытая операционная система! О да, это на самом деле важнейший аспект устройства. Гики просто счастливы. Стоит заметить, что исходники Honeycomb до сих пор закрыты и никто из производителей не дает прямого доступа к root filesystem из коробки (более того, тот же HTC устанавливает hardware защиту от подобного девиантного поведения), что заставляет делать такой же jailbreak, как и на яблочных устройствах. Так в чем открытость, господа? Раз в год очередной производитель открывает код своей надстройки над android для прошлогоднего телефона, порождая миллионы альтернативных прошивок от Васи Пупкина из Костромы с новыми иконками и смешными квакающими звуками на смс-ки? Велика честь. Идем дальше, часто производители акцентируют свое внимание на железо, мол у нас дохуяядерный процессор, крутой видеочип от nVidia, опиздеть какое количество портов HDMI и USB. Мне это напоминает процессорные гонки пятилетней давности. Все хвастались количеством ядер, гигагерцами, пиксельными и шейдерными конвеерами, таймингами оперативной памяти. Где это все? Почему в большинство современной мобильной техники устанавливают процессоры с частотой не выше 1,6 GHz? Зрите в к корень, дорогие друзья. Что касаемо современных видеочипов, то я всегда привожу один пример. Представьте, так получилось, что вам в руки попала машина времени, охуенная такая, с кучей кнопок, датчиков и возможностью перемещаться на любое количество лет взад и в вперед. Вот только один нюанс, работает эта машина времени на особых батарейках, которые скорее всего изобретут лет так через 400. И вот сидишь ты в кожаном кресле своего автомобиля из будущего, смотришь на разные датчики и думаешь: "и нахуя же я ее купил за кучу денег, какой мне с нее толк"? Вот так и с андроидом, nVidia Tegra 2 это несомненно крутотенюшка, но зачем? Игр почти нет, а те, которые есть, съедают батарею за считанные часы.  И тут мы в очередной раз упираемся своим носом в распыленный рынок. Приложения, созданные под эту крутую нвидию, не идут на устройствах более низкого класса или с другим чипом. Разработчики должны создавать разные версии под разные платформы, пользователи страдают от малого количества альтернатив, а результат один: абсолютно беспристрастный человек, подержавший в руках iPad или там Motorolla Xoom c 90% вероятностью выберет первый вариант. Да и вообще, сегментация предложения убивает Android: десятки железных конфигураций, десятки версий, производители зарабатывают не поддержкой существующих устройств, получая отчисления от продаж ПО (модель apple о которой я уже писал однажды), а выпуская новые и новые модели пачками, забивая на элементарную поддержку старых. Почему HTC не может выпускать один планшет, доведя его до совершенства? Это остается загадкой для меня.

Меня постоянно спрашивают, не разочаровался ли я в айпаде со времен первого его обзора. Нет, мое мнение абсолютно не изменилось, я даже приобрел себе в личное пользование iPad 2. Это все тот же первоклассный Entertainment PC, заменяющий 80% досуга перед монитором. С него я пишу в твиттер через великолепный официальный клиент, читаю подписки из Google Reader и свою почту, серфю в интернете, играю в кучу разных великолепных игр, просматриваю обновления YouTube-а и события в своем календаре, который тоже синхронизируется с Google. Изредка, я могу воспользоваться TeamViewer (ребятам великий респект за крутое бесплатное ПО) для доступа к своему домашнему серверу или же SSH клиентом для перезагрузки какого-то сервиса, например. То же самое я могу делать и вдали от дома, имея на борту 3G интернет. А при достаточно активном пользовании и постоянно включенном WiFi + 3G, заряжаю я iPad раз в 3-4 дня. Смог ли бы я делать все вышеперечисленное на планшете с WebOS или BlackBerry Tablet OS? Маловероятно. На Android? Скорее всего да, но совершая кучу ненужных телодвижений. Почему я советую выбрать iPad? Вы получаете простоту, которая обладает неограниченным функционалом. Ну а что вы покупаете под этикеткой "очередной убица айпада" - куча ненужного функционала, лишенного простоты. Решать вам.

Вот такой своеобразный пост обожания. Меня конечно же можно называть сектантом, хотя, почитав остальные мои обзоры по тегу "аппле", вы поймете, что это не так. Просто, попробовав все, я пришел к выводу, что альтернатив нет. Согласны? Жмите на кнопку Google +1 в веб версии поста. Считаете меня тупым мудаком - оставляйте комментарий. Ах да, тут же нет комментариев. Ну и кто теперь тупой мудак? Ха-ха! Спасибо за внимание.

Давайте по порядку. Сейчас в моде real-time коммуникации, в техническом смысле этого слова. Контакт, лицокнига, гуглоплюсы - все перечисленные социальные сети имею свой WebIM, позволяющий в реальном времени общаться со своими друзьями и подругами. Правда, концепция там немного другая, чаты этих социалок, как правило, представляют собой JavaScript обертку вокруг XMPP протокола, но смысл понятен. Еще, справедливости ради, стоит заметить, что WebSockets и Server-Sent Events в настоящее время выделены из спецификации HTML5 в отдельные доки, но, опять таки, я утверждаю и буду утверждать, что HTML5 - не технология, а маркетинговый бренд и писькомерялка современных браузеров, поэтому отождествление понятий тут допустимо. Передо мной была поставлена задача создать приложение, позволяющее в реальном времени обмениваться информацией между сервером и клиентом с минимальными задержками. Благо, приложение это исключительно интранетовское и платформа использование - Google Chrome, а значит технически я не был ограничен. Вариантов было несколько: long-polling HTTP запросы, HTTP Streaming или fast-polling, все это называется Comet моделью. И у каждой реализации есть свой недостаток. В спецификации HTTP/1.1 четко указано, что браузер не должен создавать одновременно более 2х параллельных соединений к серверу. Конечно, современные браузеры могут поддерживать десяток connections и подобное нарушение стандарта не является фатальным, но в каждом из вариантов решения есть свои недостатки. Fast-polling, который представляет собой многократное повторение запроса (с завершением сессии) создает приличную нагрузку на сервер, а "висящие" запросы - костыли, которые приводят либо к memory-leak (в последнем фаерфоксе сделать garbage collector для буфера запроса не удосужились, в хроме и сафари память чистится, но только для запросов, возвращающих "Transfer-Encoding: chunked"), к тому же, контролировать Comet сессию сложнее, она может отваливаться без какой-либо видимой причины, да и изначально протокол создавался не для этого. Есть еще BOSH, который используется в вышеупомянутом XMPP, но он заточен больше под создание чатов и готовых решений для этой технологии очень мало. В PaaS Google App Engine, на котором расположен этот блог, есть Channel API, что-то вроде Comet-а, я даже пытался попробовать, но возможности тоже сведены до минимума. Конечно можно еще использовать обертки вокруг flash socket или java-апплета, но не этому учила нас партия.

Вот именно таким путем, перепробовав все вышеназванные методы и оценив ресурсоемкость, я решил остановиться на server-sent events и web-sockets, которые вроде даже выведены из статуса эксперементальных в последних версиях Webkit-а. Начнем с SSE, спецификацию можно почитать тут. По сути, это тот же HTTP Streaming на стероидах. Его смысл заключается в том, что в JavaScript коде или DOM создается объект EventSource со скриптом в src атрибуте или методе-конструкторе. Этот скрипт, прежде всего, должен в контексте "висящего" соединения (хотя и не обязательно) возвращать корректный Content-Type: text/event-stream и в дальнейшем push-ить обновление клиенту в виде строки data: any_text_info \n\n. То бишь, протокол абсолютно односторонний, нас это вполне устраивает, общаться обратно мы можем и через милый сердцу XHR. Есть в нем и вкусности, к примеру, ответ event: test-remote-event \n data: success \n\n, если верить стандарту, можно обрабатывать в addEventListener('test-remote-event' ,function(data){}), правда, это пока только на бумаге. В Chrome Canary у меня работал только event onmessage. Со стороны все всегда кажется таким красивым, но тут начались проблемы, бывает, что поток просто висит. Никакой onerror или onclose не вызывался, сервер продолжает исправно посылать данные, что проверяется curl-ом в консоли, но браузеру пофиг, хотя рестарт страницы помогает. Пробовал в Chrome Stable - та же  заморочка. ЧЯДНТ? Вторая и более серьезная проблема - отсутствие поддержки CORS, Access-Control-Allow-Origin: * отсылается, но браузерам на него с большой колокольни, они возвращают DOM Exception 18. Очередная брешь в стандарте, как так - XHR работает, а EventSource нет. Конечно, это все придирки, можно было бы завернуть трафик через proxy_pass в nginx, но в любом случае, осадок остался. К тому же, нужно уже было думать о проверке наличия \n\n в контенте, иначе была бы вероятность получить побитый ответ. Таким вот путем я и пришел к WebSockets. Рассказывать что-либо про клиентскую часть не имеет смысла, есть спецификация, все это делается одной строкой кода, давайте лучше кратко поговорим, как реализовать подобное на сервере. В качестве server-side для подобных проектов я всегда рекомендую брать NodeJS. Сама парадигма event based неблокирующего асинхронного сервера идеально подходит для высокозагруженных API, а этот самый интранет, он очень большой и запросы ресурсоемкие. К тому же, имеющегося в NPM добра с головой хватит для решения любых задач.

Для демонстрации возможностей, я написал небольшое приложение. Прописано оно по адресу. Работать должно в Chrome, Safari (в том числе и на iPad, iPhone с 4.2) и FF. Но в последнем нужно включить поддержку сокетов. Вот вам мануал. Долго думал, откуда бы взять большой поток данных для наглядного примера, как вспомнил про Twitter Streaming API. Код готового приложения можно невозбранно скачать архивом. Если демонстрация перестанет работать - прошу меня простить, мой старенький сервер очень нежный и неторопливый, и больше времени заняла компиляция node, чем прочтение документации или написание самого кода. Разумеется, в server.js нужно вписать свои логин и пароль. Вообще, я использую sample поток, а вы, прочитав документацию по твиттер апи и twitter-node, можете создать какой-то полезный сервис мониторинга и аналитики хештегов, или выводить в форме границ Украины аватары пользователей, написавших что-то на мове. Фантазии ограничены исключительно возможностями API твиттера, а их более чем хватает.

В заключение, хочу сказать, что я постепенно пересматриваю формат блога, если вам понравилась подобная статья - не поленитесь перейти на веб версию, если в РСС читаете, и воспользоваться кнопкой Google +1. Если соберется немного плюсов, то в ближайшее время мы поговорим про WebWorkers, Forms Validation, нарисуем мужской половой хуй в Canvas, напишем вращающийся чайник на WebGL и попробуем накладывать фильтры и получать информацию из тега <video>.