Czy WordPress może być przystosowany do obsługi gniazd sieciowych?

Websockets to fajna, najnowocześniejsza technologia opakowana w HTML5. Zasadniczo można otworzyć gniazdo sieciowe, aby umożliwić trwałą dwukierunkową komunikację z serwerem WWW. Klient (interfejs użytkownika) może spontanicznie wysyłać wiadomości, a serwer może również wysyłać wiadomości.

Istniejąca technologia (JavaScript) wymaga, aby klient uruchomił wszystko - serwer nie może wysłać do klienta niczego, czego klient nie zażąda. Dlatego skrypty muszą stale odświeżać i ponownie żądać danych, które mogły się nie zmienić. Websockets działają bardziej na zasadzie „ push ” i pozwalają, aby nowe dane pojawiały się w potoku za każdym razem.

Niestety większość (wszystko, co mogę znaleźć) implementacji websocket wymaga do działania określonej aplikacji serwera. Ludzie uruchomią Apache na portach 80 i 443 (http i https) i uruchomią inny system (zazwyczaj Node.js) na innym porcie (np. 8000 lub 8080), aby obsłużyć żądania Websocket.

Działa to oczywiście, ale ma pewne wady.

Mam wtyczkę, którą chcę zbudować, która bardzo skorzystałaby na korzystaniu z websockets w WordPress. Ale jeśli użytkownik musi zainstalować drugi serwer WWW (zwykle niemożliwy dla osób korzystających z hostingu współdzielonego), nie będzie on działał jako wtyczka.

Tak więc, dla każdego z was, którzy mają doświadczenie, w jaki sposób uczynić WordPress kompatybilnym z gniazdami internetowymi? Czy sprawisz, że WordPress sam zajmie się komunikacją, czy umieścisz w skrypcie inny skrypt mini-serwera? Jeśli już to zrobiłeś, jak to zrobiłeś, nie psując samego WordPressa?

Możliwe zasoby?

• Rozszerzalny serwer gniazd sieciowych
• PHP Websocket
• PHP i Websockets

Aktualizacja z 21.09.11

Biorąc pod uwagę, w jaki sposób Apache (najczęściej instalowany serwer do uruchamiania WP na współdzielonym hoście) nie może tak naprawdę natywnie obsługiwać gniazd sieciowych, zastanawiam się nad alternatywą. Kilka wtyczek (na przykład JetPack) rozmawia z zewnętrzną usługą lub interfejsem API w celu wygenerowania zawartości.

Statystyki żądają treści od Automattic. Akismet wysyła dane tam iz powrotem z zewnętrznego serwera. Po upływie terminu przesyła treść w momencie publikacji. Kilka narzędzi SEO przesyła rzeczy tam iz powrotem przez systemy zewnętrzne.

Czy jako alternatywa dla umieszczenia kodu websocket we wtyczce WordPress byłoby możliwe hostowanie usługi websocket w centralnej lokalizacji i interakcja z tym frontendem WordPress?

WebSockets używają protokołu Websockets: WS: /example.com/twoi.js i otwierają połączenie synchroniczne - co oznacza, że ​​połączenie jest utrzymywane otwarte i dedykowane przeglądarce.

Serwery httpd, takie jak apache2 (używany przez większość dostawców hostingu współdzielonego), używają protokołu http: http://example.com/yourscript.jsi otwierają połączenie asynchroniczne - co oznacza, że ​​żadne połączenie nie jest utrzymywane otwarte między serwerem a przeglądarką. (Możesz skracać otwarte połączenia, skromnie, ustawiając pewne parametry konfiguracyjne - ale ogólnie mówiąc, jest to asynchroniczne).

Jak można sobie wyobrazić, utrzymywanie otwartych połączeń między przeglądarką a serwerem przeznacza więcej zasobów serwera dla każdego połączenia przeglądarki, a zatem bardziej obciąża zasoby serwera niż zrywanie połączeń po każdym żądaniu. Dostawcy hostingu dzielonego są, co zrozumiałe, niechętni do wspierania WS na hostingu współdzielonym.

Chociaż niektóre hosty współdzielone mogą mieć zainstalowany mod_python, umożliwiając tym samym użytkownikom wtyczki uruchomienie pywebsocket , własna dokumentacja pywebsocket wyraźnie stwierdza, że ​​„pywebsocket jest przeznaczony do celów testowych lub eksperymentalnych”.

Tak więc, chociaż można sobie wyobrazić wtyczkowy pakiet Pythona do stworzenia serwera pywebsocket, biorąc pod uwagę serwer Apache, który go obsługuje, nie sądzę, aby rozpowszechnianie takiej wtyczki było rozsądne.

W odpowiedzi na twoją aktualizację, moim zdaniem i na podstawie przeprowadzonych przeze mnie badań, byłaby to najlepsza opcja. Jeszcze lepiej byłoby stworzyć wtyczkę front-end i stworzyć zewnętrzną usługę websocket, aby rozmawiać z wtyczkami i pobierać opłatę za nią, abyś mógł zarabiać na swoim pomyśle, jeśli chcesz. Możesz nawet podać kod źródłowy usługi websocket i utworzyć ustawienie we wtyczce, aby ustawić gdzie (która domena / IP i port) znajduje się usługa websocket.

W tym celu zapomnij o „klasycznym” apache2 - apache2-mpm-prefork. Może zdarzenie apache2-mpm-może sobie z tym poradzić, ale jest eksperymentalne. Ponieważ apache2 nie jest sterowany zdarzeniami, problem opisany przez @marfarma istnieje. Do tego rodzaju serwowania potrzebny jest serwer internetowy sterowany zdarzeniami, na przykład cherokee lub nginx.

nginx może być prawdziwą korzyścią dla WordPress (ponieważ wordpress.com używa go również jako serwera) i może na przykład przekazywać określone żądania do usługi node.js.

Kilka przykładów w temacie:

• Websockets w Nginx (z Socket.IO i Gevent)
• Proxy serwera Websocket z nginx

Zrobiłem także mały samouczek dotyczący konfiguracji nginx + php-fpm + wordpress .

Innym potencjalnym rozwiązaniem jest skorzystanie z zewnętrznego dostawcy gniazd sieciowych, trochę grałem trochę z Pusher (http://pusher.com/), istnieje interfejs API, z którego można skorzystać, który może dobrze działać w przypadku próbuję zrobić. Zastanawiałem się, jak mogę to wykorzystać na własnych stronach WordPress.

Możliwą wadą jest to, że inne osoby próbujące użyć wtyczki musiałyby również uzyskać konto Pusher, aby działało. O wiele łatwiej jest pracować niż instalować własny serwer Web Sockets i utrzymywać go, co w rzeczywistości byłoby zaletą, jeśli chodzi o innych, którzy próbują korzystać z Twojej wtyczki.

Krótka odpowiedź brzmi: tak, jest to możliwe. Mogę jednak spojrzeć na coś nieco bardziej rozproszonego niż pojedynczy punkt awarii VPS, który hostujesz. Może zajrzysz do niektórych systemów EC2 z równoważeniem obciążenia lub czegoś takiego? (Zakładam, że masz strumień dochodów zapewniający takie udogodnienia. Uśmiech )