Re: [bug-inetutils] plan9 like socket interface

[Simon Josefsson]

address@hidden (Alfred M. Szmidt) writes:

>    address@hidden (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