Pytanie Jak synchronizować dane między urządzeniami w Wi-Fi


Pracuję nad aplikacją na iOS i Androida. Podstawową funkcją jest synchronizacja określonych zestawów danych na wszystkich urządzeniach w sieci Wi-Fi bez centralnego serwera. Każde urządzenie może modyfikować ten zestaw danych.

Obecne podejście polega na wykrywaniu innych urządzeń za pośrednictwem Bonjour / Zeroconf, a następnie wysyłaniu "komunikatów o zmianach" do wszystkich urządzeń za pośrednictwem ZeroMQ.

Ponieważ oba frameworki powodują wiele problemów do wdrożenia, pytam, czy jest to właściwy sposób na osiągnięcie tego.

Miałem większość logiki zaimplementowanej z Bonjour i Żądaniami HTTP wysłanymi na wszystkie urządzenia. Problem polegał po prostu na żądaniach sieciowych, które nie zostałyby odebrane nawet po trzech próbach, ponieważ sieć się nie udała. Chcę mieć jakąś rekonstrukcję stanu ogólnego lub bardziej niezawodną strukturę przesyłania wiadomości.

Czy jakiś rodzaj plotkarskiego podejścia do rozpowszechniania informacji oraz odkrywania wszystkich urządzeń będzie lepszy?


11
2017-07-29 15:37


pochodzenie


Decentralizacja zawsze będzie stanowić problem i nie można wiele z tym zrobić. Wybrałbym jedno z urządzeń w sieci i od tego momentu będzie działał jak serwer, a wszystkie inne urządzenia komunikują się tylko z jednym urządzeniem. To zdecydowanie ułatwia, ale nadal nie uważam tego za łatwe. Czy możesz pokazać nam jakiś odpowiedni kod lub wyjaśnić bardziej szczegółowo, co próbowałeś i co poszło nie tak? - Xaver Kapeller
Rozważałem zmienny serwer, ale to również powoduje pewne problemy. a) Ponieważ jest to sieć Wi-Fi ze smartfonami, rozłączenia będą się często zdarzać b) wybór serwera i sprawdzenie wszystkich urządzeń, które jest (lub jeśli już jest) jest naprawdę trudne. Będę edytować pytanie ze szczegółami. - Lukas Leitinger
Rozumiem to, ale nie można zaprzeczyć, że jest to o wiele łatwiejsze niż próba uzyskania pewnej spójności transakcyjnej w zdecentralizowanej sieci. Jeśli nie ma nikogo, kto zdecydowałby o kolejności i ważności każdej zmiany, niż napotkasz na problemy niemożliwe do rozwiązania. Tylko obraz ma dwie modyfikacje w tym samym czasie na dwóch różnych urządzeniach. Kto decyduje, czy modyfikacja jest możliwa (wyobraź sobie, że modyfikują to samo). Kto decyduje, który z nich jest przed drugim. Jeśli nie ma centralnego autorytetu do podejmowania tych decyzji, będziesz miał wiele problemów. - Xaver Kapeller
Rozumiem, co mówisz, ale w moim zestawie danych znajduje się lista pozycji, a każdy użytkownik może albo głosować na przedmiot, albo nie, więc nie ma bezpośredniego konfliktu między tymi urządzeniami. - Lukas Leitinger
Najbardziej niezawodnym sposobem jest komunikowanie się urządzeń z jednym dedykowanym urządzeniem. Jeśli coś modyfikują, serwer decyduje, czy jest to możliwe, a jeśli tak, serwer synchronizuje je z innymi urządzeniami. Jeśli serwer zniknie, wybierane jest inne urządzenie, które od niż działa jako serwer. Najtrudniejszą częścią jest oczywiście wybranie serwera i tak dalej, ale dopóki będzie to słuszne, myślę, że będzie to o wiele łatwiejsze niż w przypadku innej opcji. - Xaver Kapeller


Odpowiedzi:


Sprawne działanie oprogramowania typu klient-serwer może być dość trudne. zwłaszcza między platformami; zawsze wydaje się, że istnieje jeszcze jeden przypadek, który musi zostać rozwiązany. Zamiast odbudowywać koło, polecam korzystanie z istniejącej biblioteki, w której ktoś już wypracował wszystkie supełki. Nie używałem go do niczego poza prototypem, ale AllJoyn projekt open-source wygląda bardzo obiecująco. Inną opcją jest Interfejsy API Google w pobliżu, które w tej chwili są tylko dla Androida i iOS.


1
2017-08-06 03:25



Kilka osób proponowało AllJoyn, wygląda całkiem obiecująco, na pewno to sprawdzę! - Lukas Leitinger
Nie znaleziono strony wyjątek :( - Ranjith Kumar
Zaktualizowałem link i dodałem odnośnik / link do Google w pobliżu. - scottt


Proste schematy nie pasują do wszystkich wymagań od razu po wyjęciu z pudełka.

Ani ad-hoc - asymetria roli stania się Serwerem na żądanie, aby decydować o zmianie, jak w "Ankieta (wszystkie głosy)" (Ryc. -S dzięki uprzejmości nanomsg.org )

Survey / Vote Pattern

lub symetria roli koalicji węzłów w "Wzór szyny" Bus / Routing Pattern spełnia wszystkie wymagania per se.


"Faza" ciągłego odkrywania

jest zadaniem, które ma działać jako ciągła samoidentyfikacja, aby uzyskać Koalicję-węzłów, odpowiedni zestaw informacji, dla których należy poczekać podczas głosowania, a dla kogo nie. Odwrotnie, kiedy można nadawać <aListITEM> zmienić i oczekiwać, że głosowanie poprze jego sąsiedztwo "Koalicja-węzłów".

Książka o ponad 400 stronach Pietera Hintjena Przewodnik ZeroMQ - dla programistów Pythona, Rozdział 8.3 dadzą ci wstępne spostrzeżenia na temat autonomicznego odkrywania prewencyjnego i / lub współpracy oraz kilka uwag na temat Wi-Fi w poprzednich rozdziałach. Zwróć też uwagę na końcowe uwagi na temat niepewności ISO-OSI-L2 / L3 w >>> Ograniczenia wykrywania w oparciu o ARP oparte na WiFi SSID L3


Metody dla <aListITEM> zmienić propagację w bieżącej koalicji węzłów

to po prostu kolejny pod-protokół (warstwa) do wdrożenia w ramach koalicji węzłów.

sub-protocol

Czy autobus lub jakiś hybrydowy, skalowalny formalny wzorzec komunikacji z głosowaniem "ankietowym" spełnia wszystkie wymagania?

Może tak może nie.

Pierwszy lista wszystkie wymagania, aby móc zaprojektować "przeciw" takiemu obowiązkowemu zestawowi cech.

Druga, uprawomocnić, że zestaw cech jest uzasadniony i wykonalny dla każdego węzła, który dynamicznie stanie się / przestanie być członkiem Koalicji-Nodów.

Trzeci, projekt nieblokująca, samodoskonaląca się społeczność - a wyższego rzędu - FSA-of-FSAs - przy odpowiednim uzgadnianiu, ponownej synchronizacji / watchdog / timeout (ach) i propagacji <aListITEM> aktualizacje i mechanizmy głosowania, tak aby spełniały one obowiązkowe zestaw funkcji projektu.

Nie polegaj na gotowych prymitywach (za cenę "gięcia" obowiązkowego zestawu funkcji projektowych w celu spełnienia dostępnego dla biblioteki prymitywu, ale raczej rozwijaj inną, nowy, wyższego rzędu Formalne sygnalizowanie wzorców komunikacyjnych, będąc zmontowanym z prymitywów bibliotecznych, tak aby spełniał on cały specyfikacja. )


6
2017-08-02 23:11



Dziękuję za wyczerpującą odpowiedź, ale myślę, że najlepszą drogą jest AllJoyn. Jeśli uda mi się go uruchomić, jestem przekonany, że o wiele mniej jest wymyślanie na nowo, jak pisanie własnego protokołu (niezależnie od warstwy). - Lukas Leitinger


Nie wiem o szczegółach twojego problemu, ale:

  • jeśli nie masz DUŻO danych
  • jeśli twoje aktualizacje nie są zbyt częste (> 1 req / s)

mógł transmisja UDP wiadomość działa?

Jeśli zapytasz sieć i uzyskasz adres rozgłoszeniowy, może to być łatwy sposób dystrybucji / zapytania o informacje bez potrzeby wysyłania ich do każdego urządzenia osobno. Oczywiście, UDP nie jest wiarygodny, więc trzeba by zaimplementować pewien rodzaj mechanizmu "zapytań", w którym urządzenie prosi o aktualizacje po ponownym nawiązaniu połączenia z siecią.

Jedyną inną, bardziej niezawodną opcją, o której mógłbym pomyśleć, byłoby użycie powiadomień push platformy. W takim przypadku Apple / Google upewni się, że twoje wiadomości zostaną dostarczone, Twoim jedynym zadaniem jest utrzymywanie listy urządzeń w "grupie" (np. W tym samym wifi). Ale to rozwiązanie ponownie zawiera serwer centralny, a nawet więcej, dostęp do Internetu.


2
2017-08-01 12:48



Nie mam zbyt dużo danych (tylko tekst), ale prośby zdarzają się dość szybko, a każde urządzenie może samo wysłać więcej niż 1kw / s. Wciąż będę się nad tym zastanawiać. - Lukas Leitinger