Resumen

  • GetNext buscaba el sucesor lexicográfico inmediato entre las variables accesibles para la petición y devolvía tanto su OID como su valor.
  • Al encadenar los nombres recibidos, el gestor podía descubrir las instancias de una tabla conceptual sin pedir al agente una operación compleja de inventario.
  • SNMPv2 separó el final de cada recorrido con endOfMibView y agrupó pasos con GetBulk, pero la vista de acceso y el paso del tiempo siguieron limitando la conclusión.

La fila aparecía después de la consulta

Las definiciones MIB permitían conocer los OID de columnas como destino, siguiente salto o métrica. Los índices concretos dependían de las rutas presentes en un dispositivo. Por eso, consultar solo el nombre de una columna no equivalía a conocer sus instancias.

El RFC 1067 de 1988 describió GetNextRequest con una regla determinista: dentro de la lista ordenada de variables disponibles para lectura en la vista MIB pertinente, localizar el primer nombre que sigue lexicográficamente al recibido. La respuesta incluye ese nombre y el valor asociado.

El gestor no descarta el nombre. Lo coloca en la petición posterior. La segunda respuesta contiene el sucesor siguiente y vuelve a ofrecer un punto de avance. Una operación pequeña se transforma así en una marcha cuya memoria y límite residen en el lado gestor.

La tabla era una convención legible

La MIB representaba objetos administrados en un almacén virtual. No prometía las propiedades de una base de datos relacional. El nombre de una variable concreta combina el OBJECT IDENTIFIER del tipo con un fragmento que identifica la instancia. RFC 2578 formalizó después las tablas conceptuales y las cláusulas INDEX de SMIv2.

En el ejemplo de rutas del RFC inicial, la estación envía a la vez tres nombres de columna. El agente responde con los OID indexados de una fila. La estación devuelve esos OID y recibe la siguiente. El orden depende de los componentes numéricos del identificador, no de los rótulos amistosos ni de cómo una interfaz decida ordenar sus filas.

Esta distribución del trabajo era deliberada. SNMP reducía las funciones imprescindibles del agente y dejaba la supervisión detallada al sondeo desde el centro. Un conjunto limitado de traps orientaba ese sondeo. La interoperabilidad no exigía convertir cada equipo en un servidor de consultas rico.

Para terminar había que vigilar el prefijo

Después de la última instancia de una columna puede aparecer la primera de la columna siguiente. Al terminar una tabla, la ordenación continúa con objetos ajenos a ella. El espacio OID no adopta los bordes visuales de una pantalla.

El ejemplo de RFC 3416 muestra cómo la respuesta salta a otra columna y, finalmente, fuera de la tabla IP net-to-media. Esa salida es una señal válida. El gestor debe reconocer que el OID devuelto ya no empieza por el prefijo que se propuso recorrer.

Esperar solo un error es insuficiente. La aplicación conoce su intención; el agente solo conoce el siguiente nombre accesible. Si aquella no conserva la frontera, puede incorporar objetos vecinos y presentar la sobrelectura como una vista más completa.

En SNMPv1, el final de una trayectoria se comunicaba de forma más amplia. RFC 1157 indicaba noSuchName y un índice de error si cualquiera de los nombres no tenía sucesor accesible. El agotamiento de una columna interfería con otras incluidas en la misma petición.

SNMPv2 hizo que cada columna pudiera acabar por separado

Con RFC 1448, una variable sin sucesor recibió el valor excepcional endOfMibView. Las demás vinculaciones de la respuesta podían seguir transportando nombres y valores normales. RFC 1905 mantuvo la regla en la evolución normativa y RFC 3416 la conserva.

El significado no es “el dispositivo se ha quedado sin datos”. Es más limitado: para esta vinculación y esta petición no existe otro nombre accesible posterior. Precisamente esa modestia permite que varias columnas progresen a ritmos distintos.

GetBulk redujo intercambios. Los non-repeaters solicitan un sucesor cada uno; los demás pueden pedir varias posiciones mediante max-repetitions. Aun así, el agente puede devolver menos resultados por límites de tamaño. RFC 1905 también advierte que las respuestas grandes pueden fragmentarse y perder fiabilidad. La eficiencia no borra el presupuesto del transporte.

La misma máquina podía contar dos historias correctas

El conjunto ordenado solo contiene variables accesibles para la operación. RFC 3415 organiza la autorización mediante vistas construidas con subárboles incluidos y excluidos dentro de un contexto.

Dos grupos con permisos distintos pueden preguntar por el sucesor del mismo OID y recibir respuestas diferentes del mismo agente. Un objeto oculto no ocupa una posición en la lista visible. Por eso, endOfMibView no demuestra que falten objetos físicos, módulos privados, otros contextos o información disponible con otra identidad.

También varía el tiempo. Una tabla de vecinos o rutas puede cambiar entre dos respuestas. GetBulk acorta el intervalo, pero no crea una instantánea transaccional. El uso de sysUpTime en el ejemplo de RFC 3416 ayuda a detectar reinicios y a fechar observaciones; no hace simultáneas filas tomadas en momentos distintos.

Fuentes y alcance

La evidencia procede de RFC 1067, RFC 1157, RFC 1448, RFC 1905, RFC 2578, RFC 3415 y RFC 3416. Los textos prueban la semántica y su historia, no la compatibilidad de un producto actual, el despliegue, la seguridad de una sesión concreta ni el efecto real de una configuración.