Provided by: erlang-manpages_18.3-dfsg-1ubuntu3.1_all bug

NAME

       snmpm_network_interface - Behaviour module for the SNMP manager network interface.

DESCRIPTION

       This    module   defines   the   behaviour   of   the   manager   network   interface.   A
       snmpm_network_interface compliant module must export the following functions:

         * start_link/2

         * stop/1

         * send_pdu/7

         * inform_response/4

         * note_store/2

         * info/1

         * get_log_type/1

         * set_log_type/2

         * verbosity/2

       The semantics of them and their exact signatures are explained below.

       Legacy API function send_pdu/7 that has got separate IpAddr and PortNumber arguments still
       works as before for backwards compatibility reasons.

EXPORTS

       start_link(Server, NoteStore) -> {ok, Pid} | {error, Reason}

              Types:

                 Server = pid()
                 NoteStore = pid()

              Start-link the network interface process.

              Server is the pid of the managing process.

              NoteStore is the pid of the note-store process.

       stop(Pid) -> void()

              Types:

                 Pid = pid()

              Stop the network interface process.

       send_pdu(Pid, Pdu, Vsn, MsgData, Domain, Addr, ExtraInfo) -> void()

              Types:

                 Pid = pid()
                 Pdu = pdu()
                 Vsn = 'version-1' | 'version-2' | 'version-3'
                 MsgData = term()
                 Domain = transportDomainUdpIpv4 | transportDomainUdpIpv6
                 Addr = {inet:ip_address(), inet:port_number()}
                 ExtraInfo = term()

              Request the network interface process (Pid) to send this pdu (Pdu).

              ExtraInfo  is  some opaque data that is passed to the net-if process. It originates
              from  the  ExtraInfo  parameter  in  the  calls  to  the  synchronous  get-request,
              asynchronous  get-request,  synchronous  get-next-request,  asynchronous  get-next-
              request, synchronous set-request and asynchronous  set-request  functions.  Whether
              the  net-if  process  chooses  to  use this is implementation dependent. The net-if
              process included in this application ignores it.

       inform_response(Pid, Ref, Addr, Port) -> void()

              Types:

                 Pid = pid()
                 Ref = term()
                 Addr = address()
                 Port = integer()

              Instruct the network interface process to send the response (acknowledgment) to  an
              inform-request.

              Ref  is  something that can be used to identify the inform-request, e.g. request-id
              of the inform-request.

              Addr and Port identifies the agent, from which the inform-request originated.

       note_store(Pid, NoteStore) -> void()

              Types:

                 Pid = pid()
                 NoteStore = pid()

              Change the pid of the note-store process. This is used when  the  server  re-starts
              the note_store (e.g. after a crach).

       info(Pid) -> [{Key, Value}]

              Types:

                 Pid = pid()

              The  info returned is basically up to the implementer to decide. The implementation
              provided by this application provides info  about  memory  allocation  and  various
              socket information.

              The  info  returned by this function is returned together with other info collected
              by the manager when the info function is called (tagged with the key net_if).

       verbosity(Pid, Verbosity) -> void()

              Types:

                 Pid = pid()
                 Verbosity = verbosity()

              Change the verbosity of the network interface process.

       get_log_type(Pid) -> {ok, LogType} | {error, Reason}

              Types:

                 Pid = pid()
                 LogType = atl_type()
                 Reason = term()

              The Audit Trail Log is managed by the network interface process.  So,  it  is  this
              process that has to return the actual log-type.

       set_log_type(Pid, NewType) -> {ok, OldType} | {error, Reason}

              Types:

                 Pid = pid()
                 NewType = OldType = atl_type()
                 Reason = term()

              The  Audit  Trail  Log  is managed by the network interface process. So, it is this
              process that has to do the actual changing of the type.

              See set_log_type for more info.