COMET (server push to client) na iPhone [zamknięty]

Czy możesz używać zwykłego gniazda TCP / IP w swojej aplikacji?

A) jeśli tak, to zdecydowanie surowe Gniazdo TCP / IP jest bardziej eleganckim rozwiązaniem. Z aplikacji na iPhone ' a po prostu czekasz na zdarzenia powiadomień. Gniazdo jest otwarte tak długo, jak długo aplikacja jest otwarta. Jeśli chcesz, możesz nawet użyć protokołu HTTP / nagłówków.

Po stronie serwera można użyć jakiegoś frameworka do pisania serwerów, które efektywnie obsługują tysiące otwartych połączeń TCP / IP. e. G Twisted, EventMachine lub libevent . Następnie wystarczy podłączyć gniazdo główne serwera do portu http (80).

Chodzi o to, aby użyć serwera, który przechowuje tylko jedną strukturę danych na klienta. Odbiera Zdarzenie update z jakiejś aplikacji DB, a następnie wypycha je do właściwego klienta.

B) nie, musisz użyć Apache i klienta http po stronie iPhone ' a. wtedy powinieneś wiedzieć, że całe rozwiązanie COMET jest w rzeczywistości obejściem ograniczeń protokołu HTTP i Apache / PHP.

Apache został zaprojektowany do obsługa wielu połączeń w krótkim czasie. O ile wiem, tylko najnowsze wersje Apache (mpm worker) potrafią efektywnie obsłużyć dużą liczbę otwartych połączeń. Wcześniej Apache przechowywał jeden proces na każde połączenie.

Przeglądarki internetowe mają limit jednoczesnych otwartych połączeń z jednym serwerem WWW (w rzeczywistości adres URL, np. www.foo.com, nie adres IP www.foo.com). a limit to 2 połączenia. Dodatkowo przeglądarka pozwoli tylko na połączenia AJAX z tym samym serwerem, z którego główny HTML strona została pobrana.

Napisałem serwer WWW do robienia dokładnie tego typu rzeczy. Przepycham aktualizacje w czasie rzeczywistym przez serwer z długim sondowaniem i jako przykład miałem safari na iPhonie wyświetlające te dane.

Dana instancja serwera powinna być w stanie obsłużyć kilka tysięcy jednoczesnych klientów bez zbytniego wysiłku. Mam plan, aby umieścić je w hierarchii, aby umożliwić bardziej poziome skalowanie (powinno być dość trywialne, ale nie wpływa na mój obecny aplikacji).

WebSync ma klienta javascript, który działa na iPhonie, jeśli o to ci chodzi

Czy long-ankietowanie zadziała na to, co chcesz osiągnąć? Możesz zaimplementować stronę Klienta w kilku liniach zwykłego Javascript, który będzie lżejszy niż jakikolwiek framework.

Byłoby również trywialne zaimplementowanie go w ObjC (connect, wait for a response or timeout, repeat)

Odpowiedzi na moje pytanie prosty przykładowy kod "długiego sondażu"? miejmy nadzieję, że wyjaśnisz, jak bardzo proste jest długie sondowanie..

W zasadzie wystarczy poprosić o adres URL jako Zwykle-serwer WWW zaakceptuje połączenie, ale nie wyśle żadnych danych, dopóki nie będzie dostępne. Po odebraniu danych lub przekroczeniu czasu połączenia, łączysz się ponownie (i powtarzasz)

Najbardziej skomplikowanym bitem byłby serwer po stronie serwera, ponieważ nie można używać zwykłego, gwintowanego serwera www, takiego jak Apache, chociaż tak jest również w przypadku Comet..

StreamHub Comet Server działa z iPhone ' em po wyjęciu z pudełka, bez żadnych wtyczek ani niczego wymaganego. Po prostu przeglądałem ich stronę na moim iPhonie i wszystkie przykłady działały, nie trzeba było instalować Flasha ani nic.

Czy chcesz / masz zrobić komunikację dla aplikacji przez http? Jeśli nie, możesz użyć frameworku CFNetwork, aby używać gniazd (TCP / UDP), aby umożliwić komunikację aplikacji i serwera. Z tego, co widziałem na stosie CFNetwork, jest całkiem fajny i sprawia, że odczyt i zapis do strumieni jest dość prosty, a także pozwala na synchroniczną i asynchroniczną komunikację. Pozwala również na zdefiniowanie wywołań zwrotnych na gnieździe, co pozwala otrzymywać powiadomienia o zdarzeniach, takich jak odebrane dane, połączenie wykonane itp. Tak więc, w twoim przykładzie można wysłać informacje przez gniazdo do serwera, a następnie można zdefiniować callback, który będzie nasłuchiwać przychodzących danych w strumieniu, a następnie odpowiednio zaktualizować aplikację.

EDIT: zrobiłem trochę więcej badań, a jeśli pójdziesz podejście socket, może chcesz również spojrzeć na klasy NSStream. Są abstrakcjami kakaowymi zbudowanymi na materiale CFSocket.

Nie wspomniałeś, jakiej technologii używasz. Ale w przypadku, gdy jest to microsoft. NET (lub dla innych googlerów, którzy się z tym zetkną), jest prosta opcja dla comet: http://www.codeplex.com/ncomet .

COMET, LightStreamer, AJAX wszystkie te śmieci są zepsute. To podstawy TCP, że żadne "utrzymanie" nie są nigdy gwarantowane bez pingowania ruchu.. Możesz więc zapomnieć o tym długim sondażu, jeśli ma być zagwarantowana przyzwoita niezawodność lub terminowa dostawa..

To tylko szum, który wszyscy widzieli w 2003 roku, kiedy zaczęła się lamerska mania..