PubSub Opcje

[kpt_lucek]

Witajcie

Borykam się z pewnym problemem, mam przygotowany mechanizm PubSub (Websocket).

Opierając się o autobahn napisałem chat od strony klienta, a gosws serwer.

To z czym mam problem, bądź mi nie pasuje:
1) Serwer umiera przy dużej liczbie połączeń, cron "lata" co minutę i stara się reanimować, co w efekcie powoduje kolejne padnięcie trupem,
2) Tym mogę wyciągnąć usera, a co za tym idzie - podczas requesta, poza danymi leci również ciastko (imo nie powinno, nie do tego jest pub&sub nie?),
3) Alternatywa crossbar działa fajnie, 20k requestów/s nawet nie gryzie, aczkolwiek nie ma sharowania ciastek (przynajmniej na tym etapie dokumentacji na którym jestem, ale to nie istnotne), a poza tym i tak potrzebuję subscriber'a i publisher'a od strony php, co za tym idzie, sytuacja bardzo podobna do 1, mianowicie - dużo requestów, apka pada.

to co chcę uzyskać, to względnie wydajne narzędzie, bazujące na czymś co (najlepiej) już jest (chociażby wspomniany crossbar), możliwość względnie bezawaryjnego "słuchania" i "nadawania" do dowolnego użytkownika/grupy użytkowników na kanale, szyfrowanie to swoją drogą. Można by zapewne autoryzować użytkownika po tokenie dołączonym do payload'u, ale tutaj security fkup (tak, wiem że podwędzenie użytkownika i hasła do komputera też może się "stać").



Jakieś sugestie?

[by_ikar]

Cóż, nie może wyjść nic dobrego z puszczenia php w wieczną pętle, bez dostosowania samego serwera php do tego, dlatego to narzędzie jest raczej dowodem na to że w php też się da to zrobić, niż czymś co poleciłbym jako narzędzie produkcyjne. Nawet jeżeli użyłbyś node.js i którejś z implementacji websocketów skończyłoby się to podobnie, aczkolwiek pewnie przy większej liczbie połączeń. Jak coś ma przyjmować sporo requestów, lub utrzymywać stałe połączenia w dużej liczbie, to tego nie osiągniesz na jednej maszynie, bo prędzej czy później zwyczajnie padnie.

Pracuje nad projektem który stałych połączeń jak i samych requestów ma przyjmować ile się będzie dało, początkowo użycie socket.io wydawało się dziecinnie proste, i działało, ale przy sporej liczbie połączeń, po prostu jedno wątkowy node.js nie dawał rady, więc pierwszym wyzwaniem była komunikacja pomiędzy procesami. Bo przecież nawet jak stworzysz kilka procesów, to użytkownik podłączony do 1, nie będzie widział tego co się dzieje w 2 procesie. Do tego celu użyłem redisa który ma zaimplementowany pub/sub od wersji 2.0 (więc nawet jest dostępny na windowsie), do którego socket.io ma napisany adapter: http://socket.io/docs/using-multiple-nodes/ do tego powstały adaptery dla innych języków aby można było puścić emit z php, a użytkownicy podłączeni pod serwer napisany w node.js otrzymali by ten emit. Rozwiązanie sprawdza się o dziwo dobrze, aktualnie jestem na etapie tworzenie klastera redisa i testowania ów pub/suba w jego wykonaniu. Do tego, sesja użytkownika jest przechowywana w redisie jako string JSON'a, dzięki czemu mam szybki dostęp do takiej sesji na poziomie handshake websocketowego. PHP do redisa łączy się bez problemu, własny lekko zmodyfikowany handler sesji i gotowe, wspólna sesja, dla dwóch odrębnych usług.