[email protected] (Alfred M. Szmidt) writes: > [email protected] (Alfred M. Szmidt) writes: > > > I've been quite annoyed over how one does sockets on unixoid system > > for sometimes, specially with all the idiosyncrasies of IPv4 vs. IPv6. > > In what way? If you use getaddrinfo properly, you don't have to care a > lot about IPv4 or IPv6 differences in my experiences. There is a lot of > code in InetUtils that uses old network coding habits though. > > As an example take logger, for such a simple utility you have alot of > code just handling parsing of an host name, and setting up a > connection; and this code is duplicated is about all the utilities.
Shouldn't that assume getaddrinfo? Also I'm not sure the IPv6 parsing is necessary. Alas, some special code for IPv4/IPv6 will be necessary, you often want to be able to specify that either IPv4 or IPv6 should be used, and there is no way to say that with just a string that goes into getaddrinfo. > Ideally, all you should care about is "what you send" and "what you > read"; the "where" and "from" should be handled by some wrapper and > all you want to know is where to read/write from/to some "network > descriptor". > > getaddrinfo (from gnulib, thank you Simon!) does make things alot > easier, but I was mostly thinking about simplifying the whole socket > handling business, IP address parsing and what not. That should be done by getaddrinfo. Or is there some reason logger parses numeric IPv6 addresses? > > Plan 9 has a quite nice API that is very much agnostic when it > > comes to IPv6, IPv4, ICMP, UDP, TCP, ... etc. Now, I haven't > > used it at all, and maybe it is not flexible enough for our > > purpose. Here is what a basic ping might look like, > > Personally, I prefer POSIX standard here since people are more familiar > with it. Further, I would want to know how portably you could implement > the Plan 9 interface before deciding. If you can't do it portably > (i.e., assume POSIX but no more), I think it is a bad idea. > > Full agreement, as you say maybe the Plan 9 interface isn't good for > us. Using any non-standard _system_ API (not just POSIX, since alot > of things we have are based RFC's) is simply a no-go, but this was > more of wrapping the standard APIs (with all their strange cornder > cases) into something we can use to clean things up. > > Maybe this can all be solved by cleaning up the old crufy code, which > will be as much work as implementing a new (internal) API... Not sure > which way is better. If we come up with a good API, either the Plan 9 or something else, trying to do that in gnulib seems like a good way to have good review of it. /Simon
