Sieć Objective-C - najlepsze praktyki?

Question

Buduję aplikację Objective-C, która ma zarówno serwer, jak i klienta. Klient może wysyłać aktualizacje do serwera, a serwer musi mieć możliwość wysyłania aktualizacji do każdego podłączonego klienta. Zastanawiałem się, jak najlepiej wdrożyć ten system, ale proszę o sugestie.

Obecnie myślę, że gdy dostępne będą nowe aktualizacje, serwer będzie używał wątków do wysyłania aktualizacji każdemu klientowi po kolei. Jeśli klient przekroczy limit czasu, zostanie rozłączony. Mam bardzo małe doświadczenie w pracy w sieci, więc proszę o twój wgląd.

Czy uważasz, że ten system będzie działał dobrze? Jeśli tak, czy masz jakieś sugestie dotyczące wykonywania wątków? Dowolne zajęcia NS, na które możesz mnie wskazać? Musi być jakaś kolejka, której mogę użyć, tak myślę.

Jakieś inne myśli?

EDYCJA: Nie oczekuję, że liczba klientów wzrośnie powyżej 50 lub więcej, na maksa.

Answer 1

Jeśli zarówno klient, jak i serwer są aplikacjami OS X i oba mogą być napisane w Objective-C za pomocą frameworków Cocoa, bardzo polecam przyjrzeć się technologii Distributed Objects (DO) w Cocoa. Nie będę próbować pokazywać tutoriala w obiektach rozproszonych tutaj, tylko wyjaśnić, dlaczego może być użyteczny ...

DO obsługuje asynchroniczne szczegóły sieci dla ciebie (wszystkie aktualizacje klienta mogą się zdarzyć w jednym wątku). Ponadto semantyka komunikacji z odległym obiektem (od klienta do serwera lub odwrotnie, DO jest dwukierunkowa po ustanowieniu połączenia) jest bardzo podobna do komunikacji wewnątrzprocesowej. Innymi słowy, gdy masz już odniesienie do zdalnego obiektu (naprawdę NSDistantObject, który działa jako pośrednik do obiektu na drugim końcu połączenia), twój kod klienta może wysyłać wiadomości do zdalnego obiektu, tak jakby był lokalny:

[remoteServer update:client]; 

od klienta lub

[[remoteClientList objectAtIndex:i] update:server]; 

z serwera. Zostawię szczegóły konfigurowania połączenia i otrzymywania referencji remoteServer lub remoteClient po przeczytaniu Distributed Objects programming guide.

Wadą stosowania DO jest to, że jesteś przywiązany do kakao; będzie to trudne do napisania klienta lub serwera, który komunikuje się za pomocą Distirbuted Objects. Jeśli jest szansa, że ​​będziesz chciał mieć implementacje klienta lub serwera inne niż Cocoa, nie powinieneś używać DO. W tym przypadku polecam coś prostego z dużą ilością obsługi między platformami i językami. Interfejs API w stylu REST przez HTTP jest dobrym rozwiązaniem. Zajrzyj do dokumentacji Cocoa URL Loading System, aby uzyskać informacje na temat implementacji żądań HTTP i odpowiedzi. Obejrzyj przykładowy kod Apple CocoaHTTPServer lub projekt code.google.com z same name, aby uzyskać informacje na temat implementacji serwera HTTP w kodzie Cocoa.

Jako ostatnia opcja, możesz spojrzeć na Cocoa Stream Programming Guide, jeśli chcesz zaimplementować własny protokół sieciowy. Podklasy NSStream umożliwiają słuchanie w gnieździe sieciowym i obsługę asynchronicznych odczytów/zapisów do/z tego gniazda. Wiele osób używa do tego celu AsyncSocket.Łączy on (niższy poziom) CFStream i CFSocket i czyni pisanie kodu sieciowego nieco łatwiejszym.

Answer 2

Gdy serwer wysyła aktualizacje do klientów, prawdopodobnie łatwiej byłoby mieć tylko jeden wątek obsługiwać je wszystkie i po prostu używać gniazd asynchronicznych. Oczywiście zależałoby to od tego, z iloma klientami musiałbyś sobie poradzić.

Answer 3

Nie wiem, jak planujesz zaprojektować system, ale zazwyczaj serwer nie może połączyć się z klientem; klient musi zainicjować komunikację. Z niskim limitem 50 klientów, może nie być patrząc na implementację serwera WWW/klienta ...

Mówiąc w skrócie, istnieją dwa sposoby radzenia sobie z komunikacją z serwerem klienta: 1. Ankieta klienta serwer okresowo uzyskuje aktualizacje 2. Klient utrzymuje połączenie otwarte z serwerem, a serwer odpowiada dobrze znanym (jak w obu stronach rozumieją) protokole.

Answer 4

Istnieje kilka przykładów sieciowych po stronie programistów Apple. Jeden polecam, aby sprawdzić jest URLCache, które można pobrać. Cytując dokumentacji Apple na tym przykładzie:

URLCache to aplikacja iPhone próbki, które pokazuje, jak pobrać zasób od sieci, należy go przechowywać w katalogu danych aplikacji i korzystać z lokalnej kopii zasobu. URLCache pokazuje również jak zaimplementować kilka zasad buforowania:

Answer 5

Ciekawą opcją jest protokół z Jens AlfkeBLIP. To jest jak rozebrana wersja BEEP: system sieciowy zorientowany na komunikaty. Zasadniczo zapewnia abstrakcje niskiego poziomu dla dwukierunkowej rury komunikatów, dzięki czemu można skoncentrować się na warstwowaniu protokołu komunikacyjnego na wierzchu.

Ma kilku godnych naśladowców, takich jak Marcus Zarra (autor Biblii CoreData) i Gus Mueller z oprogramowania Flying Meat.