From: Hans H. <han...@gm...> - 2014-09-24 07:26:30
|
[Sorry for duplicate post, I had to subscribe to sbcl-devel first] 2014-09-24 9:03 GMT+02:00 Christophe Rhodes <cs...@ca...>: > Jan Moringen <jmo...@te...> writes: > > > Christophe, how should we proceed? The original plan was getting the > > changes into the upcoming release (mostly to support Hans' IPv6 > > extension of usocket). Should I push now to allow people to test the > > changes and try to fix all surfacing problems before the release? Or > > should we wait until after the release? > > I think I'm a little uncomfortable about this: it seems like the kind of > thing that would cause build failures / sb-bsd-sockets test failures, > simply because we haven't tested hard enough. So, unless we hear > squeals of pain from Hans that this can't wait, I would suggest holding > off until early in the next cycle, which promises to be wildly exciting. It can't wait. IPv6 support is overdue. That said: I completely understand the desire to keep the tests stable, and it is quite obvious that there is a lot of opportunity for breakage in this area. Would there be an option to have a second contrib in the upcoming release cycle which is a copy of sb-bsd-sockets with IPv6 support and which would need to be enabled explicitly? That way, the changes could see some testing and I could make some progress with usocket support, while still keeping the interface stable. Also, clearly we need to deprecate get-host-by-name in its current form. That means we can have a long bikeshedding discussion about what > a new interface should look like! Bonus points if it is obvious how it > would support ipv17. > When it comes to get-host-by-name, I would suggest that the best way is to completely rely on the "new" getaddrinfo() call, which can be used to convert all kinds of host and port specifications into addresses. That way, SBCL would support the same address and port syntax as the rest of the host system does, and there would be the opportunity to deal with hosts that have multiple addresses in a consistent manner. This is particularly true with dual-stack hosts, which have IPv4 and IPv6 addresses be returned in a particular order when using getaddrinfo(). There is no need to invent something new here, and I'd say that consistency with the rest of the system would be desirable. -Hans |
From: Stas B. <sta...@gm...> - 2014-09-24 08:56:06
|
Hans Hübner <han...@gm...> writes: > [Sorry for duplicate post, I had to subscribe to sbcl-devel first] > > 2014-09-24 9:03 GMT+02:00 Christophe Rhodes <cs...@ca...>: > >> Jan Moringen <jmo...@te...> writes: >> >> > Christophe, how should we proceed? The original plan was getting the >> > changes into the upcoming release (mostly to support Hans' IPv6 >> > extension of usocket). Should I push now to allow people to test the >> > changes and try to fix all surfacing problems before the release? Or >> > should we wait until after the release? >> >> I think I'm a little uncomfortable about this: it seems like the kind of >> thing that would cause build failures / sb-bsd-sockets test failures, >> simply because we haven't tested hard enough. So, unless we hear >> squeals of pain from Hans that this can't wait, I would suggest holding >> off until early in the next cycle, which promises to be wildly exciting. > > > It can't wait. IPv6 support is overdue. The wait is only one month, and the code will (hopefully) come in early in the next release cycle, so that anybody who wants to test it can easily use it. -- With best regards, Stas. |
From: Jan M. <jmo...@te...> - 2014-09-27 18:36:39
|
On Wed, 2014-09-24 at 12:55 +0400, Stas Boukarev wrote: > Hans Hübner <han...@gm...> writes: > > > > It can't wait. IPv6 support is overdue. > > > The wait is only one month, and the code will (hopefully) come in early > in the next release cycle, so that anybody who wants to test it can > easily use it. Since the 1.2.4 release is done, I pushed the basic IPv6 support to master. Please test for regressions w.r.t. IPv4, UNIX domain sockets and name service functionality. Hans, please let us know whether anything else is necessary for the usocket extension. Kind regards, Jan |
From: Stelian I. <sio...@cd...> - 2014-09-24 10:03:12
Attachments:
signature.asc
|
On Wed, 2014-09-24 at 03:26 -0400, Hans Hübner wrote: [...] > When it comes to get-host-by-name, I would suggest that the best way is to > completely rely on the "new" getaddrinfo() call, which can be used to > convert all kinds of host and port specifications into addresses. That The reason why I wrote a full DNS resolver for IOlib is because getaddrinfo behaviour was - 8 years ago - so unportable that the code ended up a big pile of reader conditionals. If you still want to use getaddrinfo(), the code is in the IOlib repository, from around 2006 and as a bonus, the code is pre-CFFI so it uses sb-alien directly. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. |
From: Jan M. <jmo...@te...> - 2014-09-24 10:22:13
|
On Wed, 2014-09-24 at 11:55 +0200, Stelian Ionescu wrote: > On Wed, 2014-09-24 at 03:26 -0400, Hans Hübner wrote: > [...] > > When it comes to get-host-by-name, I would suggest that the best way is to > > completely rely on the "new" getaddrinfo() call, which can be used to > > convert all kinds of host and port specifications into addresses. That > > The reason why I wrote a full DNS resolver for IOlib is because > getaddrinfo behaviour was - 8 years ago - so unportable that the code > ended up a big pile of reader conditionals. If you still want to use > getaddrinfo(), the code is in the IOlib repository, from around 2006 and > as a bonus, the code is pre-CFFI so it uses sb-alien directly. SBCL, more specifically sb-bsd-sockets, already uses get{addr,name}info() when they are available on the target. There is a fallback to gethostbyname(). I cannot comment on the portability of either. The change will consist in returning/accepting IPv6 addresses in addition to IPv4 addresses. |
From: Stas B. <sta...@gm...> - 2014-09-24 11:11:51
|
Stelian Ionescu <sio...@cd...> writes: > On Wed, 2014-09-24 at 03:26 -0400, Hans Hübner wrote: > [...] >> When it comes to get-host-by-name, I would suggest that the best way is to >> completely rely on the "new" getaddrinfo() call, which can be used to >> convert all kinds of host and port specifications into addresses. That > > The reason why I wrote a full DNS resolver for IOlib is because > getaddrinfo behaviour was - 8 years ago - so unportable that the code > ended up a big pile of reader conditionals. If you still want to use > getaddrinfo(), the code is in the IOlib repository, from around 2006 and > as a bonus, the code is pre-CFFI so it uses sb-alien directly. I don't think getaddrinfo deals with timeouts nicely, there's getaddrinfo_a, but its implementation didn't impress me, and it's glibc only. And the way usocket currently uses sb-ext:with-timeout around sb-bsd-sockets:get-host-by-name sometimes leads to a corrupt glibc state and sbcl needs to be restarted to resolve any more hostnames. So, if you want timeouts or perform asynchronous lookups, implementing the resolver is the only sane way to go. -- With best regards, Stas. |
From: James Y K. <fo...@fu...> - 2014-09-24 12:52:50
|
A custom resolver should never be the default in a general purpose library because the admin can configure their local resolver in many ways other than dns server. Only getaddrinfo knows about that. (But it's great to have a native lisp resolver as a library you can use in an application if needed.) On September 24, 2014 7:11:45 AM EDT, Stas Boukarev <sta...@gm...> wrote: >Stelian Ionescu <sio...@cd...> writes: > >> On Wed, 2014-09-24 at 03:26 -0400, Hans Hübner wrote: >> [...] >>> When it comes to get-host-by-name, I would suggest that the best way >is to >>> completely rely on the "new" getaddrinfo() call, which can be used >to >>> convert all kinds of host and port specifications into addresses. >That >> >> The reason why I wrote a full DNS resolver for IOlib is because >> getaddrinfo behaviour was - 8 years ago - so unportable that the code >> ended up a big pile of reader conditionals. If you still want to use >> getaddrinfo(), the code is in the IOlib repository, from around 2006 >and >> as a bonus, the code is pre-CFFI so it uses sb-alien directly. >I don't think getaddrinfo deals with timeouts nicely, there's >getaddrinfo_a, but its implementation didn't impress me, and it's glibc >only. And the way usocket currently uses sb-ext:with-timeout around >sb-bsd-sockets:get-host-by-name sometimes leads to a corrupt glibc >state >and sbcl needs to be restarted to resolve any more hostnames. > >So, if you want timeouts or perform asynchronous lookups, implementing >the resolver is the only sane way to go. > >-- >With best regards, Stas. > >------------------------------------------------------------------------------ >Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS >Reports >Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >_______________________________________________ >Sbcl-devel mailing list >Sbc...@li... >https://lists.sourceforge.net/lists/listinfo/sbcl-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |