Polling, Comet, WebSockets, itp.

Question

Potrzebuję zbudować całkiem agresywne możliwości "automatycznego odświeżania" w aplikacji internetowej. Jest to rodzaj galerii zdjęć, a obrazy są przechowywane na AmazonS3, ale dane o obrazach są przechowywane w naszej własnej bazie danych. Grałem z odpytywaniem serwera i wysyłaniem wywołań ajaxowych, aby uzyskać zaktualizowane dane. Naprawdę martwię się obciążeniem serwera (s) tą metodą. Czasami strona powinna być aktualizowana co 15 do 30 sekund.

Czytałem na komecie i po prostu nie sprzedałem, że ten "hack" to świetny pomysł. WebSockets prawdopodobnie pomoże, ale obawiam się, że są po prostu zbyt nowe i zbyt nieobsługiwane. Czy w związku z tym, czy ktoś ma jakieś zalecenia dotyczące sposobów zaprojektowania systemu, który musi odświeżać się często i ma potencjał dla bardzo wysokiej bazy użytkowników?

Nie mam zamiaru rzucić więcej serwerów na problem, ale nie jestem przekonany, że to najlepsze podejście. I zanim ktokolwiek inny to zasugeruje, nie mogę zrobić Flexa, ponieważ aplikacja internetowa musi działać na iPadzie.

Answer 1

WebSockets wydaje się dość dobrym wyborem. Wyłączenie WebSockets w Firefoksie 4 i Operze 11 jest prawdopodobnie tymczasowe, ponieważ grupa robocza rozpoczęła wydawanie wersji roboczych rozwiązujących problemy. Ponadto funkcja cofania błysku w trybie web-socket-js nadal będzie działać nawet w przeglądarkach, w których wyłączono natywne WebSockets. Warto również zauważyć, że iOS 4.2 ma natywne WebSockets. Tak więc z natywnym zabezpieczeniem WebSockets +, WebSockets jest obsługiwany niemal wszędzie.

Jeśli korzystasz z WebSockets, możesz również rozważyć przesuwanie aktualizacji zamiast ankietowania klientów. Pomoże to zapobiec przypadkowemu DDOS serwerowi. Opóźnienie po prostu pójdzie w górę dla klientów iw tym momencie możesz zacząć dodawać więcej zasobów po stronie serwera.

Jeśli nie ma mowy o JavaScript po stronie serwera, możesz sprawdzić, czy nie jest dostępny Socket.IO, który jest strukturą Nodejs WebSockets, która wybiera najlepszy transport obsługiwany zarówno przez klienta, jak i serwer (preferując macierzysty WebSockets, a następnie zastępcze WebSockets, następnie różne opcje długoterminowego odpytywania). Umożliwia także bardzo podobny wygląd kodu serwera i klienta, ponieważ zawiera bibliotekę po stronie klienta. Wydaje się, że Socket.IO ma w tej chwili sporo umysłu.

Jeśli jesteś Ruby centric, prawdopodobnie chcesz sprawdzić em-websockets. Zarówno Socket.IO, jak i em-websockets są serwerami opartymi na zdarzeniach, które pozwalają na bardzo wysoką liczbę klientów, szczególnie, gdy najważniejsze jest opóźnienie, a nie przepustowość.

Answer 2

Grupa WS-I opublikowała coś o nazwie "Reliable Secure Profile", która ma szklaną rybę i .NET implementation, która podobno ma dobrze inter-operate.

Przy odrobinie szczęścia istnieje również implementacja Javascript.

Istnieje również implementacja Silverlight, która używa HTTP Duplex. Możesz uzyskać obiekt connect javascript to the Silverlight, aby uzyskać wywołania zwrotne po naciśnięciu.

Dostępne są również commercial paid versions.