A conversa que sobrevive aos cortes

Um telemóvel perde a ligação ao servidor muito mais vezes do que se pensa: um túnel, a passagem do wifi para a rede móvel, um sinal fraco. A aplicação volta a ligar-se sozinha, em poucos segundos. Mas até 19 de maio voltava de cada corte sem o fio dos últimos minutos, porque esse fio vivia na própria ligação. Desde então, a conversa em curso pertence à pessoa, não ao cabo: uma nova ligação dentro de meia hora encontra-a intacta, histórico e interlocutor incluídos. E um erro passageiro do lado do servidor também já não a apaga.

Dez segundos de túnel

A Inês vai no comboio, a preparar o fim de semana. « Aponta que o Tiago chega sexta à noite, dorme cá em casa. » A aplicação confirma, a ficha fica criada. « E lembra-me de tirar a cama extra na quinta. » Nova confirmação, e depois uma pergunta de volta: « para uma noite ou para duas? ». O comboio entra num túnel. No topo do ecrã, o pontinho que assinala a ligação passa de verde a vermelho. Dez segundos. O comboio sai, o ponto volta a ficar verde. A Inês responde: « duas ».

Antes de 19 de maio, o que se seguia era embaraçoso. « Duas quê? » Ou pior: uma resposta que recomeçava a partir da memória longa, encontrava a ficha do Tiago e bordava à volta, sem já saber que acabava de ser feita uma pergunta. As memórias estavam todas lá. O nome do Tiago, a data, a cama extra, nada se tinha perdido. O que faltava era o minuto anterior.

Este defeito tem uma particularidade: só se vê num telemóvel em movimento. Num comboio, num elevador, ao sair de casa, a ligação parte-se a toda a hora, e é precisamente aí que apetece falar em vez de escrever.

O que um corte significa para um telemóvel

O telemóvel e o servidor falam através de um canal que fica aberto durante toda a sessão. É o que permite à voz circular nos dois sentidos sem restabelecer uma ligação a cada frase. Mas um canal aberto tem uma fragilidade: depende da rede que o sustenta, e um telemóvel muda de rede sem parar.

Passas a porta de casa: o wifi larga, a rede móvel toma o lugar, e o canal não sobrevive à mudança. Atravessas uma zona de sinal fraco: algum equipamento algures entre o telemóvel e o servidor declara o canal morto, sem que ninguém tenha decidido nada. Ficas em silêncio uns minutos: algumas redes fecham uma linha que não diz nada. Nenhum destes acontecimentos é uma avaria. É a vida normal de um aparelho que se traz no bolso.

A aplicação sabe recompor-se, e fá-lo sozinha. Quando o canal cai, tenta reabri-lo ao fim de um segundo. Se falhar, tenta de novo ao fim de dois segundos, depois quatro, depois oito, sem nunca ultrapassar um teto de quinze segundos entre duas tentativas. Entretanto, o pontinho no topo do ecrã passa a vermelho, a laranja durante uma tentativa, e volta a verde. É tudo o que se vê, e é de propósito: uma nova ligação não tem de ser um acontecimento.

Quando o canal é reaberto, o servidor começa por dizer olá: uma primeira mensagem que traz um identificador de conversa. Todo o assunto se sustenta nesse identificador. Se for novo, a conversa recomeça do zero. Se for o mesmo de antes do túnel, o fio é recuperado.

Antes: um fio preso ao cabo

Do lado do servidor, aquilo que recebe as tuas frases, põe o modelo a trabalhar, executa as suas ferramentas e te devolve a resposta é uma espécie de maestro. É ele que segura a conversa em curso: as últimas trocas, numa janela deslizante que cobre folgadamente algumas dezenas de turnos; a pessoa declarada como quem tem o telemóvel na mão, quando não és tu que falas; e a lista das fichas criadas desde o início da conversa, aquelas que um toque por baixo da resposta reabre.

Até 19 de maio, era construído um maestro para cada canal. Um canal, um maestro, uma conversa. Enquanto o canal vivia, tudo corria bem. Mas cada túnel fabricava um canal novo, portanto um maestro novo, portanto uma conversa vazia. O servidor via chegar um identificador desconhecido e fazia o que faz com um desconhecido: partia do nada, só com a memória longa.

Havia pior. O fecho do canal era tomado como o fim da conversa: nesse instante, ela era resumida, arquivada na memória longa e retirada da memória viva. O túnel da Inês não se limitava a apagar a pergunta sobre a cama extra, encerrava a conversa, como se ela se tivesse despedido.

Daí os sintomas. Um « sim » lançado depois de um corte recebia « sim a quê? ». Um pedido formulado em dois tempos, a primeira metade antes do túnel e a segunda depois, já não tinha primeira metade. E um telemóvel emprestado voltava a ser, sem avisar, o telemóvel do dono, com o risco de arrumar sob o nome errado o que a pessoa de passagem acabava de dizer.

Desde então: o fio pertence à pessoa

A correção de 19 de maio é uma deslocação. Já só há um maestro para todo o servidor, e é ele que guarda todas as conversas em curso, uma por pessoa, independentemente dos canais que vão e vêm. O que dependia do canal, o ecrã para onde enviar uma ficha a mostrar, a forma de programar um lembrete para aquele telemóvel em concreto, é-lhe entregue a cada turno, em vez de ficar selado na sua construção.

Ao lado, o servidor mantém uma pequena tabela: para cada pessoa, a conversa em curso e a hora da sua última atividade. « Pessoa » tem um sentido preciso. Se tens conta, é a conta. Se usas a aplicação sem conta, é o aparelho, reconhecido pelo identificador que traz. Nos dois casos, a chave não muda quando o canal muda.

Quando um canal se abre, o servidor olha para essa tabela. Se a pessoa tinha uma conversa ativa há menos de trinta minutos, devolve-lhe o mesmo identificador, e o maestro recupera tudo: o histórico, o interlocutor declarado, as fichas da sessão. Caso contrário, cria um novo. Nos registos do servidor, isso dá uma linha por abertura: « conversa retomada, idade 9 s », ou « conversa nova ». O túnel da Inês tornou-se uma linha do primeiro tipo.

E « duas » volta a ser uma resposta. O modelo tem a pergunta diante dos olhos, sabe a que responde a palavra, ajusta o lembrete. Nada de espetacular: é exatamente o que teria acontecido sem túnel.

Porquê trinta minutos

O número não caiu do céu. É o mesmo da regra do telemóvel emprestado, aprendida nessa mesma manhã: ao fim de meia hora de silêncio, a aplicação considera que o aparelho voltou ao dono. Uma conversa obedece à mesma lógica. Trinta minutos sem uma palavra já não são um corte, são uma pausa, e uma pausa com essa duração é o sinal natural de que se passou a outra coisa.

Um pormenor conta no cálculo. A hora da última atividade é atualizada no momento em que a tua frase chega, antes de o modelo se pôr a trabalhar, não depois. Uma resposta longa, uma pesquisa na web, uma cadeia de ferramentas que leva o seu tempo, não pode portanto empurrar-te para fora da janela enquanto esperas.

O que ultrapassa os trinta minutos também não se perde. A conversa é arquivada, e é outro mecanismo que toma o lugar: as trocas passadas, lidas tal como foram e datadas, são entregues ao modelo no início da conversa seguinte. É o que responde a « do que falávamos da última vez? », e é o tema de outro artigo, do mesmo dia. Dois mecanismos, duas escalas de tempo: a sobrevivência ao corte cobre o minuto, a recordação das conversas passadas cobre os dias.

Ir-se embora não é ser cortado

É preciso distinguir duas coisas que o servidor não distinguia. Ser cortado é algo que se sofre: o túnel, o wifi que larga, a linha fechada pela rede. Ir-se embora é algo que se decide: sais da aplicação para abrir outra, ou voltas ao ecrã inicial.

Quando te vais embora a sério, a aplicação avisa o servidor de que a conversa terminou. Ela é arquivada, e a próxima abertura recomeça com uma conversa nova, com os resumos das anteriores à mão. É uma escolha: uma conversa que se deixou é uma conversa acabada, e retomá-la palavra por palavra uma hora depois seria mais desorientador do que útil.

Mas « ir-se embora a sério » é mais estreito do que parece. Abrir o teclado, puxar o painel de notificações, ver surgir uma janela do sistema: nada disso é uma partida, e a aplicação teve de aprender a deixar de os tomar como tal. Só conta a passagem completa para segundo plano. O resto, túneis incluídos, não é decisão tua, e o fio aguenta.

Um fim que já não é uma porta a fechar-se

Se o fecho do canal já não significa o fim da conversa, é preciso outro momento para a arquivar, senão aparecem dois problemas. As conversas abandonadas, aquelas em que a pessoa simplesmente pousou o telemóvel, nunca chegariam à memória longa. E a memória viva do servidor encher-se-ia de conversas que ninguém virá buscar.

O servidor percorre por isso, de cinco em cinco minutos, a sua tabela de conversas em curso. Aquelas cuja pessoa está em silêncio há mais de trinta minutos são arquivadas, como o teriam sido antigamente ao fechar do canal, e depois retiradas da memória viva. Uma conversa abandonada acaba portanto na mesma na base de dados, com um resumo, e nada se acumula. O arquivo já não acontece no segundo em que o canal cai, mas no fim da janela: para a pessoa que retoma, é precisamente o objetivo; para a que não retoma, nada muda.

O outro corte, aquele que não vem da rede

A mesma tarde reparou uma segunda família de cortes, estes invisíveis, porque acontecem entre o servidor e os serviços de que ele depende. A rede da Inês está perfeita, o ponto está verde, e mesmo assim a aplicação responde como se tivesse perdido o fio.

O primeiro caso é o do próprio modelo. Acontecia o serviço remoto devolver uma resposta vazia na primeira chamada de um turno, uma sobrecarga disfarçada de sucesso. O servidor tomava isso por uma avaria, e tu ouvias a frase de recurso, aquela que anuncia um problema técnico. Essa primeira chamada é agora repetida uma vez, depois de uma pausa curta, antes de desistir. Uma vez só, e só a primeira chamada do turno. A meio de uma cadeia de ferramentas, repetir uma chamada seria executar duas vezes o que já foi feito: duas fichas, dois lembretes. Uma resposta falhada repara-se. Uma ficha em duplicado não, não sem que alguém dê por isso.

O segundo caso é o da memória entregue ao modelo. É montada a partir de várias fontes consultadas ao mesmo tempo, e bastava uma única fonte atrasada para esvaziar o conjunto. O modelo recebia então uma memória em branco e respondia, de boa fé, que não se lembrava. A regra passou a ser « tudo o que responde fica », e o pormenor dessa mudança está contado no artigo vizinho. O que conta aqui é o parentesco: uma fonte que tosse e um túnel produzem a mesma frase na boca da aplicação, e mereciam ser tratados no mesmo dia.

Por fim, a cada turno, o servidor anota nos seus registos o que entregou realmente ao modelo: conversas recentes, memórias de cada nível, regras, e o tamanho do conjunto. Antes, « ele esqueceu-se » era um relato impossível de investigar. Agora pode dizer-se se o fio estava lá e foi mal lido, ou se estava ausente.

O que ainda não sobrevive

Esse dia fixou um enquadramento, não resolveu todos os casos, e é melhor dizer quais ficam em aberto.

Uma frase dita durante esses mesmos dez segundos não sai. Se o ponto estiver vermelho no momento em que largas o orbe, a aplicação não consegue enviar a tua frase, e repete-la quando ele voltar a estar verde. O fio está intacto, mas esse turno é para refazer. Guardar essas frases para as enviar quando a rede voltar é um trabalho à parte.

Um reinício do servidor leva consigo as conversas ainda não arquivadas, uma vez que vivem na memória viva entre dois arquivos. Escrever cada turno na base de dados à medida que acontece, para que um reinício custe no máximo uma frase, é a continuação lógica, e espera que esta dê provas.

Para lá de trinta minutos, é uma conversa nova, e é de propósito. E a própria resposta precisa da rede: perceber a tua voz, pensar, responder-te em voz alta, tudo isso acontece no servidor. O que sobrevive ao corte é o fio. Não a possibilidade de falar dentro do túnel.

Para a Inês, o dia resume-se de forma simples. Pode manter uma conversa num comboio, e o comboio tem o direito de entrar num túnel. Quando sai, a pergunta feita antes continua feita, a pessoa que falava continua a falar, e « duas » quer dizer duas noites. É pouca coisa dito assim. Era a diferença entre uma aplicação que se usa sentado e uma aplicação que se usa a andar.