Блог

Web hosting websockets

Я думаю для интерфейсов даже HTML отомрет, будут прямо на канвасе интерфейс рисовать со всеми кнопочками и ляляками. Masterkey 24 декабря в Masterkey 25 декабря в А какой смысл? Думаю то, что предусмотренно в HTML через него сделать проще и браузером будет обрабатываться быстрее.

Кнопки же в HTML как правило не делают картинками с обработчиком если нет каких-то сильно необычных требований. Вообще, во многих web application, да и на многих обычных сайтах кнопки делают в виде ссылок с картинкой это не повод к холивару о том, правильно ли это, но тем не менее это факт.

А DOM в браузерах ооочень медленный. Особенно в FF и IE. Но, на мой взгляд, это скорее недоработка HTML — невозможность через него сделать картинку кнопкой. Как и многое другое. DOM, конечно, медленный. Но не думаю, что canvas, управляемый js, будет работать быстрее. С чего бы? DOM все-таки львиную часть работы по отрисовке отдает скомпилированному коду. Canvas —.

DOM помимо отрисовки выполняет ещё множество вещей, связанных с определением правильного положения элементов, их размеров и. Кроме того, я не знаю никакой возможности хоть как-то буферизовать изменения свойств узлов дерева. Мне кажется, что канвас на специфических задачах навороченного и очень динамического GUI вполне может оказаться быстрее. Тем более, что скрипты сейчас чуть ли не в нативный код компилируются. В специфических — безусловно. Но думаю, что все-таки с простой ссылкой работа будет быстрее, чем с нарисованным в canvas текстом и обработчиком на.

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

Но и простое отображение текста через canvas —. Где-то в промежутке есть задача, которую одинаково сложно делать как на HTML, так и с cavnas. Ну вот… hollywar detected: TimTowdy 25 декабря в Ставьте родительскому элементу св-во display: Довольно известный трюк.

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

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

Спасибо за ссылку: Пора спать! Договориться, как отображать HTML гораздо сложнее чем как рисовать на канвасе. Описание стандарта будет тупо больше, поэтому и сложее.

Live Stream #30: Creating Real-Time Shared Canvas with WebSockets

А значит место для разночтений и ошибок. А строить интерфейсы все равно будут через либы типа ExtJS. Barttos 24 декабря в Как пример bespin.

Web Sockets — TCP для веба | Учебник HTML5

Ну насколько я понимаю речь идёт не о сайте https: Если я ничего не перепутал, этот их продукт — онлайновый html-редактор. Это весьма странно. Я тоже зарегистрировался и тоже смотрю под фаерфоксом, и, насколько я вижу, сам редактор — это всё-таки canvas.

Прочие вспомогательные элементы интерфейса, вроде кнопок сохранения, всё-таки html. Старый добрый HTML рано списывать со счетов, он много на что годится. TheShock 11 марта в Выглядит красиво: Ждем полноценной поддержки всеми браузерами и серверами: Я что-то не понял, оно держит открытым соединение?

Если это так, то полный ахтунг, это же какие нагрузки! А какие нагрузки от неактивного соединения? Как раз постоянное подключение-отключение создаст большую нагрзку. Максимально возможное количество соединений ограничивается ядром, в данном случае оно должно будет быть увеличено, что строго говоря не есть гуд.

И в чем не гуд? Если надо, то надо чтобы было гуд, патчи там и тп, если сейчас что-то мешает: Оно настраивается.

Вот пример сервера, который поддерживает 1 миллион коннектов, да не просто поддерживает, а работает с ними: Как же давно я этого ждал! Теперь смогу графики и логи в браузере смотреть в реальном времени.

Вышеприведённый скрипт демонстрирует, как клиент слушает сервер. А вот ws. Это первая вводная статья. Если будет интерес — то продолжу дальнейшие изыскания. Я подумал, что она и так уже длинная — чтобы не мучать читателя часть технологии опустил. Надо попросить Сысоева добавить поддержку проксирования таких приложений. Не выделять же под это отдельный IP-шник…. Сам уже об этом подумал: Я думаю Игорь добавит в nginx хороший мультиплексор и это позволит еще снизить нагрузку на сервер по поддержанию множества сокетов.

Половина дороги пройдена, ура. Это тоже не сокеты. Goodkat 24 декабря в Ну, это препятствие P2P-сети преодолевают через промежуточные незафайерволленные узлы. Флеш умеет использовать как свои сокеты www. Kane 5 января в Flash обременяет разработчика средством разработки, а пользователя необходимостью это flash установить.

И всё это при том, что как средство разработки, так и плагин производятся одной фирмой и не имеют альтернатив. Будучи ламером и параноиком, спрошу: Jama 24 декабря в Наверняка даст. Как только пойдут массовые реализации, начнутся и грабли, которые в спецификации не описаны: Почему тогда у каждого браузера своё ограничение? В споре кривизны с прямизной, однозначно победит кривизна: С проксями получается такая ситуация: Впрочем я не исключаю, что в скором времени они научатся поддерживать веб сокеты.

Могу путать, но где-то проскавала цифра 2 или 4. Конечно, это не жесткое ограничение — никто не мешает на своем фаерфоксе поставить цифру побольше. Однако есть некоторое официально рекомендованное значение, чтобы вы ненароком сервер не уронили. Подскажите мне, неспециалисту, а чем это принципиально отличается от того, что сейчас реализовано во Flash?

Насколько я понимаю поправьте, если ошибаюсьFlash уже давно может устанавливать асинхронные TCP соединение? YouTube, Augmented reality, игрушки всякие? Тем что флеш — это хак, при чем очень грязный и в большинстве случаев его использования — абсолютно не нужный. Рискну уйти глубоко в минус по рейтингу, но можете чуть поподробнее почему флэш является хаком? Я, к сожалению, больше по desktop решениям, но websockets даже для них открывает широчайшие перспективы: Я думаю, автор имел в виду, что с помощью флеша часто обходят ограничения того же http и других доисторических прелестей, живущих у нас в браузере.

Установка WebSocket – Вопросы Timeweb Community

Да, мы делали транспортную часть между Javascript-приложением на flash. В итоге от неё отказались по двум причинам: То есть включить наш, естественно, невидимый, флэш он не сможет. Разумеется, кроме флэша была и другая реализация двустороннего обмена данными. Это всё таки суррогаты, а не полноценные сокеты. Levsha 24 декабря в WebSockets — гвоздь в гроб IE. Не уверен, что другие компании действительно быстро подтянутся.

Хром заставил зашевелиться остальных из-за того, что при переходе на него пользователь сразу получал существенные преимущества. Для использования же WebSockets веб-приложения должны писаться в рассчете на.

Сервер PHP Websocket на хостинге Linux

Пока эта технология не будет поддерживаться браузерами большинства пользователей — этого не. Пока не будет достаточно большого количества таких приложений — производителям других браузеров беспокоиться смысла. Получится ситуация в чем-то аналогичная связанной с IE6: Но конкретный сайт, не поддерживающий IE6 из-за этого потеряет посетителей. Конкретный сайт, требующий WebSockets —. Возможно, некоторым компромиссом будет реализация двух вариантов — с сокетами и без них или использование того же web-socket-js.

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

php - Сервер PHP Websocket на хостинге Linux - Qaru

Разве что в браузерах, поддерживающих сокеты, можно будет делать что-то существенно лучшее, чем без. Чем ситуация будет принципиально отличаться от, скажем, canvas? Он уже работает во всех основных браузерах, кроме IE. И часто его встретишь где-то кроме демонстрационных страничек? Можно было букв поменьше: Если да, то прекрасное так и останется далеко….

регистрация в домене fm

Скорее уж известная своим остроумием MS напишет свои MsSockets, с блекджеком и шлюхами: Учитывая ещё, что в половине сайтов простой Javascript глючит: Тут опять же пользователи браузеров с поддержкой WS окажутся в выигрыше. Glebushka 24 декабря в Wott 24 декабря в Я не стал раздувать статью, чтобы не мучать читателей. Если бы вы это видели, это было бы уже не пророчество а реальность: Я думаю после внедрения веб сокетов и полноценного HTML5 и CSS3 то Google Wave выстрелит так как будет менее ресурсоемкое и более шустрое, да и по идее вебсокеты будут жрать меньше ресурсов сервера да и юзера Если бы еще по дефолту все бы жалось в gzip….

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

Рад, что гугл со мной солидарен: Манипулируя где? Эти заголовки нужны для защиты от сайтов злоумышленников, открываемых пользователем в том же браузере. А за корректностью этих заголовков будет следить сам браузер пользователя.

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

О чем и речь. Особенно если подсунет корректный Origin: Иными словами домены по вопросу данного клиента должны между собой перепихнутся. И чем этот перепих лучше тупого проксирования? По-моему, это слишком похоже на нынешний Referer. Те, кто пытается ограничивать людей только по этому признаку — теряют посетителей из поисковиков и сливают достаточно тупым ботам, не получив никакой выгоды в замен.

Видимо, эта хрень тоже будет использоваться только в сочетании с дополнительными обвязками. Да, Origin присылается браузером, то есть потанциально его можно сфабриковать. Но тут такая картина — из яваскрипта его изменить нельзя, браузер сам пришет что. Если вы взломали браузер — то вы сможете слать что угодно — здесь уже не до проверки Origin-a.

То есть такая схема не добавляет новой уязвимости, но дает больше возможностей. Может быть, я не понимаю чего-то связанного с AJAX — но чем такая модель хуже нынешней? Браузер, думаю, не должен позволять менять Origin, а своими средствами в любом случае можно отправить какие угодно заголовки куда угодно. Так как эти ограничения невозможно сформулировать достаточно строго, то их невозможно реализовать, а значит браузер и не обязан этого делать.

И это правильно. Same Origin Policy — вещь конечно хорошая, но иногда она очень мешает. Сейчас сервисы взаимодействуют между собой всё чаще. Почему квази? С лонгполом реальный реалтайм — есть данные, тут же и получаешь.

Потому что зависит от логики реализации AJAX-а. Любые другие рекомендации? Если вы получили эту настройку, вы можете взглянуть на socket. Есть несколько примеров того, как настроить его на своих сайтах, и вы можете взглянуть на этот пост в блогев котором есть несколько примеров как настроить node. Theres второй вариант запуска сервера сокетов на основе php, хотя и не так хорош, как опция выше, но он может, вероятно,?

PHP имеет базовые функции seme для создания сервера сокетов, которые перечислены. Есть несколько примеров того, как настроить такой. И здесь также этот qaru. Таким образом, новые клиенты не могут работать со старыми серверами и наоборот. Насколько быстро сломается то, что уже сделано в Web Socket-ном вебе?

В принципе уже начало ломаться. Гугловцы обещаличто WebKit, начиная с ревизии r, и Chrome, начиная с версии 6. А это значит, что нам сейчас надо срочно обновлять наши сервера. Давайте рассмотрим, что именно изменено и ради чего такая спешка, что даже потребовалось ломать рабочие версии.

Основные изменения связаны с безопасностью подключения. Например, чтобы нельзя было послать из браузера AJAX-запрос максимально похожий на установление веб-сокетного соединения и тем самым атаковать веб-сокет сервер. Для этого в протокол был добавлен целый ряд заголовков, начинающихся на sec. Сравним старый и новый запрос на установление подключения по Web Socket: Старый запрос: WebSocket Connection: Upgrade Host: Upgrade Sec-WebSocket-Key2: Название - ваше собственное, можно использовать, например, chat или sample или еще какое-нибудь.

Данный заголовок позволяет проверить, что и сервер, и клиент поддерживают ваш протокол. Если это не так, то соединение будет сброшено. Это немного упрощает проверку поддержки конкретного протокола или его версии, экономит вам несколько строк кода.

Обрабатываются они одинаково: Мы должны получить такой результат: В данном случае 12 и Каждое число делится на соответственное количество пробелов.