SNMP 索引的抽象資料型別

模組 snmp_index 實作了用於 SNMP 表格的 SNMP 索引結構的抽象資料型別 (ADT)。它以 ordered_set 資料型別的 ets 表格實作，這表示所有操作都是 O(log n)。在表格中，鍵值是一個 ASN.1 OBJECT IDENTIFIER。

此索引用於將 SNMP 排序的實作與表格的實際實作分離。SNMP 排序，即 GET NEXT 的實作，是在此模組中實作的。

例如，假設有一個 SNMP 表格，在 Erlang 中最好以每個 SNMP 表格列一個程序的方式實作。進一步假設 SNMP 表格中的 INDEX 是一個 OCTET STRING。索引結構將如下建立：

snmp_index:new(string)

對於我們建立的每個新程序，我們會在 snmp_index 結構中插入一個項目。

new_process(Name, SnmpIndex) ->
  Pid = start_process(),
  NewSnmpIndex =
    snmp_index:insert(SnmpIndex, Name, Pid),
  <...>

有了這個結構，我們現在可以將例如 GET NEXT 請求中的 OBJECT IDENTIFIER 對應到正確的程序。

get_next_pid(Oid, SnmpIndex) ->
  {ok, {_, Pid}} = snmp_index:get_next(SnmpIndex, Oid),
  Pid.

警告

警告

所有更新索引的 API 函式都會回傳一個 NewIndex 項。這是為了與先前使用純 Erlang 編寫的 B+ 樹作為索引的實作向後相容。NewIndex 回傳值現在可以忽略。現在的回傳值是 ets 表格不變的表格識別碼。

使用 ets 表格的實作引入了與舊實作的語義不相容性。在那些使用純 Erlang 項的舊實作中，索引像任何其他 Erlang 項一樣進行垃圾回收，並且在丟棄時不必刪除。ets 表格僅在建立它的程序明確刪除它或建立程序終止時才被刪除。

現在新增了一個新的介面 delete/1，以處理程序想要丟棄索引表格的情況（即建立一個全新的表格）。任何使用暫時性 snmp 索引的應用程式都必須修改以處理此情況。

由於 snmp 適配通常會將索引保留在整個系統的生命週期中，因此這很少會是問題。