Resumo

  • O Discard TCP e UDP ouvia na porta 9, eliminava os dados recebidos e não emitia resposta de aplicação. No TCP, o chamador encerrava a conexão.
  • Conexão e ACKs registram responsabilidade do transporte, não uma declaração do processo Discard de que leu ou contabilizou os bytes.
  • No UDP, silêncio combina tanto com descarte correto quanto com perda, filtro ou serviço ausente. Sem testemunha no receptor, não existe evento positivo de entrega.

O ensaio que retirou o caminho de volta

O propósito era modesto. Para depurar ou medir uma direção, o receptor não precisava devolver os octetos, produzir caracteres ou informar a hora. Bastava servir de sumidouro. O RFC 863 descreveu esse serviço em maio de 1983.

Retirar a resposta também retirou a comparação. Um cliente que nada recebe não sabe, pela camada de aplicação, se o serviço cumpriu a regra. O mesmo vazio aparece quando o pacote não chega. A especificação governa o que um servidor faz depois do recebimento; não transforma todo silêncio observado pelo emissor em prova desse recebimento.

TCP mantém um rastro limitado

Na variante TCP, o servidor aceitava conexões na porta 9 e descartava tudo o que recebesse. Não respondia e prosseguia até o usuário chamador terminar a conexão. Logo, não cabia ao servidor enviar um fim de lote ou fechar como recibo.

O handshake prova que um endpoint TCP remoto aceitou aquela conexão naquele momento. ACKs, retransmissões, RST e temporizadores acrescentam informação sobre o fluxo. O RFC 9293, porém, situa o ACK: o TCP receptor confirma quando assume a responsabilidade de entregar dados ao seu usuário. Isso não certifica a execução de uma leitura específica no processo Discard.

Também não se deve superestimar o retorno local. O RFC 9293 admite interfaces em que SEND recebe confirmação local antes de o segmento ser reconhecido pelo TCP distante. Um write concluído pode significar apenas que a pilha local aceitou o buffer.

Se o objetivo é provar consumo pelo processo remoto, a arquitetura do teste precisa adicionar contador de aplicação, captura controlada ou canal auxiliar. Esse mecanismo fala em nome do experimento, não em nome de um recibo escondido no RFC 863.

UDP produz silêncio sem causa observável

No UDP, cada datagrama que alcançava a porta 9 era descartado e nenhuma resposta saía. O RFC 768 não garante entrega nem proteção contra duplicação. Assim, processamento correto, perda, bloqueio e ausência de listener terminam do mesmo modo no emissor.

Nem a falta de ICMP resolve. O RFC 8085 observa que dispositivos intermediários filtram esses erros e determina que aplicações UDP não dependam de sua entrega para operação correta e segura. Um erro validado reduz incerteza; nenhum erro não prova sucesso.

Para medir entrega, é necessário controlar a outra ponta ou um ponto independente: contar datagramas recebidos, declarar o local da captura e fechar uma janela temporal. “Enviei mil e recebi zero respostas” descreve respostas, não mil entregas.

Não é a história do laço Echo/Chargen

Echo devolve a entrada; Character Generator produz saída. Discard não devolve nada. Por isso não cria a cadeia em que uma resposta UDP, enviada a uma origem falsificada, vira a próxima solicitação. A questão aqui é a perda deliberada de evidência aplicativa.

Um sumidouro ainda pode consumir banda, buffers e estado. As fontes não trazem censo atual, taxa de abuso ou fator universal, portanto o texto não inventa esses números. O controle relevante é autorização da carga, limite de capacidade e atribuição do teste.

O registro não executa a porta

IANA registra discard na porta 9 para TCP e UDP e mantém linhas para SCTP e DCCP com outras referências. O RFC 863 define diretamente as duas primeiras. O registro preserva o significado do número; não garante um processo ativo.

O RFC 6335 chama 0–1023 de System Ports e separa estados atribuídos, não atribuídos e reservados. Atribuição é evidência administrativa. Não autentica software, conformidade, exposição ou consentimento para gerar tráfego.

Essa diferença impede que o número preencha o vazio UDP. No TCP, a conexão acrescenta uma observação do endpoint, mas o nome da porta ainda não identifica sozinho o processo. Registro e execução pertencem a cadeias de prova distintas.

Formular a frase verificável

Aceitação pelo kernel local exige telemetria local. Responsabilidade do TCP remoto exige estado e ACKs. Leitura pelo processo exige observação do receptor. Taxa de entrega UDP exige denominador enviado e numerador recebido. Misturar as quatro frases em “teste aprovado” destrói a utilidade do resultado.

Conserve transporte, endereços, horários, bytes, retransmissões, erros, origem do fechamento e contador receptor. Se surgir uma resposta aplicativa, preserve-a: o endpoint não se comportou como Discard, e a porta 9 não autoriza adivinhar sua identidade.

Fontes e limites

O serviço vem do RFC 863, e seu status elective do RFC 880. A fronteira TCP segue o RFC 9293. As não garantias UDP estão no RFC 768, com cautelas atuais no RFC 8085.

A governança do número usa o RFC 6335 e o registro IANA. Nada aí mede implantação, desempenho, tráfego ou abuso atuais nem identifica um servidor vivo.