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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
