APRENDER. PRATICAR. EVOLUIR.Nomear a fase que expirou
O cliente do laboratório liga ao servidor, envia STATUS 42 e o servidor lê o pedido. Só depois o cliente espera por uma resposta com um timeout de 150 ms. Como o runner ainda não envia resposta, recv lança TimeoutError. A ligação já estava estabelecida e a aplicação do servidor tinha lido o pedido. Classificar este resultado como falha de DNS ou handshake perde informação essencial. Num incidente, regista a chamada que falhou, o valor configurado, o tempo observado, origem e destino e a identidade funcional. Uma mensagem genérica network timeout não é uma causa raiz.
Uma resposta pode chegar depois
Após observar o timeout, o runner envia READY 42 e o cliente recebe no mesmo socket, sem reconnect. A experiência demonstra uma sequência controlada, não uma garantia sobre qualquer biblioteca ou serviço. Algumas aplicações fecham o recurso ou cancelam tarefas por política própria. A equipa deve distinguir o prazo local, a eventual propagação de cancelamento e o resultado remoto. Os 150 ms também não são o RTO do TCP: o limite da API e o temporizador de retransmissão são mecanismos diferentes. Este ensaio não captura retransmissões nem mede o algoritmo de RTO do sistema.
Recusa explícita com contexto delimitado
Para observar uma recusa, o runner reserva uma porta local, fecha esse socket e tenta ligar ao endereço acabado de libertar. A execução devolveu ECONNREFUSED. O código valida o resultado em vez de o pressupor, porque a porta deixa de estar reservada nesse intervalo. Não houve captura para atribuir pacotes a componentes externos. Em produção, a mesma classificação de erro exige endereço, porta, origem, momento e observações autorizadas do percurso. Um listener ausente, uma política de rejeição e o contexto errado não se distinguem apenas pela palavra refused mostrada ao utilizador.
A cauda de um datagrama não fica pendente
O emissor envia o datagrama abcdefghij e, a seguir, NEXT. O recetor chama recvmsg com espaço para quatro bytes e recebe abcd com MSG_TRUNC. A leitura seguinte entrega NEXT, não efghij. A aplicação deve observar a truncatura e aplicar o contrato para eventos incompletos. Num collector fictício, guardar o prefixo como evento válido pode produzir métricas incorretas. Alinha o limite do emissor, o tamanho admitido pelo protocolo e a capacidade de receção. Aumentar o próximo buffer não recupera a cauda já descartada, e concatenar datagramas com identidades diferentes corrompe o significado.
Vazio depende do tipo de socket
Outra experiência envia um datagrama UDP de comprimento zero, seguido de AFTER EMPTY. recvfrom devolve bytes vazios com o endereço do emissor e depois recebe o datagrama seguinte. Isso não é o EOF de um fluxo TCP. A aplicação pode rejeitar mensagens vazias, mas deve fazê-lo por uma regra do protocolo, sem inventar um encerramento de ligação. O ensaio é local e não mede entrega UDP numa WAN, perda, ordem ou fragmentação IP. Para um protocolo real, revê tamanho, identidade e recuperação perante perda sem assumir as garantias de um transporte diferente.
Entregar a RUN uma decisão reproduzível
Para o caso fictício de liquidação, comunica que a leitura expirou e que o resultado remoto ainda precisa de consulta. Mantém a identidade original ao aplicar o contrato de deduplicação; uma nova identidade pode representar outra intenção. O pacote de evidência inclui fase, cronologia, erro, versão e critério funcional de sucesso. O runtime executado foi Python 3.13.1 em macOS; a documentação consultada da linha 3.13 apresenta 3.13.16. As oito experiências usam IPv4 em loopback, sem TLS, DNS, captura ou efeitos financeiros. A aceitação do ambiente alvo continua a exigir o seu percurso e dependências reais.
O timeout ocorreu após o servidor ler STATUS 42. A resposta READY 42 chegou depois no mesmo socket. Noutro ensaio, MSG_TRUNC identificou uma cauda descartada e a leitura seguinte trouxe outro datagrama.
Armadilhas comuns
Chamar handshake a um timeout de leitura; inferir RTO da API; presumir cancelamento remoto; concatenar datagramas; tratar UDP vazio como EOF; extrapolar loopback para disponibilidade internacional.
Tópicos relacionados: Transporte, confirmação e mensagens · Estados, filas e controlo de fluxo · Diagnóstico no contexto da aplicação
Localiza a espera e o contrato antes de repetir. O erro técnico orienta a investigação; a identidade e o estado funcional orientam a recuperação sem efeitos duplicados.
Referência: Python socket interface · DR TCP/IP 2026-09; TCP RFC 9293; IPv6 RFC 8200 with RFC 9673 update; Linux socket and iproute2 guidance