On Thu, 2005-09-08 at 19:12 +0200, Magnus Fromreide wrote:
> On Thu, Sep 08, 2005 at 02:52:35PM +0100, Dave Shield wrote:
> > In fact, it might be sensible for the OSI and Appletalk
> > transport-specific parsing code to check for these common
> > port numbers, and convert them into the equivalent string
> > identifiers. Anything else would either be rejected or
> > ignored.
>
> But this pushes the knowledge of the default ports for every protocol
> into the transport handlers and that I feel breaks modularity.
However we structure things, there's going to have to be *somewhere*
that modularity gets fractured slightly.
As you said yourself:
> Yes, that have to be done somewhere regardless of what scheme is used - the
> question is if it is better that the transports knows about the defaults for
> any protocol that they might carry or if the services knows about the defaults
> they should use on various transports.
I'd say the second.
There are relatively few of these "well known port numbers"
relevant to SNMP, and these could be hard-coded quite easily.
For flexibility, I suspect we'd need to have a dynamic mapping
to handle (rather than fixed "if" statements), and provide an
API for an application to extend this mapping with new default.
But this still feels a cleaner approach than providing
transport-specific defaults at the application layer
(where this will be scattered across widely disparate files).
> This was also the reason that I exported the AAL5PVC and UNIX address parsing
> routines and, at least for UNIX, gave it a hook for default values. I know
> to little about AAL5PVC addresses to say where the default value should be.
That illustrates my point, really.
The place for knowledge about per-transport defaults is in the
transport-specific domain handler, where the person coding this
*would* know what the default values should be for particular
services.
As far as an application writer is concerned, they should be able
to say:
"I'm talking to a SNMP notification receiver, so use
the appropriate default socket for that service."
They're primarily interested in the *service* that they want
to talk to - not how that service happens to be represented.
They shouldn't need to know about the existance of AAL5PVC at
all - but if the user provides an AAL5 address, the library
should Do The Right Thing.
Think of this as an extension of the /etc/services file on Unix.
Good programming practise would be to use
getservbyname("snmp");
to retrieve the SNMP (agent) port number, rather than hardwiring
it as 161. A multi-transport equivalent to getservbyname would
be able to return the appropriate TSP identifier automatically.
What I'm proposing doesn't work in quite the same way, but the
basic idea is the same. Instead of using a "service name" to
identify the service, we use the IP port number. The various
transport-specific code routines can then interpret this appropriately
for that particular transport - either using it directly, or
converting it into the local equivalent ('getservbyNum')
> The reason I chose to interpret addresses was that an sockaddr_in
> can't convey a nonpresent item in any way, and the point was to
> provide defaults.
But by the point the sockaddr_in is created, then the default
should *already* have been applied.
At the application level, I'd suggest there are only two valid
ways to refer to a particular address:
- either as a string representation ("udp:localhost:161", etc),
where not all the elements need necessarily be present,
and possibly accompanied by an (optional) default port.
- or as a netsnmp_transport structure, containing the
equivalent transport-specific expansion of that address.
An application shouldn't be passing around a bare sockaddr_in
structure at all - it should always work with one of these
two ("before" and "after" interpretation).
Now it might need some code cleanup to get to such a state,
but that's where I think we should be heading - improving
the situation, rather than making it worse! :-)
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
