Рубрика «WebSocket» - 8

Websocket′ы полезны постоянным дуплексным соединением backend-сервера с браузером клиента — это прочный мост между сервисом и посетителями, по которому удобно беспрепятственно транспортировать потоки данных в обе стороны.

В результате внедрения websocket′ов наш проект получил возможность в реальном времени менять по своему усмотрению отображение страниц в браузере на протяжении всей клиентской сессии и иметь обратную связь.

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

Однако, когда дело дошло до полевых испытаний, обнаружилась масса проблем с ISP, всеми мыслимыми и немыслимыми способами пытающимися сэкономить трафик за счёт своих клиентов. Об этих и других «граблях» полноценного боевого внедрения websocket′ов читайте под катом.Читать полностью »

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

Читать полностью »

Предупреждение: если у вас есть претензии к бенчмарку и/или к коду, бенчмарк выложен на Гитхабе, что позволяет вам править баги самим или сообщить о багах автору.

Подробнее о проблеме 1000 соединений: ru.wikipedia.org/wiki/Проблема_10000_соединений

Как с проблемой 1000 соединений через вебсокеты справятся Erlang, Go, Haskell (Snap), Java (Webbit), Node.js (websocket) и Pythin (ws4py)?

Читать полностью »

Предупреждение: если у вас есть претензии к бенчмарку и/или к коду, бенчмарк выложен на Гитхабе, что позволяет вам править баги самим или сообщить о багах автору.

Подробнее о проблеме 10000 соединений: ru.wikipedia.org/wiki/Проблема_10000_соединений

Как с проблемой 10000 соединений через вебсокеты справятся Erlang, Go, Haskell (Snap), Java (Webbit), Node.js (websocket) и Pythin (ws4py)?

Читать полностью »

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

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

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

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

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

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

Читать полностью »

image Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных 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"
} ]

Читать полностью »

В 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.Читать полностью »

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

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

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

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js