O que fazer quando a solicitação é enviada ao servidor e enquanto a resposta à conexão com a Internet é perdida?

Estou enviando uma enorme quantidade de dados para o servidor. Agora, enquanto eu enviava os dados e aguardava a resposta do servidor, de repente meu dispositivo Android perdeu a conexão com a Internet.
Então, o que eu costumava fazer é mostrar uma caixa de diálogo de alerta de conexão perdida, mas no lado do servidor os dados já foram processados e atualizados em algum lugar, por exemplo, em qualquer URL. Mas meu telefone Android não sabe disso, pois nunca obteve resposta. Como resolver isso.
Se isso poderia ser feito no lado do servidor ou no próprio Android Como?
Como servidor saberia que o telefone Android não vai ouvir a resposta?
Pode ser uma perspectiva de otimização de comunicação cliente-servidor.

— mayank_droid
fonte

De quantos dados estamos falando? Gigabytes?

— precisa saber é o seguinte

Não há 7-8 MB, mas o tempo de resposta do servidor é muito longo e a taxa de upload do telefone é de cerca de 128 KB / S. Eu não estou falando sobre o tamanho dos dados, mas o problema de conexão.

— mayank_droid

Respostas:

Esse é um problema bastante comum com transações assíncronas e se divide em várias partes.

Como os dois lados sabem que a solicitação de transação foi recebida com sucesso?
Como você reenvia uma solicitação de transação que o cliente acredita que não foi recebida corretamente?
Como o servidor detecta solicitações repetidas do cliente quando o servidor recebeu com êxito a primeira solicitação?
Como o cliente sabe de onde obter os resultados da transação?

O melhor do HTTP é que é bastante fácil resolver todos esses problemas.

Imagine uma estrutura de URL como esta:

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

Usando postagem HTTP para enviar uma solicitação ao servidor, usando um ID de solicitação de cliente exclusivo - e faça com que o servidor responda com a ID da tarefa. Da perspectiva do cliente, se essa resposta não ocorrer, a solicitação precisará ser reenviada. Do ponto de vista dos servidores, os IDs de solicitação do cliente precisam ser armazenados em cache por alguns minutos, caso o cliente envie solicitações duplicadas. Solicitações duplicadas são tratadas simplesmente retornando a mesma ID de tarefa ao cliente.

O cliente obtém os resultados da solicitação no URL de resultados. Essa chamada pode ser repetida quantas vezes for necessário para obter os resultados. Se for chamado antes que os resultados estejam disponíveis, a resposta poderá ser uma resposta SEM CONTEÚDO, para que o cliente saiba que o servidor reconhece o ID do trabalho, mas ainda não possui o conteúdo. Se o ID do trabalho não for reconhecido, NOT-FOUND é a resposta apropriada.

O resultado final é que o cliente sempre pode fazer uma ação sensata quando a rede é perdida e recuperada e, da mesma forma, o servidor sempre pode processar solicitações do cliente de maneira sensata.

— Michael Shaw
fonte

Isso, ou simplesmente fazendo uma solicitação curta solicitando um ID da transação, várias solicitações adicionando dados à transação (você pode dividir a transferência em partes menores aqui, para obter reconhecimentos parciais) e, em seguida, uma solicitação final de "confirmação". Você pode ter tempos limite diferentes para transações completamente vazias (o cliente provavelmente não recebeu o ID), transações parcialmente carregadas e resultados (se o cliente não recebeu os resultados, pode tentar novamente a solicitação de "confirmação").

— Simon Richter

Isso gerenciaria a situação em que a conexão estava sendo perdida durante a transmissão da solicitação. A pergunta feita está falando sobre a conexão perdida após o envio dos dados, mas antes do processamento da solicitação.

— Michael Shaw

Isso também é tratado. A transação "commit" é pequena e usa o ID da transação, portanto pode ser reemitida de maneira barata sem retransmitir os dados, e o servidor pode iniciar o processamento ou retornar o resultado da chamada anterior. Isso é muito semelhante ao que você está sugerindo; a diferença é que eu tenho uma solicitação separada para criar a ID da tarefa, por isso tenho um ponto de sincronização adicional, para que o cliente possa saber se a tarefa já existe sem retransmitir a solicitação completa.

— Simon Richter

Sim, isso faz sentido.

— Michael Shaw

Dessa forma, se uma transação contiver dados parciais no servidor, eu sei que existe um cliente que conhece esse ID e tenta concluir a transação, para que eu possa manter o estado parcial e me oferecer para retomar a transmissão até a metade, minimizando os requisitos de largura de banda e removendo o precisa comparar o conteúdo da solicitação para encontrar duplicatas.

— Simon Richter

Isso se enquadra no básico da comunicação de protocolo. Uma transação foi solicitada pelo cliente Android e o servidor deve realizar a transação. Se a transação depende da confirmação do cliente Android, isso é chamada de comunicação ACK / NAK.

ACK (confirmação) e NAK (confirmação negativa) são usados para informar o outro lado do resultado de uma solicitação.

O que você está perguntando é sobre um tipo de troca de handshaking entre o cliente e o servidor e pode ser realizada com uma troca básica de ACK / NAK.

Aqui está um exemplo do Android fazendo upload de um arquivo com reconhecimento bidirecional.

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

No exemplo acima, adicionei um #ididentificador exclusivo para a transação. O servidor deve receber os arquivos, criar um registro de transação e enviá-lo como resposta de volta ao Android. O Android deve seguir com um reconhecimento dessa transação (ou, alternativamente, um NAK para uma rejeição).

Aqui está um exemplo de um Android desconectado durante o aperto de mão.

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

No exemplo acima, o servidor aceitou os arquivos enviados e enviou uma #idresposta ACK de volta ao Android, mas o Android nunca responde com uma ACK. O dispositivo Android falhou ao concluir o handshake. Cabe a você decidir como o servidor deve lidar com isso. Destrua a transação, mantenha a transação e aguarde o dispositivo Android retornar mais tarde ou conclua a transação de qualquer maneira.

O servidor pode assumir que, uma vez que o dispositivo não respondeu com o ACK. Que o dispositivo Android não atualizou seu estado interno para indicar que o upload foi bem-sucedido. Eu descartaria a transação e permitiria que o dispositivo a repetisse no futuro.

— Reactgular
fonte