Re: [PATCH 0/6] Add support for interface binding

On 11/6/18 8:03 AM, Bill Fenner wrote:
> My main question is, what's the advantage of storing the IPv4/IPv6 
> address as a string and a port number, instead of as a sockaddr_*?  
> I.e., why use netsnmp_ep_str?

Parsing endpoint addresses happens in two phases: first parsing the 
endpoint strings and next the conversion into a sockaddr_* structure. 
The code for the first conversion is shared by the IPv4 and IPv6 
transports while the code for the second conversion is transport 
specific. Hence two data structures, netsnmp_ep_str and netsnmp_ep.

> Is the API change here ok?  Are we assuming that nobody ever calls 
> netsnmp_foo_transport() directly?

My own preference is to make the entire transport API internal to 
libsnmp and not to allow any direct calls to any transport code from 
outside libsnmp. That would make it much easier to maintain and refactor 
that code.

> Should there be an #ifdef in patch 5 to make the interface name 
> optional, both in the struct and the parser, for platforms that don't 
> support it?  Is it better to return a parse error on the address that 
> includes interface name, or a "failed to open socket" without much more 
> information?

That case should already be handled by the following code in 
netsnmp_bindtodevice():

     if (!iface || iface[0] == '\0')
         return 0;
#ifdef HAVE_SO_BINDTODEVICE
     [ ... ]
#else
     errno = EINVAL;
     return -1;
#endif

> Given your proposed code structure, I imagine that we could add network 
> namespaces to netsnmp_ep too - this basically ends up using "socketat( 
> /* magic */, family, type, protocol )" instead of socket() to create the 
> socket, and the magic can be derived from what we store in ep.

That sounds like a good idea to me.

Bart.


_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders