_{Фото: www.bleepingcomputer.com}

После сообщений о том, что eBay.com сканирует порты на компьютерах посетителей, когда они просматривают сайт, журналисты BleepingComputer решили выяснить, какие еще крупные компании занимаются этим.

Сегодня речь пойдет о phpDaemon — асинхронном модульном демоне-фреймворке, который берёт на себя обработку I/O (libevent) и другие низкоуровневые задачи, присущие демонам. С его помощью легко писать правильные сетевые приложения с блэкджеком и шлюхами.
Из коробки идут сервера FastCGI, HTTP, CGI, FlashPolicy, Telnet, WebSocket (!) — да-да тот самый волшебный пендаль новый протокол от Google. И клиенты mysql, memcached, mongodb… И многое другое, полный список под катом. Работать с сетью действительно просто. Программист средней руки может написать, к примеру, IRC-бота за считанные часы.
В качестве наглядного примера я реализовал вот этот чат на phpDaemon + WebSocket + MongoDB + jQuery. Он наглядно демонстрирует преимущества этой технологии: доставка сообщений мгновенна, накладные расходы при обмене данными минимальны, высока производительность, приложение масштабируется горизонтально. Исходники этого чата (в данный момент 17 кб). Прошу заметить, чат тестировался и работает в Chrome, FF, IE6+, Iron, Safari.

Многие уже наслышаны о революции в расширении HTTP протокола — внедрении технологии WebSocket разработчиками Google Chromium. В данной статье речь пойдет о том, как приручить данного зверя — установке и настройке WebSocket сервера на асинхронном фреймворке phpDaemon.

В Январе была опубликована статья phpDaemon — фреймворк асинхронных приложений. У многих она вызвала смешанные чувства: с одной стороны проект перспективен, с другой – было трудно вникнуть в недокументированный код, и хуже того – позиция автора была, скажем так, не совсем адекватной требованиям сообщества.
Но позиция автора поменялась, а с ней и многое в проекте.
Проект переехал на GitHub. Теперь методы и свойства задокументированы. API сделано более прозрачным и легким для работы, исправлено множество недочетов, повышена стабильность, изменена структура директорий.
Заполняется WIKI. Добавлено много новых возможностей, включая клиент для Postgresql.
Это принесло свои плоды: phpDaemon твердо обосновался на production-серверах многих проектов, и ведет себя стабильно, что не может не радовать.
Также появилось время на реализацию общественно полезных модулей и других фич, будем рады дельным предложениям.

Заранее благодарю за комментарии!

Сегодня я вкратце расскажу о технологии WebSocket, о предпосылках к её появлению, о текущих проблемах и об их решениях.

Помимо уже упомянутого мною двунаправленного коммуникационного канала известного как WebSocket, HTML5 включаетв себя также сервер-push технологию Server-Sent Events (SSE). В то время как WebSocket широко обсуждается, доступно множество реализаций серверов WebSocket, технология уже почти в полном объеме доступна в браузере Google Chrome, SSE, по большей части остаются в тени.

Мы привыкли что HTTP ограничен моделью запрос-ответ, что значит: клиент посылает запрос HTTP и ожидает на него HTTP-ответ. По сути, сервер не может сообщить что-либо клиенту до тех пор пока клиент его его «не попросит». Даже для такой тривиальной вещи как онлайн статус пользователя, нам надо прибегать к различным уловкам. Ну вы знаете – неугомонная изобретательность энтузиастов породила множество таких решений, на что есть собирательное имя Comet. Впрочем, цитируя экспертов: «Comet есть не что иное как гигантский хак». Похоже, HTML 5 призван обогатить нас нативными возможностями, на смену ныне используемому Comet. В случе SSE, HTML5 предоставляет API для открытия специального HTTP соединения для принятия уведомлений со стороны сервера. Взгляните, на то какой простой интерфейс

Вечером 30 июня «Мозилла» явилась в Лондон в Англии, чтобы поведать про дополнения («Mozilla Add-Ons») и показать некоторые новые клёвые особенности грядущего Файерфокса 4.

Вероятно, наиболее впечатляющими (если не считать средства создания дополнений «Add-Ons Builder», основанного на «Беспине») оказались следующие будущие возможности Firefox 4:

→  отображение HTML5-видео (<video>)

→  рисование на холсте (<canvas>)

→  манипулирование изображениями на холсте (анализ пикселов, распознавание лиц с помощью opencivitas)

→  технологии «зелёного экрана» (хромакей) в иллюстрациях и видео, достигаемые анализом цвета пикселов

→  HTML5, встраиваемый внутрь SVG (ура!)

→  SVG как <img>

→  SVG как CSS-фон

→  SVG-фильтры, SVG-маски, SVG-контуры обрезки

→  SVG-анимация

→  inline SVG (то есть SVG внутри HTML5)

→  CSS3: селекторы, @font-face, 2D-преобразования (transforms), переходы (transitions), тени, градиенты, вычисления — calc(2em-10px)

→  API: геопозиция (geolocation), оффлайн (IndexDB, localStorage, AppCache, FileAPI: чтение двоичного содержимого из файла, перетаскивание файлов), веб-труженики (web workers) и сокеты (websockets)

→  контроллер на вебсокетах, запускающий презентацию с мобильника

→  WebGL

Некоторые из этих способностей подтверждались демонстрациями:

→  фильтры CSS3 и маски SVG на HTML5-видео:

В этом топике я хочу рассказать, как организовать WebSocket соединение между браузером, поддерживающим WebSocket и ASP.NET приложением.
В статье описано, как организовать подключение и отослать сообщение подключенному клиенту. Так же, в конце статьи, есть ссылка на исходники рабочего приложения.

Статья и приложение просто пример того, как это все работает, и как можно связать ASP.NET и WebSockets, и вряд ли претендует на руководство по внедрению в текущем виде, однако хорошо демонстрирует основы и может быть доработано.

Ребята из Ericsson Labs сделали наглядное сравнение между технологиями WebSocket и Long Polling.

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

Прочитав «Веб-сокеты временно отменяются», не смог удержаться и решил ответить.

Добрый день, Хабражитель!

Поздравляю всех и каждого с великим Днем Программиста! Желаю рабочего кода, уверенных сокетов и самых продвинутых пользователей!

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

Для реализации такой задачи есть три решения:

• «бесконечный iframe»,
• используя XMLHttpRequest (a.k.a. Ajax),
• используя WebSocket.

Первое решение я сразу «отметаю» (причины объяснять не буду, web-разработчики меня поймут).

Второе решение нравится гораздо больше, но у него есть свои минусы:

• браузер отправляет запрос каждую секунду создавая лишнюю нагрузку на:
  • сервер;
  • ОС, на которой работает браузер;
  • и еще раз на сервер, так как сервер постоянно выполняет запрос БД на выборку последних уведомлений.
• тяжело отследить онлайн-статус пользователя (то есть нужно, например, хранить сессии в БД и постоянно мониторить каждую на timeout).

Третье решение — как раз то, что доктор прописал.

Итак, WebSocket.

Version: 0.2

Возникла у меня потребность атомарного обновления в реальном времени страницы у некоторого количества пользователей в зависимости от действий других пользователей (не гербалайф чат). Понятное дело, можно всё выкинуть в помойку и, по-молодецки, запилить с нуля на tornado/twisted.web, но явно не самый продуктивный путь (да и я не мо́лодец ни разу) когда всё что надо — уже работает на Django и нужно всего-то чуть-чуть… Естественным образом, по сути своей, сюда просится WebSocket. И всё бы ничего но Django WSGI приложение, а этот стандарт не предполагает таких выкрутасов даже близко (пока). Гугления интернетов навели, в очередной раз, на труд известного python-гуру kmike (это без сарказма, т.к. его работы выручали меня лично уже не однократно, за что нижайший ему поклон!).

Итак если вы хотите скрестить ваш Django проект с websocket посредством js библиотеки socket.io или sockjs — вилькоммен!

Протокол WebSocket получил свой номер RFC и опубликован в официальной библиотеке IETF как RFC 6455. Это означает, что черновик спецификаций признан вполне удачным, в целом стабильным и подходящим для стандартизации. Его дальнейшую судьбу будет отслеживать организация IETF, и впереди у потенциального стандарта — два этапа. После «предложенного стандарта» будут рассмотрены улучшения, которые представит сообщество, затем документ RFC может получить статус «драфта» (чернового стандарта) и, в конце концов, может быть признан как полноценный Стандарт Интернета (STD) — из нескольких тысяч кандидатов до такого статуса дожили всего 72.

WebSocket — протокол двунаправленной связи между браузером и веб-сервером. Протокол включает в себя описание запроса клиента и ответа сервера на установление соединения, а также базовое оформление сообщений, передаваемых поверх TCP-соединения.

С помощью WebSocket можно создавать интерактивные браузерные веб-приложения, которые постоянно обмениваются данными с сервером, но при этом не нуждаются в открытии нескольких HTTP-соединений, как XMLHttpRequest или <iframe>’ы.

В качестве авторов RFC 6455 указаны Ян Фетте из Google Security Team и Алексей Мельников (isode.com).

Не секрет, что Украина, это страна, где каждый «владетель» (депутат, чиновники и олигарх) думает, что он умнее всех и считает, что он контролируют процесс, а позже оказывается, что никто его не контролировал. Небольшой анализ предыстории в социально-политическом плане мы с коллегами даем на сайте Фонда качественной политики.

Что же такое JS LOIC, это простейший и не очень хорошо написанный JavaScript размером в 50 строк, технические подробности работы его, и подобных, изложены ниже. Но его уникальность в том, что каждый браузер может стать источником атак, без инсталляции специальных программ и заражения вирусом. Во-первых, каждый школьник и домохозяйка совсем скоро смогут участвовать в атаках, не разбираясь ни в чем, просто получив ссылку и нажав кнопку на странице. Более того, нажимать кнопку не так уж и обязательно, любой массовый ресурс может стать носителем такого скрипта, внедренного в него владельцами или злоумышленниками (не столь важно), но свою цель такие запросы достанут.

Что будем писать

В прошлой статье мы писали простенький эмулятор терминала на PHP. Я думаю, теперь время написать что-нибудь более серьезное, на вебсокетах. Какой язык использовать для работы с вебсокетами..? Питон..? Руби..? JavaScript..? Нет! Раз уж зарелизился Go 1, давайте на нём и напишем ;). Я постараюсь не повторяться и не писать сюда целиком код. Я приведу лишь интересные, на моей взгляд, фрагменты.

Демо

Спасибо пользователю Aleks_ja за возможность посмотреть эмулятор терминала в действии (нужен браузер с последней версией вебсокетов — например это Firefox 11 или последний Chrome). С первого раза оно может не подключиться, если демон не успеет стартовать за 100 мс — попробуйте сначала обновить страницу.



Исходный код веб-терминала доступен на гитхабе. Компилировать вебсокет-демон необходимо самостоятельно (командой go build) — это небольшая мера защиты от тех, кто любит «повзламывать» хостеров ;).

В Windows 8 CP и Server Beta все клиенты и сервера Microsoft WebSocket, включая IE10, сейчас поддерживают финальную версию протокола IETF WebSocket. Кроме того, IE10 реализует предварительную рекомендацию W3C WebSockets API.

WebSockets стабильны и готовы к тому, чтобы разработчики начали создавать инновационные приложения и сервисы. Эта статья представляет собой простое введение в W3C WebSockets API и ниже расположенный протокол WebSocket. Обновленная демонстрация Flipbook использует последние версии API и протокола.

В моей предыдущей статье я описал сценарии использования WebSockets:

WebSockets позволяют Web-приложениям выполнять доставку нотификаций и обновлений в реальном времени, прямо в браузер. Разработчики столкнулись с проблемами, связанными с необходимостью обходить ограничения персоначальной модели взаимодействия HTTP вида запрос-ответ, чей дизайн не предназначен для сценариев реального времени. WebSockets позволяют браузерам открывать двухсторонний, полнодуплексный канал коммуникаций с сервисами на стороне сервера. Каждая из сторон может использовать этот канал для немедленной доставки данных другой стороне. Сегодня сайты, начиная с социальных сетей и игр, заканчивая финансовыми сайтами, могут предоставить лучшие сценарии реального времени, чем ранее, в идеале используя одну и ту же разметку в различных браузерах.

Со времени публикации той статьи в сентябре 2011 года рабочие группы достигли важного прогресса. Протокол WebSocket теперь стал стандартным протоколом, предложенным IETF. К тому же W3C WebSockets API теперь является кандидатом-рекомендацией W3C.

Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных API, различные механизмы IPC, и разные возможности у разных поставщиков. Такие проекты, как WebDriver, пытаются абстрагироваться от этой сложности, к тому же в Сети можно найти десятки других «безголовых» драйверов, использующих WebKit или иные движки. В настоящее время в работе даже находится спецификация W3C на WebDriver.

Инструментирование Google Chrome

Тем не менее, в то время, как создание общего решения является сложной задачей, оказалось, что инструментирование Chrome очень просто, — как я недавно обнаружил при исследовании некоторых вопросов, связанных с сетевыми задержками. Начиная с 18 версии, Chrome теперь поддерживает протокол удалённой отладки v1.0, который предоставляет все возможности браузера с помощью обычного WebSocket!

/Applications/Path To/Google Chrome --remote-debugging-port=9222 # OSX
$> curl localhost:9222/json

[ {
   "devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page;=1",
   "faviconUrl": "",
   "thumbnailUrl": "/thumb/chrome://newtab/",
   "title": "New Tab",
   "url": "chrome://newtab/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]

Сейчас почти не осталось препятствий для создания полноценного SIP клиента в браузере. Необходимый для видео конференций WebRTC уже можно протестировать, например, в Chrome Canary. Существует draft-ibc-sipcore-sip-websocket, который добавляет WebSocket в качестве еще одного транспорта для SIP. И уже появляются первые реализации SIP клиентов:



К сожалению, автор представленного на видео клиента еще не определился будет ли открывать исходники и под какой лицензией. Под катом альтернативные решения с демонстрацией передачи видео…

Мы долго не могли понять почему каждый норовит сделать свой собственный сервис для управления списками дел и почему мы тоже стали жертвой этого стремления, но работа над нашим GTD-приложением, о котором пойдет речь ниже, помогла нам прийти к гипотезе.
Оглянитесь вокруг, много ли вы знаете туду-сервисов? — Тьма. А пользуетесь каким-нибудь? — Вероятно. Но все ли вас в нем устраивает? Скорей всего — нет.
Наверняка вы знаете уйму недостатков в сервисе, с которым работаете ежедневно, но продолжаете пользоваться им потому, что ничего лучше вы все равно еще не нашли. Если вы — разработчик, настает день когда вы понимаете, что настало время «точить пилу» и вы начинаете делать свой таск-менеджер. Постойте, но почему?

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

Веками для запоминания чего либо использовалась бумага. Она хорошо выполняет свою роль по двум причинам: во-первых, она, как известно, все стерпит, а во вторых, она ничего не навязывает. Иными словами, бумага сочетает в себе функциональность и простоту. Глубоко проникнувшись этой идеей, мы сделали свой продукт.
Что мы понимаем под этим? Эйнштейн говорил «Сделай настолько просто, насколько это возможно, но не проще.» Мы, следуя этому принципу реализовали все фундаментальные инструменты управления делами, но в тоже время мы сделали их максимально обобщенными и ненавязчивыми. Именно поэтому, если вам нужен некоторый инструмент, то вы сможете пользоваться им применительно к любой предметной области, а если он вам не нужен, то вы даже можете не заметить его существования. Т.е. мы не навязываем методологию, мы просто даем набор идеально заточенных инструментов.

Дальше меньше общих слов и больше технологических подробностей. Картинка клибельна.