Sunucuya istek gönderildiğinde ve yanıt beklenirken internet bağlantısı kesildiğinde ne yapmalı?

Sunucuya çok miktarda veri gönderiyorum. Şimdi veri gönderirken ve sunucu yanıtını beklerken aniden android cihazım internet bağlantısı kesildi.
Eskiden yaptığım şey, kayıp bağlantıyla ilgili bir uyarı iletişim kutusu göstermektir, ancak sunucu tarafında veriler zaten işlenmiş ve herhangi bir URL'de bir yerde güncellenmiştir. Ama android telefonum bunu hiç bilmediği için bilmiyor. Nasıl çözülür.
Sunucu tarafında mı yoksa android'in kendisinde mi yapılabilir?
Nasıl android android telefon yanıtı dinlemek olmaz biliyor?
İstemci-sunucu iletişim optimizasyonu perspektifi olabilir.

— mayank_droid
kaynak

Ne kadar veri hakkında konuşuyoruz? Gigabaytlar?

— Daniel Hollinrake

Yaklaşık 7-8 MB civarında değil, ancak sunucu yanıt süresi çok uzun ve telefondan yükleme hızı 128 KB / S civarında. Veri boyutu hakkında değil bağlantı probleminden bahsediyorum.

— mayank_droid

Yanıtlar:

Bu, zaman uyumsuz işlemlerde oldukça yaygın bir sorundur ve birkaç parçaya ayrılır.

Her iki taraf da işlem talebinin başarıyla alındığını nasıl biliyor?
Müşterinin düzgün şekilde alınmadığına inandığı bir işlem talebini nasıl yeniden gönderirsiniz?
Sunucu ilk isteği başarıyla aldığında sunucu istemciden gelen tekrar isteklerini nasıl algılar?
Müşteri işlem sonuçlarını nereden alacağını nasıl biliyor?

HTTP ile ilgili en güzel şey, tüm bu sorunları çözmenin oldukça kolay olmasıdır.

Bunun gibi bir URL yapısı düşünün:

POST http://my.server.com/application/engine/queue 
GET   http://my.server.com/application/engine/results?jobid=43425

Benzersiz bir istemci isteği kimliği kullanarak sunucuya istek göndermek için HTTP postasını kullanma ve sunucunun iş kimliğiyle yanıt vermesini sağlama. İstemciler açısından bakıldığında, bu yanıt gerçekleşmezse, isteğin yeniden gönderilmesi gerekir. Bir sunucu perspektifinden, istemcinin yinelenen istekler göndermesi durumunda, istemci istek kimliğinin birkaç dakika önbelleğe alınması gerekir. Çoğaltılan istekler, yalnızca aynı iş kimliği istemciye döndürülerek işlenir.

İstemci, isteğin sonuçlarını sonuç URL'sinden alır. Bu çağrı, sonuçları almak için gerektiği kadar tekrarlanabilir. Sonuçlar kullanılabilir duruma gelmeden çağrılırsa, yanıt sunucunun iş kimliğini tanıdığını ancak henüz içeriğe sahip olmadığını bilmesi için yanıt NO-CONTENT yanıtı olabilir. İş kimliği tanınmazsa, uygun yanıt NOT-FOUND olur.

Nihai sonuç, ağ kaybedildiğinde ve kurtarıldığında istemcinin her zaman mantıklı bir işlem yapabilmesi ve aynı şekilde sunucunun istemciden gelen istekleri her zaman mantıklı bir şekilde işleyebilmesidir.

— Michael Shaw
kaynak

Bu, ya da sadece bir işlem kimliği isteyen kısa bir talepte bulunarak, işleme ilişkin veri ekleyen birkaç talep (kısmi teşekkür almak için aktarımı burada daha küçük parçalara bölebilirsiniz), ardından son bir "taahhüt" talebi. Daha sonra tamamen boş işlemler (istemci büyük olasılıkla kimlik almadı), kısmen yüklenmiş işlemler ve sonuçlar için farklı zaman aşımlarına sahip olabilirsiniz (müşteri sonuçları almadıysa, "kesinleştirme" isteğini yeniden deneyebilir).

— Simon Richter

Bu, talebin iletilmesi sırasında bağlantının kesildiği durumu yönetecektir. Sorulduğu gibi, veri gönderildikten sonra, ancak istek işlenmeden önce bağlantı kesilmesinden bahsediliyor.

— Michael Shaw

Bu da ele alınır. "Taahhüt" işlemi küçüktür ve işlem kimliğini kullanır, bu nedenle verileri yeniden iletmeden ucuza yeniden gönderilebilir ve sunucu işlemeye başlayabilir veya önceki çağrıdan sonucu döndürebilir. Bu, önerdiklerinize çok benzer; fark iş kimliği oluşturmak için ayrı bir istek var, bu yüzden ek bir eşitleme noktası var, böylece istemci tam isteği yeniden iletmeden iş zaten var olup olmadığını bilmek.

— Simon Richter

evet, bu mantıklı.

— Michael Shaw

Bu şekilde, bir işlem sunucuda kısmi veriler içeriyorsa, bu kimliği bilen ve işlemi tamamlamaya çalışan bir istemci olduğunu biliyorum, böylece kısmi durumu koruyabilir ve iletimin yarıya kadar devam etmesini, bant genişliği gereksinimlerini en aza indirmeyi ve yinelenenleri bulmak için istek içeriğini karşılaştırmanız gerekir.

— Simon Richter

Bu protokol iletişiminin temelleri altındadır. Android istemcisi tarafından bir işlem istendi ve Sunucunun işlemi gerçekleştirmesi gerekiyor. İşlem Android istemcisinin onayına bağlıysa, ACK / NAK iletişimini arayın.

ACK (onay) ve NAK (olumsuz onay) karşı tarafa bir isteğin sonucunu bildirmek için kullanılır.

Sorduğunuz şey, istemci ve sunucu arasında bir tür el sıkışma alışverişidir ve temel bir ACK / NAK değişimi ile gerçekleştirilebilir.

Aşağıda, iki yönlü onay içeren bir dosyayı karşıya yükleyen Android örneği verilmiştir.

Android -> upload files -> Server
Android <- ACK #id <- Server
Android -> ACK #id -> Server

Yukarıdaki örnekte #id, işlem için benzersiz bir tanımlayıcı ekledim . Sunucu dosyaları almalı, bir işlem kaydı oluşturmalı ve bunu Android'e yanıt olarak göndermelidir. Android daha sonra söz konusu işlemin onayını (veya alternatif olarak ret için bir NAK) izlemelidir.

İşte el sıkışma sırasında Android'in bağlantısını kesmeye bir örnek.

Android -> upload files -> Server
Android <- ACK #id <- Server
/** no ACK response **/

Yukarıdaki örnekte Sunucu, yüklenen dosyaları kabul etti ve #idAndroid'e bir ACK yanıtı gönderdi , ancak Android hiçbir zaman bir ACK ile yanıt vermiyor. Android cihaz el sıkışmasını tamamlayamadı. Sunucunun bunu nasıl ele alacağına karar vermek size kalmış. İşlemi yok edin, işlemi koruyun ve Android cihazının daha sonra geri dönmesini veya işlemi yine de tamamlamasını bekleyin.

Sunucu, cihaz ACK ile yanıt vermediği için bunu kabul edebilir. Android cihazının, yüklemenin başarılı olduğunu belirtmek için dahili durumunu güncellememesi. İşlemi iptal eder ve cihazın ileride tekrarlamasına izin veririm.

— Reactgular
kaynak