- usocket-devel - mailman3.common-lisp.net

[usocket-devel] patch: adding *remote-host* *remote-port* to socket-server stream handler functions
by Matthew Curry 11 Nov '11

11 Nov '11

Hi all: I had a need to know the remote socket and port for a tcp connection, however the socket-server handler function did not have *remote-host* and *remote-port* set (oddly it does set these for datagram sockets). socket-server is mostly what I want, save this feature, which I have modified the sources locally. If it's alright with the devs, could this simple patch be committed to the server.lisp file in the usocket tree? Thanks, -Matt

2 1

[usocket-devel] [ANNOUNCE] usocket 0.5.4
by Chun Tian (binghe) 01 Oct '11

01 Oct '11

Hi, Common Lispers This is a new cumulative update release for USOCKET, version 0.5.4 Changes in this version: * Bugfix: [ECL] Fixed for ECL's MAKE-BUILD by removing some unecessary code (reported by Juan Jose Garcia-Ripoll, the ECL maintainer) * Bugfix: [ACL] Fixed for Allegro CL modern mode. (by Hans Hübner) * Bugfix: [SBCL] SOCKET-CONNECT on TCP won't call bind() when keyword arguments LOCAL-HOST and LOCAL-PORT is not set. (reported by Robert Brown) Special thanks (again) to: Robert Brown <robert.brown(a)gmail.com> for his reporting and patching on a big bug in SBCL's SOCKET-CONNECT function, which have unnecessary bind() calls previously. If you want to download this release, please checkout http://common-lisp.net/project/usocket/releases/ or just wait for new Quicklisp releases. The API documentation page is still here: http://common-lisp.net/project/usocket/api-docs.shtml As usual, any feedback - bugs or hugs - is greatly appreciated, Regards, Chun Tian (binghe) Glority Software Ltd. P.S. What's next in USOCKET? I think it's a enhanced ECL backend which works in its byte-compiler-only mode. I think this means all inlined C code should be replaced by FFI code, just like what I've done in LW and CLISP backends. I'll learn how to do it right from ASDF.

2 1

[usocket-devel] bug in backend/sbcl.lisp ?
by Robert Brown 01 Oct '11

01 Oct '11

I think the socket-connect function in the SBCL backend is incorrectly calling bind when creating a client stream socket. With the current code, when I create a lot of client stream sockets on a Linux system, the bind call in socket-connect eventually returns an error, address already in use. I don't think the bind call is needed for the client end of stream sockets. The following patch appears to fix the problem for me. bob --- backend/sbcl.lisp.~1~ 2011-09-23 13:46:55.071765010 -0400 +++ backend/sbcl.lisp 2011-09-23 13:51:33.841811680 -0400 @@ -269,9 +269,8 @@ :protocol (case protocol (:stream :tcp) (:datagram :udp)))) - (local-host (host-to-vector-quad (or local-host *wildcard-host*))) - (local-port (or local-port *auto-port*)) - usocket ok) + (usocket nil) + (ok nil)) (unwind-protect (progn (ecase protocol @@ -284,8 +283,6 @@ ;; to pass compilation on ECL without it. (when (and nodelay-specified sockopt-tcp-nodelay-p) (setf (sb-bsd-sockets::sockopt-tcp-nodelay socket) nodelay)) - (when (or local-host local-port) - (sb-bsd-sockets:socket-bind socket local-host local-port)) (with-mapped-conditions (usocket) #+(and sbcl (not win32)) (labels ((connect ()

3 3

[usocket-devel] Usocket and ECL's MAKE-BUILD
by Juan Jose Garcia-Ripoll 27 Aug '11

27 Aug '11

There are various things in how the usocket library is packaged that prevent it from being used in standalone programs with ECL. I summarize them - A package usocket-system is defined and used in package.lisp. This package is not needed, as ASDF provides it and when the executable is created it does not exist. - Standalone executables do not have ASDF in it. There is no need. Yet usocket uses it to define a logical hostname which is never used. - The references to usocket-system propagate to usocket-test. I attach a patch against the version that quicklisp distributes. With this patch usocket builds as an independent library without problems and can be shipped in standalone executables as well. Juano -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

2 1

[usocket-devel] [ANNOUNCE] usocket 0.5.3
by Chun Tian (binghe) 16 Aug '11

16 Aug '11

Hello people, This is a cumulative update for USOCKET, version 0.5.3 Changes: * Bugfix: [MCL] Fixed SOCKET-LISTEN on vector addresses like #(0 0 0 0) * Bugfix: [MCL] Fixed WAIT-FOR-INPUT on passive sockets (stream-server-usocket) * Bugfix: [LispWorks] Fixed using UDP in delivered applications (thanks to Camille Troillard and Martin Simmons, this is from the legacy LispWorks-UDP project). * Bugfix: [SBCL] Fixed for "SBCL data flush problem", reported by Robert Brown and confirmed by Nikodemus Siivola. Special thanks to: Robert Brown <robert.brown(a)gmail.com> for his reporting and patching on "SBCL data flush problem". If you want to download this release, please checkout http://common-lisp.net/project/usocket/releases/ or just wait for new Quicklisp releases. The API documentation page is still here: http://common-lisp.net/project/usocket/api-docs.shtml Any feedback - bugs or hugs - is greatly appreciated. P.S. Now I have a full-time Lisp job in China:) Regards, Chun Tian (binghe)

2 1

[usocket-devel] SBCL data flush problem
by Robert Brown 08 Aug '11

08 Aug '11

I use SBCL on Linux and have noticed a problem when writing lots of data to socket streams created with usocket. In file backend/sbcl.lisp, the function socket-connect creates a stream as follows: (setf (socket-stream usocket) (sb-bsd-sockets:socket-make-stream socket :input t :output t :buffering :full :element-type element-type)) If you look at the code for sb-bsd-sockets:socket-make-stream in sbcl/contrib/sb-bsd-sockets/sockets.lisp, you'll see that it specifies a default value of T for the keyword argument serve-events: (defmethod socket-make-stream ((socket socket) &key input output (element-type 'character) (buffering :full) (external-format :default) timeout auto-close (serve-events t)) This means that SBCL streams created by usocket have a true serve-events property. When writing large amounts of data to several streams, the kernel will eventually stop accepting data from SBCL. When this happens, SBCL either waits for I/O to be possible on the file descriptor it's writing to or queues the data to be flushed later. Because usocket streams specify serve-events as true, SBCL always queues. Instead, it should wait for I/O to be available and write the remaining data to the socket. That's what serve-events equal to NIL gets you. Usocket should add :serve-events NIL to the call to socket-make-stream. bob

2 1

[usocket-devel] [ANNOUNCE] usocket 0.5.2
by Chun Tian (binghe) 11 May '11

11 May '11

Hello everyone, I'm pleased to release USOCKET 0.5.2, a new version of the universal socket library for Common Lisp. In this release, the core API function WAIT-FOR-INPUT was much improved on SBCL, ECL, CLISP; there're some other fixes for ABCL and LispWorks. I heard, with this release, Hunchentoot can run on ABCL now. Major changes since 0.5.1: * General: [SBCL] SOCKET-CONNECT's TIMEOUT argument was limited on non-Windows platforms. * Bugfix: [CLISP] WAIT-FOR-INPUT now functions right (with/without READY-ONLY), this made Hunchentoot working on CLISP. (Thanks to Anton Vodonosov <avodonosov(a)yandex.ru>) * Bugfix: [ABCL] Fix SOCKET-ACCEPT to follow the documented API so that when called without an :ELEMENT-TYPE argument. (Thanks to Mark Evenson, the ABCL developer) * Bugfix: [LispWorks] Fixed SOCKET-ACCEPT (Windows only) on WAIT-FOR-INPUTed sockets. * Bugfix: [SBCL, ECL] Fixed wrongly STATE set/unset for WAIT-FOR-INPUT on Windows (report by Elliott Slaughter) * Enhancement: Additional NAME keyword argument for SOCKET-SERVER for setting the server thread name. * Enhancement: [ABCL] GET-ADDRESS now works with underlying IP6 addresses. * Enhancement: [CLISP] missing GET-LOCAL-* methods for STREAM-SERVER-USOCKET was now added. We give special thanks to: Elliott Slaughter <elliottslaughter(a)gmail.com> for his two bug reports on WAIT-FOR-INPUT (SBCL/Windows) with unit test code, and these code are now part of USOCKET-TEST. If you want to download this release, please checkout http://common-lisp.net/project/usocket/releases/ The API documentation page is here: http://common-lisp.net/project/usocket/api-docs.shtml As usual, I hope more and more people use USOCKET as part of their Lisp applications, and any feedback - bugs or hugs - is greatly appreciated. If you use USOCKET, please let us know what for. And, if there's any historical issue which haven't been solved, please feel free to remind me. And below is a roadmap for future USOCKET releases (ignore the order): * Add UDP (Datagram) support for Digitool MCL; * The DFFI version of ECL backend without calling C compilers; * New backends: Symbolics Lisp Machine, XCL and IOlib; * New API: SOCKET-OPTION for setting/getting various socket options (already exist in trunk (0.6)) Let me know if you have other ideas. Regards, Chun Tian (binghe)

1 0

[usocket-devel] How to tell size of data waiting in a TCP socket?
by Elliott Slaughter 10 May '11

10 May '11

Hi, I'm wondering if there is a good way to figure out how much data is available on a socket. Right now I have a situation where my program accepts messages over a TCP socket. To check to see if a single message is available, I can just call wait-for-input with :timeout 0. But in order to check for multiple messages on a single socket, I need multiple calls to wait-for-input. So something like (iter (for ready next (wait-for-input socket :timeout 0)) (while (read-message socket))) I'm avoiding multithreading to preserve compatibility with Lisps that don't support (or have unstable support for) threads. The above works on most implementations, but breaks on SBCL/Windows, where subsequent calls to wait-for-input appear to block, despite the :timeout 0 parameter. There may very well be a bug in the SBCL/Windows implementation in usocket to chase down here. Alternatively, is there a better way to do the above (assuming that multithread is unavailable in the implementation I want to run this on)? Thanks. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

2 4

[usocket-devel] SBCL wait-for-input bug on attempt at second connection
by Elliott Slaughter 01 May '11

01 May '11

First, the documentation for wait-for-input says that only integer are accepted, but code seems to think reals should work. (Tested on SBCL/Windows.) Second, I have found a bug in wait-for-input in SBCL on Windows. The problem is that a wait-for-input on a TCP server socket which has already accepted one client will continue to return that the socket is ready to accept more clients even though it isn't, and thus cause an error when I try to call socket-accept. Here is the code that breaks it: (defvar *port* 12345) (defvar *socket-server-listen* (socket-listen *wildcard-host* *port* :element-type '(unsigned-byte 8))) (defvar *socket-server-connection*) (setf *socket-server-connection* (when (wait-for-input *socket-server-listen* :timeout 0 :ready-only t) (socket-accept *socket-server-listen*))) (format t "First time (before client connects) is ~s.~%" *socket-server-connection*) (defvar *socket-client-connection*) (setf *socket-client-connection* (socket-connect "localhost" *port* :protocol :stream :element-type '(unsigned-byte 8) :timeout 0)) (setf *socket-server-connection* (when (wait-for-input *socket-server-listen* :timeout 0 :ready-only t) (socket-accept *socket-server-listen*))) (format t "Second time (after client connects) is ~s.~%" *socket-server-connection*) (setf *socket-server-connection* (when (wait-for-input *socket-server-listen* :timeout 0 :ready-only t) (socket-accept *socket-server-listen*))) (format t "Third time (before second client) is ~s.~%" *socket-server-connection*) The output on Windows/SBCL looks like: First time (before client connects) is NIL. Second time (after client connects) is #<STREAM-USOCKET {24757F91}>. It doesn't get to the first format call, because it hits the following error first: Condition BAD-FILE-DESCRIPTOR-ERROR was signalled. [Condition of type BAD-FILE-DESCRIPTOR-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [ABORT] Return to SLIME's top level. 2: [ABORT] Abort 3: [CLOSE-CONNECTION] Close SLIME connection 4: [ABORT] Exit debugger, returning to top level. Backtrace: 0: (USOCKET::HANDLE-CONDITION #<SB-BSD-SOCKETS:SOCKET-ERROR {2475C889}> #<STREAM-SERVER-USOCKET {256F7C19}>) 1: (SIGNAL #<SB-BSD-SOCKETS:SOCKET-ERROR {2475C889}>) 2: (ERROR SB-BSD-SOCKETS:SOCKET-ERROR :ERRNO 9 :SYSCALL "accept") 3: (SB-BSD-SOCKETS:SOCKET-ERROR "accept") 4: ((SB-PCL::FAST-METHOD SB-BSD-SOCKETS:SOCKET-ACCEPT (SB-BSD-SOCKETS:SOCKET)) #<unavailable argument> #<unavailable argument> #<SB-BSD-SOCKETS:INET-SOCKET 0.0.0.0:12345, fd: 6 {2576DD91}>) 5: ((SB-PCL::FAST-METHOD SOCKET-ACCEPT (STREAM-SERVER-USOCKET)) #<unused argument> #<unused argument> #<STREAM-SERVER-USOCKET {256F7C19}> :ELEMENT-TYPE NIL) 6: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SOCKET-ACCEPT *SOCKET-SERVER-LISTEN*) #<NULL-LEXENV>) 7: (SB-INT:SIMPLE-EVAL-IN-LEXENV (PROGN (SOCKET-ACCEPT *SOCKET-SERVER-LISTEN*)) #<NULL-LEXENV>) 8: (SB-INT:SIMPLE-EVAL-IN-LEXENV (WHEN (WAIT-FOR-INPUT *SOCKET-SERVER-LISTEN* :TIMEOUT 0 :READY-ONLY T) (SOCKET-ACCEPT *SOCKET-SERVER-LISTEN*)) #<NULL-LEXENV>) 9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (SETF *SOCKET-SERVER-CONNECTION* (WHEN # #)) #<NULL-LEXENV>) -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

2 5

[usocket-devel] Patch for ABCL for IP6 and SOCKET-ACCEPT
by Mark Evenson 29 Apr '11

29 Apr '11

The attached patch against usocket HEAD (basically usocket-0.5.1) address for following for ABCL: 1. GET-ADDRESS now works with underlying IP6 addresses 2. Fix SOCKET-ACCEPT to follow the documented API so that when called without an :ELEMENT-TYPE argument, use the ELEMENT-TYPE of specified in the corresponding call to SOCKET-LISTEN. With the [corresponding patches][1] this allows ABCL to run Hunchentoot. [1]: http://detroit.slack.net/~evenson/abcl/hunchentoot -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1