home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / snmp / 512 < prev    next >
Encoding:
Internet Message Format  |  1992-07-27  |  2.3 KB
  1. Path: sparky!uunet!zephyr.ens.tek.com!shaman!thistle!stevet
  2. From: stevet@thistle.wv.tek.com (Steve Tarr;685-3528;63-356;;)
  3. Newsgroups: comp.protocols.snmp
  4. Subject: tcpConnEntry instance naming
  5. Message-ID: <1495@shaman.wv.tek.com>
  6. Date: 27 Jul 92 22:54:58 GMT
  7. Sender: nobody@shaman.wv.tek.com
  8. Reply-To: stevet@pogo.wv.tek.com
  9. Organization: Tektronix, Inc., GPID
  10. Lines: 44
  11.  
  12. I'm trying to make sense of the last few paragraphs of Section 5.3.2
  13. "Problems with Naming" in _The Simple Book_:
  14.  
  15.         "Of course, it might be possible that there is no way to
  16.     uniquely identify a particular entry in the table. ..."
  17.  
  18.         "A special "hack" can be used in this case.  If multiple
  19.     rows in a table have the same key, the agent marks one of
  20.     these rows as the primary.  The other rows with the same key
  21.     are ... assigned an implementation-dependent, small, unique
  22.     non-negative integer. To identify an instance of a secondary
  23.     row, this integer is appended onto the instance identifier of
  24.     the primary row."
  25.  
  26. My (embedded) protocol stack maintains a separate connection endpoint for
  27. each possible TCP connection to a server.  New connection requests are
  28. handled by finding the first entry in the table with the correct local
  29. address/port in state LISTEN, copying the remote address/port information
  30. from the packet into the entry, and setting the entry state to SYN-RECEIVED.
  31. What this means for SNMP is that there are often a number of connection
  32. endpoints with identical address/port information, i.e. local address
  33. 0.0.0.0, local port 8000, remote address 0.0.0.0, and remote port 0,
  34. all in state LISTEN.  I'd like to make all these endpoints visible for
  35. monitoring, since the number of "available" endpoints is an important
  36. resource limitation.
  37.  
  38. Assuming three such entries, the text would seem to imply that the
  39. corresponding instances of tcpConnState would be named:
  40.  
  41.     tcpConnState.0.0.0.0.8000.0.0.0.0.0
  42.     tcpConnState.0.0.0.0.8000.0.0.0.0.0.1
  43.     tcpConnState.0.0.0.0.8000.0.0.0.0.0.2
  44.  
  45. This is admittedly somewhat awkward to implement, since the resulting
  46. instance identifiers aren't all the same length, but I could live with
  47. that.  The nagging problem is that I can't find any support for this
  48. "hack" in the SNMP or MIB RFCs or in any of the public implementations
  49. I've looked at.
  50.  
  51. Is my interpretation correct?
  52.  
  53. Steve Tarr
  54. Tektronix, Inc. GPID
  55. stevet@pogo.wv.tek.com
  56.