Wysyłam ogromną ilość danych na serwer. Teraz, gdy wysłałem dane i czekam na odpowiedź serwera, nagle moje urządzenie z Androidem traci połączenie z Internetem.
Tak więc zwykłem wyświetlać okno dialogowe z ostrzeżeniem o utracie połączenia, ale po stronie serwera dane zostały już przetworzone i zostały zaktualizowane gdzieś np. Pod dowolnym adresem URL. Ale mój telefon z Androidem tego nie wie, ponieważ nigdy nie otrzymał odpowiedzi. Jak to rozwiązać?
Czy można to zrobić po stronie serwera, czy na samym Androidzie Jak?
Skąd serwer wiedziałby, że telefon z Androidem nie będzie nasłuchiwał odpowiedzi?
Może to być perspektywa optymalizacji komunikacji klient-serwer.
server
server-side
client-side
android-development
mayank_droid
źródło
źródło
Odpowiedzi:
Jest to dość powszechny problem z transakcjami asynchronicznymi i dzieli się na kilka części.
Wspaniałą rzeczą w HTTP jest to, że dość łatwo można rozwiązać wszystkie te problemy.
Wyobraź sobie taką strukturę URL:
Użycie postu HTTP do wysłania żądania do serwera, użycie unikalnego identyfikatora żądania klienta - i serwer powinien odpowiedzieć za pomocą identyfikatora zadania. Z perspektywy klienta, jeśli ta odpowiedź nie występuje, żądanie musi zostać ponownie wysłane. Z perspektywy serwera identyfikator żądania klienta musi być buforowany przez kilka minut, na wypadek, gdyby klient wysłał zduplikowane żądania. Zduplikowane żądania są obsługiwane po prostu przez zwrócenie tego samego identyfikatora zadania klientowi.
Klient otrzymuje wyniki żądania z adresu URL wyników. To połączenie można powtarzać tak często, jak to konieczne, aby uzyskać wyniki. Jeśli zostanie wywołany, zanim wyniki będą dostępne, odpowiedź może być odpowiedzią BRAK ZAWARTOŚCI, aby klient wiedział, że serwer rozpoznaje identyfikator zadania, ale nie ma jeszcze treści. Jeśli identyfikator zadania nie zostanie rozpoznany, wówczas odpowiednią odpowiedzią jest NOT-FOUND.
Efektem końcowym jest to, że klient zawsze może podjąć rozsądne działanie, gdy sieć zostanie utracona i odzyskana, a serwer może zawsze rozsądnie przetwarzać żądania od klienta
źródło
Dotyczy to podstaw komunikacji w protokole. Klient systemu Android zażądał transakcji, a serwer musi ją wykonać. Jeśli transakcja jest zależna od potwierdzenia klienta Android, to należy zadzwonić do komunikacji ACK / NAK.
ACK (potwierdzenie) i NAK (negatywne potwierdzenie) są używane do poinformowania drugiej strony o wyniku żądania.
To, o co pytasz, to rodzaj wymiany uzgadniania między klientem a serwerem, którą można wykonać za pomocą podstawowej wymiany ACK / NAK.
Oto przykład przesyłania przez system Android pliku z dwukierunkowym potwierdzeniem.
W powyższym przykładzie dodałem
#id
unikalny identyfikator transakcji. Serwer powinien otrzymać pliki, utworzyć rekord transakcji i wysłać go jako odpowiedź z powrotem do Androida. Android powinien następnie potwierdzić tę transakcję (lub alternatywnie NAK za odrzucenie).Oto przykład odłączania się Androida podczas uzgadniania.
W powyższym przykładzie serwer zaakceptował przesłane pliki i wysłał
#id
odpowiedź ACK z powrotem do Androida, ale Android nigdy nie odpowiada ACK. Urządzenie z Androidem nie zakończyło uzgadniania. To Ty decydujesz, jak serwer powinien to obsłużyć. Zniszcz transakcję, zachowaj transakcję i poczekaj, aż urządzenie z Androidem wróci później lub mimo to sfinalizuj transakcję.Serwer może założyć, że ponieważ urządzenie nie odpowiedziało za pomocą ACK. To, że urządzenie z Androidem nie zaktualizowało stanu wewnętrznego, aby wskazać, że przesyłanie się powiodło. Odrzuciłbym transakcję i pozwoliłbym urządzeniu powtórzyć ją w przyszłości.
źródło