Resumo

  • RFC 2013 definiu quatro Counter32 somente de leitura para toda a implementação UDP: datagramas entregues a usuários UDP, recebidos sem aplicação na porta de destino, não entregues por outros erros e enviados pela entidade.
  • Cada linha de udpTable era indexada apenas pelo endereço IPv4 e pela porta locais. Não havia endereço ou porta remotos, processo, instância de socket ou identidade de datagrama.
  • RFC 4113 acrescentou tipos e valores de endereços locais e remotos, portas, discriminador de instância e processo do sistema. Isso melhorou a atribuição do endpoint, não a prova de processamento ou resultado.

Quatro totais não formavam um diário

Os quatro escalares separavam resultados úteis dentro do mecanismo UDP. udpInDatagrams contava entregas a usuários UDP. udpNoPorts registrava datagramas recebidos sem aplicação na porta de destino. udpInErrors reunia outras falhas de entrega de entrada. udpOutDatagrams contava datagramas enviados pela entidade.

Nenhum deles era indexado por endpoint. Não havia par remoto, processo, horário, identificador de mensagem ou vínculo entre entrada e saída. A coincidência de dois aumentos não demonstra que um datagrama foi resposta ao outro.

RFC 1902 torna a leitura ainda mais limitada: Counter32 sobe até 2^32−1, retorna a zero, não tem valor inicial definido e uma leitura isolada em geral não contém informação. Reinicialização pode interromper a sequência. Uma diferença exige duas amostras e evidência de continuidade; mesmo correta, continua sendo diferença da entidade inteira.

A tabela era um catálogo de coordenadas locais

udpTable listava endpoints em que uma aplicação local aceitava datagramas naquele momento. O índice era udpLocalAddress mais udpLocalPort. 0.0.0.0 significava escuta em qualquer interface local; a porta variava de 0 a 65535.

Uma linha sustentava uma afirmação estreita: no instante da coleta, o agente representava aquela coordenada IPv4 local como listener. Não mostrava de onde veio um datagrama. Não nomeava o processo, não distinguia sockets que reutilizavam a mesma tupla e não ligava a linha aos contadores globais.

O fato de uma aplicação estar “aceitando datagramas” também não prova processamento. O registro não diz se um payload específico saiu do buffer, passou pela validação, foi autorizado ou provocou uma ação. Não demonstra resposta, entrega remota ou resultado para o usuário. A porta identifica a recepção possível, não a conversa ocorrida.

Entregue ao usuário UDP ainda não significava resolvido

udpInDatagrams é mais preciso do que presença numa interface: sua definição fala em entrega a usuários UDP. Isso é um resultado real da camada de transporte. Mas a fronteira da aplicação vem depois.

O contador não registra leitura pelo código, interpretação ou mudança de estado. udpNoPorts prova ausência de aplicação na porta para seu total, sem preservar o remetente. udpInErrors combina os demais motivos de não entrega. udpOutDatagrams termina no envio pela entidade, sem comprovar chegada ao host ou à aplicação remota.

Para sustentar uma conversa, o operador precisa unir identidade do datagrama ou evento, estado do endpoint, ciclo do processo, recibo da aplicação e observação independente do resultado.

RFC 4113 redesenhou a identidade do endpoint

RFC 4113 substituiu RFC 2013 em 2005. Manteve os quatro contadores e tornou udpTable obsoleta por dois motivos: suporte apenas a IPv4 e incapacidade de descrever endpoints UDP “conectados”. A limitação de família de endereços não é a tese deste texto. A segunda razão mostra que um índice puramente local não descrevia o outro lado possível.

udpEndpointTable passou a representar listeners com remoto curinga e endpoints com endereço e porta remotos definidos. O índice incluiu tipos, endereços e portas locais e remotos, mais udpEndpointInstance. A instância separava processos sobre a mesma tupla, inclusive em reutilização com SO_REUSEADDR ou SO_REUSEPORT. udpEndpointProcess fornecia o ID do processo, ou zero, com correlação esperada a MIBs de host e aplicação.

O avanço é de identidade gerencial. Não cria uma sessão confiável. Um PID pode faltar ou ser reutilizado. Um remoto configurado não prova troca de datagrama. Nenhum campo certifica parse, autorização, resposta ou efeito de serviço.

Mais identidade também significa mais sensibilidade: RFC 4113 avisou que os índices podiam revelar portas abertas. A MIB continuou sem objetos de escrita, mas o direito de observar merecia proteção.

A conclusão deve permanecer no nível observado

RFC 2013 nunca prometeu um livro de conversas. O erro seria converter um total da entidade em falha de um serviço, uma porta local em interlocutor, “enviado” em “entregue” ou entrega UDP em conclusão comercial.

A afirmação defensável mantém a escala: entre duas amostras contínuas, este contador da entidade cresceu; neste instante, o agente mostrou este listener local. Atribuição exige evento ou pacote correlacionado. Processamento exige recibo da aplicação. Entrega exige observação remota. Sucesso exige definição e medição do serviço.

Porta é coordenada. Contador é denominador. Conversa é cadeia de eventos atribuídos. RFC 4113 tornou parte da cadeia explícita, sem fabricar o desfecho.

Fontes

Limites da evidência

As fontes comprovam linhagem documental, definições, semântica dos contadores e modelo sucessor. Não comprovam implementação de fornecedor, adoção, configuração atual, defeito, incidente, SLA, tráfego medido ou resultado de aplicação.