Apa yang harus dilakukan ketika permintaan dikirim ke server dan sambil menunggu tanggapan konektivitas internet hilang?

Saya mengirim sejumlah besar data ke server. Sekarang ketika saya telah mengirim data dan menunggu respons server, tiba-tiba perangkat android saya kehilangan koneksi internet.
Jadi yang biasa saya lakukan adalah, menampilkan dialog peringatan koneksi hilang, tetapi di sisi server data sudah diproses dan diperbarui di suatu tempat misalnya pada URL apa pun. Tapi ponsel android saya tidak mengetahui hal ini karena tidak pernah mendapat respons. Bagaimana mengatasinya.
Apakah itu bisa dilakukan di sisi server atau di Android sendiri Bagaimana?
Bagaimana server tahu bahwa ponsel android tidak akan mendengarkan responsnya?
Mungkin perspektif optimasi komunikasi klien-server.

— mayank_droid
sumber

Berapa banyak data yang kita bicarakan? Gigabytes?

— Daniel Hollinrake

Tidak banyak 7-8 MB, tetapi waktu respons server terlalu lama, dan kecepatan unggah dari ponsel sekitar 128 KB / S. Saya tidak berbicara tentang ukuran data tetapi masalah koneksi.

— mayank_droid

Jawaban:

Ini adalah masalah yang cukup umum dengan transaksi asinkron, dan terbagi dalam beberapa bagian.

Bagaimana kedua belah pihak tahu bahwa permintaan transaksi telah berhasil diterima?
Bagaimana Anda mengirim ulang permintaan transaksi yang menurut klien belum diterima dengan benar?
Bagaimana cara server mendeteksi permintaan berulang dari klien ketika server berhasil menerima permintaan pertama?
Bagaimana klien tahu dari mana mendapatkan hasil transaksi?

Hal hebat tentang HTTP adalah cukup mudahnya untuk menyelesaikan semua masalah ini.

Bayangkan struktur URL seperti ini:

POST http://my.server.com/application/engine/queue 
DAPATKAN   http://my.server.com/application/engine/result?jobid=43425

Menggunakan pos HTTP untuk mengirim permintaan ke server, menggunakan id permintaan klien yang unik - dan meminta server merespons dengan ID pekerjaan. Dari perspektif klien, jika respons ini tidak terjadi, maka permintaan harus dikirim ulang. Dari perspektif server, permintaan id klien perlu di-cache selama beberapa menit, seandainya klien mengirim permintaan yang digandakan. Permintaan duplikat ditangani hanya dengan mengembalikan ID pekerjaan yang sama ke klien.

Klien mendapatkan hasil permintaan dari URL hasil. Panggilan ini dapat diulang sesering yang diperlukan untuk mendapatkan hasil. Jika dipanggil sebelum hasilnya tersedia, maka responsnya bisa berupa respons TANPA KONTEN sehingga klien tahu bahwa server mengenali id pekerjaan tetapi belum memiliki konten. Jika id pekerjaan tidak dikenali maka NOT-FOUND adalah respons yang sesuai.

Hasil akhirnya adalah bahwa klien selalu dapat membuat tindakan yang masuk akal ketika jaringan hilang dan dipulihkan, dan juga server selalu dapat memproses permintaan dari klien secara masuk akal.

— Michael Shaw
sumber

Itu, atau hanya melakukan permintaan singkat meminta ID transaksi, kemudian beberapa permintaan menambahkan data ke transaksi (Anda dapat membagi transfer menjadi potongan-potongan kecil di sini, untuk mendapatkan pengakuan parsial), kemudian permintaan "komit" akhir. Anda kemudian dapat memiliki batas waktu berbeda untuk transaksi yang benar-benar kosong (klien kemungkinan besar tidak menerima ID), transaksi yang diunggah sebagian, dan hasil (jika klien tidak menerima hasil, itu mungkin mencoba lagi permintaan "komit").

— Simon Richter

Itu akan mengelola situasi di mana koneksi terputus saat transmisi permintaan. Pertanyaan yang ditanyakan adalah berbicara tentang koneksi yang hilang setelah data dikirim, tetapi sebelum memproses permintaan telah selesai.

— Michael Shaw

Itu juga ditangani. Transaksi "komit" kecil dan menggunakan ID transaksi, sehingga dapat diterbitkan kembali dengan murah tanpa mentransmisikan kembali data, dan server dapat mulai memproses, atau mengembalikan hasilnya dari doa sebelumnya. Ini sangat mirip dengan apa yang Anda sarankan; perbedaannya adalah bahwa saya memiliki permintaan terpisah untuk membuat ID pekerjaan, jadi saya memiliki titik sinkronisasi tambahan, sehingga klien dapat mengetahui apakah pekerjaan sudah ada tanpa mengirim ulang permintaan penuh.

— Simon Richter

ya, itu masuk akal.

— Michael Shaw

Dengan cara ini, jika suatu transaksi berisi sebagian data di server, saya tahu bahwa ada klien yang mengetahui ID ini dan mencoba menyelesaikan transaksi, sehingga saya dapat menjaga status parsial dan menawarkan untuk melanjutkan transmisi setengah, meminimalkan kebutuhan bandwidth dan menghapus perlu membandingkan konten permintaan untuk menemukan duplikat.

— Simon Richter

Ini berada di bawah dasar-dasar komunikasi protokol. Transaksi telah diminta oleh klien Android, dan Server harus melakukan transaksi. Jika transaksi tergantung pada pengakuan klien Android maka ini disebut komunikasi ACK / NAK.

ACK (pengakuan) dan NAK (negatif-pengakuan) digunakan untuk memberi tahu pihak lain hasil dari permintaan.

Apa yang Anda tanyakan adalah jenis pertukaran handshaking antara klien dan server, dan itu dapat dilakukan dengan pertukaran ACK / NAK dasar.

Berikut adalah contoh Android yang mengunggah file dengan pengakuan dua arah.

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

Dalam contoh di atas saya telah menambahkan #idpengidentifikasi unik untuk transaksi. Server harus menerima file, membuat catatan transaksi dan mengirimkannya sebagai tanggapan kembali ke Android. Android kemudian harus mengikuti dengan pengakuan transaksi itu (atau sebagai alternatif NAK untuk penolakan).

Berikut adalah contoh pemutusan Android selama jabat tangan.

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

Dalam contoh di atas Server telah menerima file yang diunggah dan mengirim #idrespons ACK kembali ke Android, tetapi Android tidak pernah merespons dengan ACK. Perangkat Android gagal menyelesaikan handshaking. Terserah Anda untuk memutuskan bagaimana Server harus menangani ini. Hancurkan transaksi, simpan transaksi dan tunggu hingga perangkat Android kembali nanti atau selesaikan transaksi.

Server dapat berasumsi bahwa karena perangkat tidak merespons dengan ACK. Bahwa perangkat Android tidak memperbarui keadaan internal untuk menunjukkan bahwa unggahan berhasil. Saya akan membuang transaksi dan memungkinkan perangkat untuk mengulanginya di masa depan.

— Reactgular
sumber