On Thu, Sep 08, 2005 at 02:52:35PM +0100, Dave Shield wrote:
> On Wed, 2005-09-07 at 18:13 +0200, Magnus Fromreide wrote:
> > On Wed, Sep 07, 2005 at 04:06:13PM +0100, Dave Shield wrote:
>
> > > What I'd envisage would be a call such as
> > >
> > > netsnmp_transport *
> > > netsnmp_transport_open( char *string, int def_port )
> > >
> > > which would take a transport specification string:
> > > ("tcp:localhost:1234", "udp:10.0.0.1", "myhost", etc) and
> > > a default port number (which the first example would ignore),
> > >
> > > This routine would then return the appropriate transport
> > > structure.
> >
> > Yes, but what is a default port number in an IPX context?
>
> An IPX socket number - probably 36879 (0x900f).
> (or 36880/0x9010 for trap receivers)
>
> [You'd have done better to ask about OSI or AppleTalk transports,
> which do use string-based transport service point identifiers!]
Ok :-)
> > The reason I used a
> > void* for the user argument is so that anything imaginable
> > could be transferred
>
> But anything imaginable *can* be transferred, by using the
> main address string.
But the main address string is already set by the user and the whole point is
that I shouldn't have to parse it to add reasonable default values and then
pass it to the agent that parses it again.
> This is the primary way to refer to a transport address. The (integer)
> default port is simply a convenient way to refer to particular sockets
> in the most common cases, and is for backwards compatability as much as
> anything.
>
> 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.
> I can't help feeling that you're complicating things unnecessarily.
Quite possible.
> > I am also imagining that for example you could send in "unix:"
> > to the agentx handler and make it use /var/agentx/master,
>
> Indeed.
>
> > something your proposal can't do.
>
> Yes, it can:
>
> netsnmp_transport_open("unix:/var/agentx/master", 0);
>
> > Finally you can implement netsnmp_transport_open as:
>
> > netsnmp_transport *
> > netsnmp_transport_open( char *string, int def_port )
> > {
> > return netsnmp_tdomain_transport_ex(sink, 0, "udp",
^ bug here, should be string.
> > &netsnmp_transport_open_match,
> > &def_port);
> > }
>
> No, that doesn't work. You're forcing a UDP transport.
No, the third argument is a default transport that should be used unless the
user have said something else. "host" would be parsed as "udp:host:def_port"
while "tcp:somewhere:21" would be parsed as exactly "tcp:somewhere:21". All of
this is in the existing implementation and I do not change it.
> The main point of the 'netsnmp_transport_open' routine
> is that *this* is where to make the decision about which
> transport domain to use.
I would like to point out that I do not allow you to change the transport
domain from the match functions, what they do is to add a hook for parsing
everything after "domain:", so on that point there is no disagreement.
> So this routine should be something like:
>
> netsnmp_transport *
> netsnmpp_transport_open( char *string, int def_port )
> {
> if ( !strncmp( string, "udp:", 4) ||
> !strncmp( string, "tcp:", 4)) {
> return netsnmp_transport_open_in( string, def_port );
> } else if ( !strncmp( string, "udp6:", 5) ||
> !strncmp( string, "tcp6:", 5)) {
> return netsnmp_transport_open_in6( string, def_port );
> } else if ( !strncmp( string, "ipx:", 4)) {
> return netsnmp_transport_open_ipx( string, def_port );
> } else if ( !strncmp( string, "unix:", 5)) {
> return netsnmp_transport_open_unix( string, def_port );
>
> <etc, etc>
>
> } else {
> /* Default to IPv4 transports */
> return netsnmp_transport_open_in( string, def_port );
> }
> }
I think this is what netsnmp_tdomain_transport is doing in the current code,
at least it looks that way to me, except that there isn't any def_port
argument.
> > Yes, but if the session routines wish to bother about it then
> > we shouldn't stop them, should we?
>
> Yes.
> Because that's the whole point of having a modular transport
> mechanism. *Nothing* else should be interpreting addresses and
> suchlike directly.
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.
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.
> Consider what happens when we need to add support for IPv99,
> fifty years from now.
>
> If everything is using the modular transport APIs, we'd just
> need to write a new 'snmpIP99Domain.c' file, and tweak the
> various transport-selection routines (all in 'snmp_transport.c')
> to know about this option. No other code would need to be touched.
I might have failed to convey how I interpret the return values of the match
function:
1 - Success, a good address written in addr, open it
0 - Failed to parse, return failure.
-1 - I do not know what this is, try with the default handler for the
transport domain.
So what will happen when we add IPv99 is that nothing will know about it and
thus it will fall back on the default routine that tries to open a port that
is good for snmp (udp:161 on IPv4, don't know on IPv99).
> If we allow individual applications to meddle with such stuff
> directly, then we'd have to search through the whole code tree,
> to discover (and fix) all the places this might be being done.
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 deafults
they should use on various transports.
/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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
