APRENDER. PRATICAR. EVOLUIR.Uma leitura não define um registo
O produtor e o consumidor precisam de concordar sobre como reconhecer uma mensagem. No laboratório original, duas mensagens têm corpos de 12 e oito bytes, cada um precedido por um comprimento de dois bytes. Uma chamada sendall entrega os 24 bytes ao socket; o consumidor pede no máximo três bytes por recv. O parser consegue reconstruir as duas mensagens. As oito leituras observadas pertencem à API da aplicação. Não foram capturados pacotes, pelo que não representam oito segmentos TCP demonstrados. Esta distinção evita corrigir o tamanho dos pacotes quando o erro está no parser.
Acumular, extrair e conservar o resto
O parser mantém um buffer de bytes ainda não consumidos. Só interpreta o comprimento quando tem o cabeçalho completo; só emite uma mensagem quando também tem o corpo completo. Depois remove exatamente esses bytes e volta a verificar se existe outra mensagem. Num feed fictício de posições, isso permite receber metade de um cabeçalho ou várias mensagens próximas sem perder alinhamento. O runner verifica ainda os 25 pontos possíveis de uma divisão dos mesmos 24 bytes em duas partes. São verificações do parser, adicionais às leituras reais, e não uma simulação exaustiva da rede.
Fim de fluxo com trabalho incompleto
Noutro ensaio, o cabeçalho anuncia dez bytes, mas o produtor envia apenas abc e termina a direção de escrita. O consumidor recebe EOF com sete bytes do corpo em falta. O parser rejeita essa conclusão como mensagem incompleta. A camada de transporte pode terminar de forma ordenada sem satisfazer o contrato da aplicação. No handover, comunica comprimento esperado, bytes recebidos, identidade do fluxo e ausência de mensagem completa. Não ajustes o comprimento ao resultado recebido. Também não suponhas que uma nova ligação continuará automaticamente o fluxo anterior: essa recuperação precisa de um contrato próprio.
Terminar o pedido sem perder a resposta
Um protocolo pode usar o fim da direção de pedido como delimitador. O cliente do ensaio envia REPORT END e chama shutdown(SHUT_WR). O servidor lê até EOF e só depois envia REPORT RECEIVED; o cliente ainda recebe essa resposta. Fechar a escrita e libertar o socket inteiro são operações diferentes. Para uma integração real, confirma que o protocolo prevê este comportamento e define framing e prazo da resposta. A mensagem sintética demonstra a direção que permaneceu aberta, mas não representa aceitação de um relatório financeiro, persistência ou autorização de negócio.
O retorno do envio é uma etapa
O ensaio sequencial também chama sendall antes de qualquer leitura no servidor. O envio termina e, nesse instante, o contador de leituras da aplicação remota ainda é zero. O runner lê depois os 19 bytes sintéticos. Essa ordem é suficiente para mostrar que retorno do envio não implica consumo funcional. Não houve captura de ACKs nem base de dados. Quando uma API de envio lança uma exceção, não inventes um offset seguro para repetir parte do pedido. Guarda a identidade da operação e usa o mecanismo de reconciliação definido para resultados incertos.
Aceitar a correção de um feed
No caso fictício de posições, introduzir um delay entre mensagens pode esconder um parser incorreto. A aceitação deve variar as divisões dos bytes, incluir mensagens consecutivas, EOF a meio e comprimentos fora do limite acordado. O laboratório executado cobre leituras pequenas, divisões em duas partes e um corpo interrompido; não mede carga nem executa todos os casos de fronteira propostos. Define também o prazo total para completar uma mensagem e a ação quando esse prazo termina. Reconciliar registos afetados pela release faz parte da recuperação, juntamente com a correção técnica e a evidência para RUN.
Uma escrita de 24 bytes produziu oito leituras de três bytes e duas mensagens válidas. Um segundo ensaio recebeu cinco bytes de framing, mas rejeitou o corpo incompleto anunciado como dez bytes.
Armadilhas comuns
Usar read como mensagem; interpretar EOF como conclusão funcional; chamar close quando ainda falta resposta; confundir retorno de sendall com leitura ou persistência; apresentar chunks como pacotes capturados.
Tópicos relacionados: Transporte, confirmação e mensagens · Estados, filas e controlo de fluxo · Diagnóstico no contexto da aplicação
O contrato da aplicação define a mensagem e a confirmação. Mantém estado de parsing, limites e evidência de cada etapa, mesmo quando o transporte termina sem erro explícito.
Referência: Transmission Control Protocol · DR TCP/IP 2026-09; TCP RFC 9293; IPv6 RFC 8200 with RFC 9673 update; Linux socket and iproute2 guidance