Thank you very much...
And I’d like to add some notes to the exist IPv6 support status of CL platforms currently supported by USOCKET:
AllegroCL supports IPv6 since very early versions [0]; LispWorks supports IPv6 since version 6.1 [1], IPv4 UDP support is provided by USOCKET. CLISP doesn’t support IPv6, neither the socket streams API [2] nor rawsock API [3]; CMUCL doesn’t support IPv6; Scieneer CL (SCL) doesn’t support IPv6 [4], the platform and its networking API is totally derived from CMUCL; SBCL doesn’t support IPv6; ECL doesn’t support IPv6, but its networking support is based on SB-BSD-SOCKETS interface, can be done with SBCL together. Clozure CL (CCL) doesn’t support IPv6 [5]; Armed Bear Common Lisp (ABCL) doesn’t support IPv6, and its whole IPv4 support is provided by USOCKET. Macintosh Common Lisp (MCL) as a dead platform, not to mention, it doesn’t support IPv6 and even doesn’t support Mac OS X 10.7+. ^_^ MOCL, the new iOS CL platform, no access to it, but I think they don’t support IPv6.
Basically, that’s not a shame for SBCL/CCL at all. Among all CL platforms in this world, only Allegro CL and the current latest version of LispWorks (6.1) support IPv6. And technically speaking, the only bottleneck (toward IPv6) in these platforms, is to not treat IP address as a 32-bit integer any more, instead, a 128-bit black-box structure (like what’s done in LispWorks 6.1, structure 'COMM:IPv6-Address) should be accepted by all networking APIs.
Hope this helps,
Chun
[0] http://franz.com/support/documentation/9.0/doc/socket.htm#socket-ipv6-1 [1] http://www.lispworks.com/documentation/lw61/RNIG/html/readme-393.htm#pgfId-9... [2] http://clisp.podval.org/impnotes/socket.html [3] http://clisp.podval.org/impnotes/rawsock.html [4] http://www.scieneer.com/scl/doc/sockets.html [5] http://ccl.clozure.com/ccl-documentation.html#Sockets-Overview
Il giorno 18/set/2014, alle ore 14:21, Hans Hübner hans.huebner@gmail.com ha scritto:
Hi Chun,
thank you for getting back, and no worries: Studying should be great and maybe you'll have some time to return to open source work in the future.
I will be moving usocket's main repository to github as soon as I'm finished with IPv6 support in Clozure CL. I will let y'all know when that has finished.
Personally, I will not be maintaining patches to add IPv6 support to older lisp implementations. We should be able to get native support into the current versions of CCL and SBCL, and it will probably also be possible to support Allegro CL and Lispworks, although that is lower on my priority list. If you or anyone else want to maintain IPv6 patches to older compilers, I'd not be opposed as long as that does not put a burden onto people who use the current versions with native support. It will make sense to wait until we have something for the current versions so that the changes made for that can be used as model or be back ported.
I'll keep you updated on the progress.
-Hans
2014-09-18 13:59 GMT+02:00 Chun Tian (binghe) binghe.lisp@gmail.com: Hi Hans,
Beside other questions, I agree to move USOCKET development to Git. However my exist knowledge to Git cannot do such migration in short time, I hope you can do this for USOCKET, as you’re a maintainer of USOCKET too. (But please don’t put the Git repository on common-lisp.net servers, I think it’s not quite stable. I prefer SourceForge or Github. Once the new Git repository is set up, we’ll do rest of the work on Git instead of SVN.
I’m very sorry that I was not active in the past year. One reason is that I’m keep working for Gensym Corporation to maintain & develop the next version of their flagship Lisp-based product, Gensym G2, and the work is extremely busy. The other reason is that I’m trying to go back to college again for further study, and now I’m in Italy, will shortly be a student of University of Bologna.
For the IPv6 plan, pushing SBCL & CCL community to add the feature is easier for USOCKET and better for future maintenance. On the other side, providing fully loadable IPv6 patches by ourself is hard but provided the possibility to let users on old SBCL/CCL versions directly benefit from IPv6. I’m not sure which approach is the best, but fortunately these approaches are not conflict with each other (so, choosing which plans totally depends on the progress of each). For example, one major commercial CL platform is going to support UDP natively, thus all the UDP loadable patches provided by USOCKET will be obsoleted, but these code will not be removed as they still provide the possibility for users on old versions of that platform to use UDP. (upgrading a commercial platform needs money, upgrading a free platform needs courage, that’s at the same level from my view).
Regards,
Chun Tian (binghe)
Il giorno 17/set/2014, alle ore 10:08, Hans Hübner hans.huebner@gmail.com ha scritto:
I did some more research to find that nothing has moved in terms of implementation support for IPv6 (in SBCL and CCL, fwiw). I think this should change, in particular as the required changes to sb-bsd-sockets and l1-sockets.lisp are rather small, and it is very embarrassing that the two most popular open source CL implementations still ignore IPv6.
I'm going to come up with a more complete IPv6 update to sb-bsd-sockets in the next few days and try to get it merged into SBCL.
From looking at http://sourceforge.net/p/sbcl/mailman/sbcl-devel/thread/4E820C9E-33E2-43B2-B..., I see that there has been some work on USOCKET to support IPv6. Has that gone anywhere yet?
Finally, would you consider moving USOCKET development to git? GitHub makes collaboration so much easier.
Cheers, Hans
2014-09-17 9:36 GMT+02:00 Hans Hübner hans.huebner@gmail.com: Hi Chun,
this discussion thread has kind of ended in nothing and I'm now returning to find out how IPv6 support can be added to Hunchentoot and Drakma. A few options are on the table:
- Make USOCKET support IPv6
- Create IOLib backend for USOCKET
- Add Implementation specific code to Drakma and Hunchentoot
I have given up on the IOLib idea, basically because it uses a shared library that cannot be built using quicklisp.
What is the status of IPv6 support in USOCKET? Is there any hope to see it happen?
Thanks, Hans
2013-06-25 15:12 GMT+02:00 Ryan Davis ryan@acceleration.net: We have a similar problem with CLSQL; one API with multiple database backends. CLSQL's backend choice is a little different; the backend choice is a user-facing decision whereas usocket choosing iolib is an internal matter, but I thought I'd offer our approach.
We solve it in two ways: an ASD files for each backend: clsql-mysql, clsql-sqlite3, etc. (akin to the proposed usocket-iolib) a generic ASD file that tries to dynamically load more backends on request; if we try to connect to a :sqlite3 database, the connect function checks to see if clsql-sqlite3 is loaded, and if not, issues the load on the spot - see https://github.com/UnwashedMeme/clsql/blob/master/sql/database.lisp#L99 So library users can specify which backend they want via a direct dependency via ASDF, or let the environment take care of it. It's not the cleanest solution in the world and has some restrictions, but it's worked pretty well.
Thanks,
Ryan Davis Director of Programming, Acceleration.net 2837 NW 41st Street, Unit 320 Gainesville, FL 32606 352-335-6500 x124 http://www.acceleration.net On 06/24/2013 06:27 AM, Chun Tian (binghe) wrote:
Hi Anton
On 24/giu/2013, at 18:10, Anton Vodonosov avodonosov@yandex.ru wrote:
To solve all related issue, I'm going to do some runtime detection on *features*: if last compile time usocket was compiled with or without :usocket-iolib but current load time the feature set is different, ASDF should re-compile all usocket source files instead, not just load previous FASLs. (I'm not sure if ASDF have already provided such a feature, so let me also copy this mail to Faré, the ASDF maintainer)
I don't like the idea of creating a whole new ASDF system like "usocket-iolib", because that will require other packages to change their system definitions to benefit from this new work. And the most important thing, whether to depend on IOlib is totally an internal fair of usocket: it doesn't change the programming interface at all. And the choice on if user want to use native network support of IOlib-based network support on their current platforms, ONLY depends on if they like to load additional DLLs (by CFFI). I always want usocket to depend on nothing, so that we can easily patch those 24x7 lisp servers to upgrade the networking support smoothly.
I agree that the usocket clients (application and other libraries) should work via the API and do not depend on particular implementation. What I suggest is to make the implementation switchable at runtime, instead of compile time. I think the solution will be simpler and more flexible solution. Up the the level that we can have at the same time in the same lisp image both IOlib sockets and sockets based on the API provided by the Lisp implementation.
It's possible to implement the runtime switches, and I admit this is a good idea when IOlib is being depended by usocket. Now I think it's also possible to provide a standalone, new ASDF system "usocket-iolib", which *explicitly* make sure IOlib is used as backend. But all my previous ideas should still work, there's no conflicts I can see.
Best regards,
- Anton