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!]
> 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. 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.
I can't help feeling that you're complicating things
unnecessarily.
> 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",
> &netsnmp_transport_open_match,
> &def_port);
> }
No, that doesn't work. You're forcing a UDP transport.
The main point of the 'netsnmp_transport_open' routine
is that *this* is where to make the decision about which
transport domain to use.
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 );
}
}
> > The create_trap_session* routines shouldn't need to bother
> > about *any* of that detail - it's purely a matter for the
> > library transport code.
>
> 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.
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.
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.
That's my understanding anyway.
Anyone else wish to comment?
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
