Phải làm gì khi yêu cầu được gửi đến máy chủ và trong khi chờ phản hồi kết nối internet bị mất?

Tôi đang gửi một lượng lớn dữ liệu đến máy chủ. Bây giờ trong khi tôi đã gửi dữ liệu và chờ phản hồi của máy chủ, đột nhiên thiết bị Android của tôi bị mất kết nối internet.
Vì vậy, những gì tôi thường làm là hiển thị hộp thoại cảnh báo mất kết nối, nhưng ở phía máy chủ, dữ liệu đã được xử lý và nó được cập nhật ở đâu đó, ví dụ như trên bất kỳ URL nào. Nhưng điện thoại Android của tôi không biết điều này vì nó không nhận được phản hồi bao giờ. Làm thế nào để giải quyết nó.
Liệu nó có thể được thực hiện ở phía máy chủ hay trên chính Android?
Làm thế nào máy chủ biết rằng điện thoại Android sẽ không lắng nghe phản hồi?
Nó có thể là quan điểm tối ưu hóa giao tiếp máy khách-máy chủ.

— mayank_droid
nguồn

Chúng ta đang nói về bao nhiêu dữ liệu? Gigabyte?

— Daniel Hollinrake

Không có nhiều 7-8 MB xung quanh, nhưng thời gian phản hồi của máy chủ quá dài và tốc độ tải lên từ điện thoại là khoảng 128 KB / S. Tôi không nói về kích thước dữ liệu nhưng vấn đề kết nối.

— mayank_droid

Câu trả lời:

Đây là một vấn đề khá phổ biến với các giao dịch không đồng bộ và rơi vào một số phần.

Làm thế nào để cả hai bên biết rằng yêu cầu giao dịch đã được nhận thành công?
Làm thế nào để bạn gửi lại một yêu cầu giao dịch mà khách hàng tin rằng chưa được nhận đúng?
Làm thế nào để máy chủ phát hiện các yêu cầu lặp lại từ máy khách khi máy chủ nhận thành công yêu cầu đầu tiên?
Làm thế nào để khách hàng biết nơi nhận được kết quả giao dịch?

Điều tuyệt vời về HTTP là nó khá dễ dàng để giải quyết tất cả các vấn đề này.

Hãy tưởng tượng một cấu trúc URL như thế này:

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

Sử dụng bài đăng HTTP để gửi yêu cầu đến máy chủ, sử dụng id yêu cầu khách hàng duy nhất - và để máy chủ phản hồi với ID công việc. Từ góc độ khách hàng, nếu phản hồi này không xảy ra, thì yêu cầu cần phải được gửi lại. Từ quan điểm của máy chủ, id yêu cầu của máy khách cần được lưu trong vài phút, trong trường hợp máy khách gửi các yêu cầu trùng lặp. Yêu cầu trùng lặp được xử lý đơn giản bằng cách trả lại cùng ID công việc cho khách hàng.

Khách hàng nhận được kết quả của yêu cầu từ URL kết quả. Cuộc gọi này có thể được lặp lại thường xuyên khi cần thiết để có được kết quả. Nếu nó được gọi trước khi có kết quả, thì phản hồi có thể là phản hồi KHÔNG NỘI DUNG để khách hàng biết rằng máy chủ nhận ra id công việc nhưng chưa có nội dung. Nếu id công việc không được công nhận thì KHÔNG-FOUND là phản hồi thích hợp.

Kết quả cuối cùng là máy khách luôn có thể thực hiện hành động hợp lý khi mạng bị mất và được phục hồi, và tương tự, máy chủ luôn có thể xử lý các yêu cầu từ máy khách một cách hợp lý

— Michael Shaw
nguồn

Điều đó, hoặc đơn giản là thực hiện một yêu cầu ngắn yêu cầu ID giao dịch, sau đó một số yêu cầu thêm dữ liệu vào giao dịch (bạn có thể chia chuyển khoản thành các phần nhỏ hơn ở đây, để nhận được một phần xác nhận), sau đó là yêu cầu "cam kết" cuối cùng. Sau đó, bạn có thể có thời gian chờ khác nhau cho các giao dịch hoàn toàn trống (rất có thể khách hàng không nhận được ID), giao dịch được tải lên một phần và kết quả (nếu khách hàng không nhận được kết quả, có thể thử lại yêu cầu "cam kết").

— Simon Richter

Điều đó sẽ quản lý tình huống mất kết nối trong quá trình truyền yêu cầu. Câu hỏi khi được hỏi là nói về việc mất kết nối sau khi dữ liệu được gửi, nhưng trước khi xử lý yêu cầu đã hoàn tất.

— Michael Shaw

Điều đó cũng được xử lý. Giao dịch "cam kết" nhỏ và sử dụng ID giao dịch, do đó, nó có thể được phát hành lại với giá rẻ mà không cần truyền lại dữ liệu và máy chủ có thể bắt đầu xử lý hoặc trả về kết quả từ lệnh gọi trước đó. Điều này rất giống với những gì bạn đang đề xuất; sự khác biệt là tôi có một yêu cầu riêng để tạo ID công việc, vì vậy tôi có một điểm đồng bộ hóa bổ sung, vì vậy khách hàng có thể biết liệu công việc đã tồn tại mà không truyền lại yêu cầu đầy đủ hay chưa.

— Simon Richter

Vâng, điều đó có ý nghĩa.

— Michael Shaw

Bằng cách này, nếu giao dịch chứa dữ liệu một phần trên máy chủ, tôi biết rằng khách hàng tồn tại biết ID này và cố gắng hoàn thành giao dịch, vì vậy tôi có thể giữ trạng thái một phần và đề nghị tiếp tục truyền nửa chừng, giảm thiểu yêu cầu băng thông và loại bỏ yêu cầu băng thông cần so sánh nội dung yêu cầu để tìm bản sao.

— Simon Richter

Điều này rơi vào những điều cơ bản của giao tiếp giao thức. Một giao dịch đã được yêu cầu bởi ứng dụng khách Android và Máy chủ phải thực hiện giao dịch. Nếu giao dịch phụ thuộc vào xác nhận của máy khách Android thì đây là cuộc gọi liên lạc ACK / NAK.

ACK (xác nhận) và NAK (xác nhận phủ định) được sử dụng để báo cho phía bên kia kết quả của yêu cầu.

Những gì bạn đang hỏi là một loại trao đổi bắt tay giữa máy khách và máy chủ, và nó có thể được thực hiện với một trao đổi ACK / NAK cơ bản.

Dưới đây là một ví dụ về việc Android tải lên một tệp với xác nhận hai chiều.

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

Trong ví dụ trên tôi đã thêm một #idmã định danh duy nhất cho giao dịch. Máy chủ sẽ nhận các tệp, tạo một bản ghi giao dịch và gửi nó dưới dạng phản hồi lại cho Android. Android sau đó nên tuân theo xác nhận về giao dịch đó (hoặc thay vào đó là NAK để từ chối).

Dưới đây là một ví dụ về việc ngắt kết nối Android trong quá trình bắt tay.

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

Trong ví dụ trên, Máy chủ đã chấp nhận các tệp đã tải lên và gửi #id phản hồi ACK trở lại Android, nhưng Android không bao giờ phản hồi bằng ACK. Thiết bị Android đã không hoàn thành việc bắt tay. Tùy bạn quyết định cách Máy chủ xử lý việc này. Phá hủy giao dịch, giữ giao dịch và đợi thiết bị Android quay lại sau hoặc hoàn tất giao dịch.

Máy chủ có thể cho rằng vì thiết bị không phản hồi với ACK. Thiết bị Android không cập nhật trạng thái bên trong để cho biết rằng quá trình tải lên đã thành công. Tôi sẽ loại bỏ giao dịch và cho phép thiết bị lặp lại giao dịch trong tương lai.

— Phản ứng
nguồn