Чи може WordPress зробити так, щоб підтримувати веб-розетки?

Веб-розетки - це класна, найсучасніша технологія, загорнута в HTML5. В основному, ви можете відкрити веб-розетку, щоб забезпечити постійне, двостороннє спілкування з веб-сервером. Клієнт (інтерфейс користувача) може самовільно надсилати повідомлення, а сервер також може надсилати повідомлення.

Існуюча технологія (JavaScript) вимагає, щоб все починалося клієнтом - сервер не може надсилати клієнту нічого, чого клієнт не запитує. Тому сценарії потрібно постійно оновлювати та повторно запитувати дані, які, можливо, не змінилися. Веб-розетки працюють більше на принципі " натискання " і дозволяють нові дані надходити кожен раз.

На жаль, для більшості (все, що я можу знайти) реалізацій websocket потрібен певний серверний додаток для роботи. Люди запускатимуть Apache на порти 80 та 443 (http та https) та запускають іншу систему (зазвичай Node.js) на іншому порту (тобто 8000 чи 8080) для обробки запитів на веб-сокети.

Це, очевидно, працює, але це має деякі недоліки.

У мене є плагін, який я хочу створити, який би дуже виграв від використання веб-сокетів в WordPress. Але якщо користувачеві потрібно встановити другий веб-сервер (зазвичай це неможливо для людей із спільним хостингом), він не працюватиме як плагін.

Отже, для когось із вас, хто має досвід, як би ви зробили WordPress сумісним із веб-розетками? Ви б змусили WordPress керувати самим спілкуванням або з’єднати інший міні-серверний скрипт у плагін? Якщо ви вже зробили це, як ви це зробили, не порушуючи WordPress?

Можливі ресурси?

• Розширюваний сервер веб-сокетів
• PHP Websocket
• PHP та веб-розетки

9/21/11 Оновлення

Зважаючи на всі розмови про те, як Apache (найчастіше встановлений сервер для запуску WP на спільному хості) насправді не може самостійно обробляти веб-сокети, мені цікаво про альтернативу. Кілька плагінів (наприклад, JetPack) спілкуються із зовнішньою службою чи API для створення вмісту.

Статистика запитує вміст від Automattic. Akismet посилає дані назад і назад із зовнішнього сервера. Після того, як Кінцевий термін подає вміст у час публікації Кілька інструментів SEO передають речі назад і назад через зовнішні системи.

Отже, як альтернатива розміщенню коду websocket у плагіні WordPress, чи можливо зробити розміщення служби веб-сокетів у центральному місці, а замість цього взаємодіє фронтмен WordPress?

WebSockets використовують протокол websockets: WS: /example.com/yourscript.js та відкривають синхронне з'єднання - це означає, що з'єднання відкрито та призначене для браузера.

Сервери httpd, як-от apache2 (використовується більшістю постачальників послуг, що користуються спільним хостингом), використовують протокол http: http://example.com/yourscript.jsі відкривають асинхронне з'єднання - це означає, що між сервером та браузером жодне з'єднання не відкрите. (Ви можете продовжувати відкриті з’єднання, скромно, встановлюючи певні параметри конфігурації, але загалом кажучи, це асинхронно.)

Як ви можете уявити, підтримка відкритого з'єднання між браузером та сервером приділяє більше серверних ресурсів для кожного з'єднання браузера, а отже, більше оподатковує серверні ресурси, ніж скасовує з'єднання після кожного запиту. Очевидно, що провайдери спільного хостингу відмовляються підтримувати WS у спільному хостингу.

Хоча в деяких спільних хостах може бути встановлений mod_python , що дозволяє користувачам плагіну запускати pywebsocket , у власній документації pywebsocket чітко зазначено, що "pywebsocket призначений для тестування або експериментальних цілей".

Таким чином, хоча можна уявити код python, що поєднує плагін, щоб створити сервер pywebsocket, враховуючи сервер apache, який його підтримує, я не вважаю, що було б розумним розповсюджувати плагін, який це робив.

У відповідь на ваше оновлення, на мою думку та на основі проведених нами досліджень, це був би найкращий варіант. Ще краще було б створити плагін на передньому кінці та створити зовнішню службу веб-розмов для розмови з плагінами та стягнути плату за нього, щоб ви могли монетизувати свою ідею, якщо хочете. Ви навіть можете надати вихідний код для служби websocket і створити в плагіні налаштування, щоб встановити, де (в якому домені / IP та порті) знаходиться веб-розетка.

Забудьте для цього "класичний" apache2 - apache2-mpm-prefork. Можливо, apache2-mpm-event може впоратися з цим, але це експериментально. Оскільки apache2 не керується подіями, проблема, описана @marfarma, існує. Вам потрібен веб-сервер, орієнтований на події, для такого типу подачі, наприклад, cherokee або nginx.

nginx може бути реальною вигодою для WordPress (оскільки wordpress.com також використовує його як свій сервер), і він може проксі-сервіси задавати запити до служби node.js, наприклад.

Деякі приклади в темі:

• Веб-розетки в Nginx (із Socket.IO та Gevent)
• Проксі-сервер веб-сокетів з nginx

Я також зробив невеликий підручник для налаштування nginx + php-fpm + wordpress .

Іншим потенційним рішенням є використання стороннього постачальника веб-розеток. Я трохи пограв з Pusher (http://pusher.com/), є API, який ви можете використати, що може добре працювати для того, що ви намагаюся зробити. Я роздумував над тим, як я міг би використати це на власних сайтах WordPress.

Можливим недоліком є ​​те, що інші люди, які намагаються використовувати ваш плагін, також повинні мати обліковий запис Pusher, щоб він працював. З цим набагато простіше працювати, ніж встановлювати власний сервер Web Sockets і потребувати його підтримки, це насправді буде перевагою насправді, коли справа доходить до інших, хто намагається використовувати ваш плагін.

Коротка відповідь: так, це можливо. Хоча я можу розібратися в чомусь більш розподіленому, ніж в одній точці відмови VPS, який ви розміщуєте. Можливо, подивіться на якісь системи збалансованого навантаження EC2 чи щось таке? (Я припускаю, що у вас є потік доходу, щоб забезпечити такі зручності. Усмішка )