요약

  • SNMP GetNext는 요청된 이름 다음에 오는 첫 번째 접근 가능한 주체 IDENTIFIER를 반환했으므로, 관리자는 각 답변을 다음 요청의 시작점으로 재사용할 수 있었습니다.
  • 후속 이름의 반복은 행 인덱스 목록을 미리 갖지 않고도 개념적 테이블을 순회할 수 있게 했으며, 단순히 오류를 받는 것이 아니라 의도한 서브트리를 벗어나는 것이 테이블의 경계를 표시했습니다.
  • SNMPv2는 바인딩별endOfMibView와 GetBulk 효율성을 추가했으며, 접근 제어 뷰, 응답 한도, 변화하는 장치 상태는 모든 순회를 부분적이고 시간 제약이 있는 것으로 유지했습니다.

관리자는 아직 행이 아니던 이름에서 시작했다

관리 스테이션이 라우터 테이블의 목적지와 다음 홉을 얻고 싶다고 가정해 봅시다. 스테이션은 MIB에 정의된 열 식별자는 알고 있지만, 인스턴스 접미사는 지금 이 장치에 존재하는 행에 속합니다. 단순한 GetRequest로 열 이름만 요청해서는 인스턴스를 열거할 수 없습니다.

RFC 1067의 1988년 사양은 더 작은 연산을 제공했습니다. GetNextRequest의 각 이름에 대해 에이전트는 해당 MIB 뷰에서 get 연산이 가능한 변수들의 사전 편찬 순서에서 바로 다음 후속 이름을 찾습니다. 응답은 그 후속 이름과 그 값도 함께 담습니다.

이름이 결정적인 부분입니다. 첫 응답이 하나의 경로 인덱스로 끝나는 인스턴스를 담고 있다면, 관리자는 그 완전한 반환 이름을 다음 GetNextRequest에 담아 보냅니다. 에이전트는 다음 접근 가능한 인스턴스로 전진합니다. 반복이 하나의 후속 규칙을 순회로 바꿉니다.

별도의 "모든 행을 달라"는 명령이 필요하지 않습니다. 루프를 소유하는 쪽은 관리자이며, 에이전트는 한 번에 하나의 순서가 매겨진 질문에 답합니다.

테이블은 순서가 매겨진 식별자에서 나타났다

SNMP의 관리 정보 베이스(MIB)는 관계형 데이터베이스가 아니라 가상 정보 저장소였습니다. 객체에는 전역적으로 구조화된 주체 IDENTIFIER 이름이 있었고, 테이블 열과 인스턴스 인덱스는 하나의 구체적 변수 이름으로 결합되었습니다.RFC 2578은 이후 이러한 개념적 테이블과 INDEX 절의 SMIv2 형식을 부여했습니다.

RFC 1067의 실습 예제는 이 설계를 구체적으로 보여줍니다. 관리자는 세 개의 경로 테이블 열 이름으로 시작합니다. 응답은 첫 번째 인덱스된 목적지, 다음 홉, 메트릭을 제공합니다. 관리자는 그 반환 이름들을 반복하며 다음 행을 받습니다. 친숙한 라벨의 알파벳 순서가 아니라 숫자 OID 구성요소의 순서가 "다음"의 의미를 결정합니다.

이는 SNMP의 더 큰 경제성과도 일치했습니다. 초기 아키텍처는 에이전트의 기능을 의도적으로 최소화했습니다. 관리자는 변수를 폴링했고, 제한된 트랩 집합이 그 폴링의 시점과 초점을 재조정했습니다. 풍부한 인벤토리 연산은 얇은 공용 프리미티브에서 가장자리에서 구성될 수 있었습니다.

테이블의 끝은 반드시 오류가 아니었다

사전 편찬 네임스페이스는 하나의 테이블 뒤에서도 계속됩니다. 한 열의 마지막 인스턴스가 반환된 후, 다음 후속은 다음 열의 첫 번째 인스턴스일 수 있습니다. 대상 테이블의 마지막 객체 뒤에는 접근 가능한 MIB 뷰의 완전히 다른 객체가 후속으로 올 수 있습니다.

RFC 3416은 두 전환을 모두 보여줍니다. 응답은 다음 열로 "감아 넘어간" 뒤 IP net-to-media 테이블을 벗어날 수 있습니다. 그 바깥 이름은 유용한 증거입니다. 요청한 서브트리가 끝났음을 관리자에게 알려줍니다. 이는 형식이 잘못된 응답이 아닙니다.

따라서 관리자에게 에이전트가 추론할 수 없는 의무가 있습니다. 의도한 접두사를 정의하고, 반환된 이름이 더 이상 그 아래에 속하지 않으면 중단하는 것입니다. 프로토콜 오류만 기다리는 순회는 관련 없는 관리 데이터로 계속 진입하여 그 초과분을 발견이라고 부를 수 있습니다.

SNMPv1의 종료 동작도 성긴 것이었습니다.RFC 1157에 따르면, 요청된 이름 중 하나라도 접근 가능한 후속 앞에 오지 않으면 응답은noSuchName과 오류 인덱스를 사용했습니다. 하나의 열이 고갈되는 것만으로 다중 바인딩 요청의 유용성이 손상될 수 있었습니다.

SNMPv2는 부재를 바인딩 단위로 국소화했다

RFC 1448은 일반적인 종료 조건을 바꿨습니다. 요청된 이름 하나에 사전 편찬 후속이 없을 때, 그 바인딩의 응답은endOfMibView를 담을 수 있습니다. 다른 바인딩들은 여전히 이름과 값을 반환할 수 있습니다.RFC 1905는 그 모델을 Standards Track에 유지했고, RFC 3416은 이를 현재의 프로토콜 연산 사양으로 계승합니다.

이것은 단지 더 다정한 오류 보고 이상이었습니다. 동시에 진행되는 여러 순회의 독립성을 보존했습니다. 한 열은 끝나는 동안 다른 열은 계속될 수 있었습니다. 그 결과는 장치에 다른 정보가 없다고 말하는 것이 아니라, 이 요청을 지배하는 뷰에서 이 바인딩에는 더 이후의 접근 가능한 이름이 없다고 말하는 것이었습니다.

SNMPv2는 또한 GetBulk를 도입했습니다. 처음non-repeaters는 각각 하나의 후속을 받고, 나머지 바인딩들은max-repetitions개까지의 연속 위치를 받을 수 있습니다. 같은 테이블을 더 적은 요청-응답 교환으로 순회할 수 있게 된 것입니다.

그러나 "대량"이 "완전"를 의미하지는 않았습니다. 응답자는 산술적 최대치보다 적은 바인딩을 반환할 수 있습니다. 메시지 크기 한도도 여전히 적용됩니다. RFC 1905는 관리자에게 반복 횟수를 경로 단편화를 고려하여 선택하라고 경고하며, 특히 네트워크 부하 상황에서 그렇게 하라고 합니다. GetBulk는 후속 규칙을 일괄 처리할 뿐, 전송 물리학을 정지시키지 않습니다.

순회가 드러낸 것은 장치 전체가 아니라 뷰였다

후속 규칙 안에는 "접근 가능한(accessible)"이라는 단어가 들어 있습니다. 이것은 장식이 아닙니다. 관리 프레임워크가 해당 연산에 보이는 MIB 뷰를 선택합니다.RFC 3415는 컨텍스트 내부의 포함/제외 서브트리로 뷰를 정의하고, 서로 다른 그룹이 서로 다른 부분집합을 받도록 허용합니다.

따라서 두 명의 적절히 권한을 부여받은 관리자가 같은 장치에 같은 OID의 후속을 요청해도 서로 다른 참된 답을 받을 수 있습니다. 제외된 객체는 그 요청의 순서 목록에 없는 것처럼 건너뛰어집니다.endOfMibView는 해당 연산에서 접근 가능한 이름들의 끝을 증명할 뿐, 숨겨진 객체, 비공개 모듈, 다른 컨텍스트 또는 더 높은 권한의 뷰가 존재하지 않음을 증명하지 못합니다.

시간이 두 번째 경계를 만듭니다. 순회는 일련의 교환입니다. 경로 테이블은 첫 응답과 마지막 응답 사이에 바뀔 수 있으며, GetBulk는 스냅샷 격리를 제공하지 않습니다. RFC 3416의 예제는 테이블 값 옆에sysUpTime을 함께 읽어 관찰을 시간에 위치시키는 데 도움을 주지만, 프로토콜은 개별적으로 샘플링된 행을 하나의 원자적 인벤토리로 바꾸지 않습니다.

출처와 한계

이 메커니즘과 그 진화는RFC 1067,RFC 1157,RFC 1448,RFC 1905,RFC 2578,RFC 3415,RFC 3416에 의해 확립됩니다. 이 문서들은 명명, 후속 처리, 테이블 예제, 대량 검색, 뷰 범위 지정을 확립합니다. 이들은 벤더 구현을 인증하거나, 현재 배포 현황을 측정하거나, 보안 전송을 보장하거나, 순회를 운영 효과의 증명으로 만들지 않습니다.