live chat i websocket, wydajny chat Opcje

[bialko0019]

Witam. CHciałbym stworzyć w miare wydajny ( zakładam około 5tyś userów dziennie, z czego np. 1/4 będzie używała wiadomości w danym dniu ) i chciałbym zrobić chat dla nich. Jak myślicie, serwer wytrzyma połączenie typu ajax i php, gdzie intervalem lacze sie co kilka sekund, i sprawdzam czy jest nowy id, jeśli tak to pobieram wiadomość nową? Jeśli raczej nie ma szans, to jak z kompatybilnością i obsługą jest z websocket? Słyszałem o nim, że o wiele łatwiej, jeśli chodzi o wydajność, ale serwis ma być też responsywny a więc i mobilne przeglądarki mogą różnie to interpretować. Jest sposób na obejście websocketa ( nie wiem z czym się go je itd, a czas mnie trochę goni... )

[Skie]

Widzę, że wolisz rozwiązanie PHP i odniosłeś sie w swoim poście do linka, który podałem , więc wytłumaczę Ci wszystko wg. działania Ratchet. Server.php to plik, który uruchamiasz na serwerze za pomocą komendy z konsoli serwera - np. przez putty.

[PHP] pobierz, plaintext 
php server.php
[PHP] pobierz, plaintext 

Powinien on w nieskończonej pętli czekać na przychodzące wiadomości socketowe i w momencie otrzymia takiej wiadomości odpalać odpowiednią funkcję. Oczekiwanie, wyłączenie timeoutów PHP i całą warstwę odpowiedzialną za demonizację procesu PHP odpowiada moduł React/Loop, którego Ratchet używa, więc tutaj nie musisz się przejmować o tego typu problemami - tj. "wygasaniem" PHP.

Wspomniany serwer musi implementować 4 podstawowe funkcje - onStart, onStop, onMessage i onError - pierwsza uruchamiana jest w przypadku utworzenia nowego połączenia, druga w przypadku zamknięcia istniejącego, trzecia w przypadku otrzymania wiadomości i czwarta w przypadku błędu. Najważniejsza jest trzecia

[PHP] pobierz, plaintext 
onMessage(ConnectionInterface $conn, MessageInterface $message)
[PHP] pobierz, plaintext 

. Funkcja ta ma podobne zadanie jak routing HTTP w przypadku frameworków MVC - odbierasz wiadomość $message od użytkownika $conn i następnie ją parsujesz i przkazujesz do odpowiedniego kontrolera w aplikacji. Odpowiedź generujesz za pomocą $conn->send(MessageInterface $response).

Dla porównania w MVC routing zrobiłbyś mniej więcej tak:

[PHP] pobierz, plaintext 
Router::setController('/hello', new HelloWorldController());
[PHP] pobierz, plaintext 

Odpowiednik tego przy weboscket (ratchet) byłby taki:

[PHP] pobierz, plaintext 
onMessage(ConnectionInterface $conn, MessageInterface $message) {
    switch ($message['get']) {
        case '/hello': 
            $controller = new HelloWorldController();
            break;
 
         /* ... */
    }
 
    $conn->send(
        $controller->someAction($message)
    );
}
[PHP] pobierz, plaintext 

Oczywiście możesz tutaj jaki syntax-sugar samemu zrobić by zapis byłby prostszy i np tworzyć nowe routingi za pomocą czeogś w stylu:

[PHP] pobierz, plaintext 
Websocket::setController('/hello', new HelloWorldController());
[PHP] pobierz, plaintext 

To wszystko - łatwo, prosto i przyjemnie.

W tym momencie widzisz, że HTTP i WebSocket to osobne wejścia do Twojej aplikacji, ale jestes w stanie połączyć je obie z istniejącą już architekturą. Problemem jaki możesz napotkać to obiekt $Request, który może w tym przypadku nie istnieć wewnąrz aplikacji, która normalnie używa HTTP. Jeśli moduły z których chcesz skorzystać używają aktywnie Request i nie znajdziesz sposobu by zamockować go przy websocket, to możesz rozwiązać ten problem w taki sposób, by serwer.php po otrzymaniu wiadomości socket, wysyłał lokalnie zapytanie HTTP do Twojej aplikacji , czekał na odpowiedź i następnie odsyłał wiadomość przez socket. Postaraj sie jednak użyć tego w ostateczności.

W kwestii zarządcy, to problem jest taki - PHP domyślnie jest jednowątkowe - to oznacza, że jakikolwiek Fatal Error lub Unhandled Exception zamknie proces server.php , a co za tym idzie, Twoje webosckety przestaną działać. Rolą zarządcy jest monitorowanie danego procesu - tutaj server.php z poziomu systemu operacyjnego - po to, że jeślli zakończy on działanie, zarządca uruchomi go ponownie. Dzięki temu niebędziesz musiał się bać, że w przypadku wysypania się któregoś modułu Twoja aplikacja przestanie działac.

UWAGA:
Nie przepisuj kodu PHP, który podałem w tym poście słowo w słowo, gdyż jest to pseudokod pisany z pamięci, by dać Ci ogólne pojęcia jak to ustrukturyzować. Dokładne zapisy weź z manuala Ratchet.

Ten post edytował Skie 20.08.2015, 01:39:09