On Fri, Sep 09, 2005 at 09:39:20AM +0100, Dave Shield wrote:
> 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.
I agree with that.
> There are relatively few of these "well known port numbers"
> relevant to SNMP, and these could be hard-coded quite easily.
Yes, the hard part is how to specify the interface. The key for lookups must
contain at least
a) A transport reference
b) A service reference
> 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.
Yes, please.
> 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).
Agreed.
> > 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.
Yes.
> 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.
Yes - the fact that we currently fail to call getservbyname on provided port
names is beside the point in this context.
> 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.
I suppose that in the case where there is no default IP port number I could
use a number greater than 65535, that might call for an ID assigment engine
but lets ignore that for now.
> 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')
So that suggests a function on the form:
void*
netsnmp_getservbytoken(int service, const char* domain);
If it returns NULL then nothing was found, otherwise cast the result to a
pointer to a transport-specific port representation and use it as needed.
We could then have something like
int
netsnmp_setservtoken(int service, const char* domain,
void* token, size_t token_size);
for registrations.
> > 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.
Here I think we talk around each other. I wanted to be able to mash any
address for a foo transport, while you say that if I do that then I have to
handle any address, find the foo ones and mash them.
> - or as a netsnmp_transport structure, containing the
> equivalent transport-specific expansion of that address.
This is a nice black box to work with.
> 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).
I am still not convinced but will rest that for now.
> 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! :-)
Well, this I agree fully with :-)
/MF
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
