On Mon, 2005-09-12 at 15:08 -0700, Wes Hardaker wrote:
> I do agree that we need the ability to specify default ports, but when
> you look at exactly where that needs to be done where it's *not* the
> norm then you'll see that's rather small. IE, currently only the trap
> handling is unique in a default port number.
You've forgotten about AgentX, which uses a different default port
(705). But the basic principle is sound - in 99% of the cases, the
required service will doubtless be SNMP (with a default port of 161).
But part of the idea that we've been batting about is a mechanism
for defining the default port to use for a particular server
when using a particular transport.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
So if I'm opening an SNMP connection over UDP (or TCP), then this
should default to port 161 - correct. But if I'm opening an SNMP
connection over an OSI transport, then it should default to a
transport selector of "snmp-l". And if I'm opening an SNMP
connection over Appletalk, then it should default to a DDP socket
number 8 (or a NBP service selected by "SNMP Agent" - I don't
know quite how this stuff works).
But the fundamental principle is that the application shouldn't
have to work out what type of transport is being used for any
particular connection. It's simply passed an (opaque) address
specification (which may or may not include a transport identifier
and/or explicit default port), and asks the transport module to
provide "an SNMP connection" using the appropriate transport
and default port (if necessary).
Robert and I have been suggesting different forms of how to represent
the requested service - either a string-based token ("snmpd:receive")
or an integer ID (which happens to be the same as the default UDP
port number). But that doesn't affect the underlying principle.
So that's the problem we're trying to solve.
> The majority of the APIs
> should be simple. open(SPEC);
Agreed.
Given that SNMP requests are the most common, it probably makes sense
for there to be an API to open an SNMP service connection, as a special
case wrapper for the more general "open an X service connection".
> Deviating from that to require an app
> to register something
The application wouldn't *need* to register anything.
*Something* would have to register the default port(s) to use for
the most common service(s) on the supported transport. But I'd
expect this registry to be seeded with appropriate values as part
of the library initialisation. So each of the transport-specific
modules would automatically register the default SNMP, SNMP-TRAP
and AgentX ports (or equivalent) for that particular transport.
The same mechanism would be available for the application to register
appropriate defaults for any *other* service that it might wish to
use (either as a client, or a server). But this should be handled
automatically for the "core services".
> then call another function with 4+ arguments
As you've probably gathered, I'm not in favour of splitting the
transport specification into three separate parameters. I've
been proposing a single address string (which could contain a
complete or partial specification), together with a numeric
service selector (*not* a default UDP port, though the value
would be exactly the same!)
The address string would be provided by the user, and wouldn't
need to be parsed by the application-level code. But I think
two parameters is the minimum necessary for a general-purpose
API (although there could be a single-parameter SNMP-only wrapper,
as discussed above).
Orthogonal to that, the same basic mechanism could also be used
to register a default transport and/or destination for each service
individually. This could be used to specify "tcp:" for the
AgentX service (leaving the default destination host undefined).
Alternatively, it could specify a transport of "unix:" with
a default destination of "/var/agentx/master"
Once again, suitable default defaults could be initialised by
the library code, and then over-ridden by the application itself
(or by configure directives). And naturally, any setting
explicitly provided by the user at run time would take precedence.
But this mechanism wouldn't necessarily result in more complex
application code, while still supporting a very flexible handling
of default transport settings.
That may not be quite how Robert/Magnus envisage this working,
but it's the mental model I'm currently working with.
Thoughts?
Dave
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
