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

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

11 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 02 May '11

02 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

[usocket-devel] wait-for-input fix for CLISP
by Anton Vodonosov 11 Apr '11

11 Apr '11

Hello. I am using usocket 0.5.0 and it has a bug for CLISP. In the function wait-for-input-internal there is a do* cycle which analyzes the result of the CLISP function socket-status (its docs are here: http://www.clisp.org/impnotes/socket.html#so-status) Here is how the cycle is written now: (do* ((x (pop sockets) (pop sockets)) (y (pop status-list) (pop status-list))) ((null x)) (when (eq y :INPUT) (setf (state x) :READ))) This cycle never recognizes that a server socket is ready to accept a connection. The fixed cycle (do* ((x (pop sockets) (pop sockets)) (y (cdr (pop status-list)) (cdr (pop status-list)))) ; <- fixed here ((null x)) (when (member y '(T :INPUT)) ; <- and here (setf (state x) :READ))) The first mistake was that the code expects socket-status to return a list of statuses, but it actually returns a list of cons cells, according to the doc: > If you want to avoid consing[3] up a fresh list, you can make the elements of > socket-stream-or-list to be (socket-stream direction . x) or (socket-server . x). > Then SOCKET:SOCKET-STATUS will destructively modify its argument and replace > x or NIL with the status and return the modified list. The second mistake is that socket-status specifies ready SOCKET-SERVER as T (and :INPUTS is for SOCKET-STREAM). As far as I understood usocket intention for the wait-for-input-internal function, we should check both. With these changes, I have hunchentoot 1.1.1 working with clisp 2.49. Best regards, - Anton

2 4

[usocket-devel] [ANNOUNCE] usocket 0.5.1
by Chun Tian 02 Apr '11

02 Apr '11

Hello everyone, With permission from Erik Huelsmann, I'm pleased to release USOCKET 0.5.1 The major point in this release is the availability of UDP protocol support on GNU CLISP, and we have implemented too versions: the FFI version and the RAWSOCK verion. The FFI version will be useful for those who cannot use RAWSOCK (i.e. default installation on MacOS/Fink and most Linux distributions) There're also some important fixes since the 0.5.0 release, especially for SBCL. Major changes since 0.5.0: * New feature: [CLISP] UDP (Datagram) support based on FFI (Win/Mac/Linux), no RAWSOCK needed. * Enhancement: SOCKET-SERVER return a second value (socket) when calling in new-thread mode. * Enhancement: [CLISP] Full support of DNS helper functions (GET-HOST-BY-NAME, ...) added. * Enhancement: [CLISP] Better network error type detection based on OS error code. * Enhancement: [LispWorks] Better network error type detection based on OS error code. * Bugfix: Fixed wrong macro expansions of {IP|PORT}-{FROM|TO}-OCTET-BUFFER functions (since 0.4.0) * Bugfix: SOCKET-CONNECT didn't set CONNECTED-P for datagram usockets on most backends. * Bugfix: [SBCL] Fixes for "SBCL/Win32: finalizer problem, etc", by Anton Kovalenko <anton(a)sw4me.com> * Bugfix: [SBCL] Fixed SOCKET-SERVER (UDP) on SBCL due to a issue in SOCKET-CONNECT when HOST is NIL. * Bugfix: [SBCL] SOCKET-CONNECT's TIMEOUT argument now works as a "connection timeout", thanks to Nikodemus Siivola. * Bugfix: [CMUCL] Fixed SOCKET-SEND on unconnected usockets under Unicode version of CMUCL. * Bugfix: [CLISP] Fixed and confirmed UDP (Datagram) support (RAWSOCK version). We special thanks to: Anton Kovalenko <anton(a)sw4me.com> for his professional fix on the issue "SBCL/Win32: finalizer problem, etc" [1]. If you want to download this release, please check out http://common-lisp.net/project/usocket/releases/ The API documentation page on the website is actually quite new: 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 backend: Symbolics Lisp Machine (because ASDF support it now); * New backend: XCL (is it ready?!); * New backend: IOlib; * New API: SOCKET-OPTION for setting/getting various socket options. Let me know if you have other ideas... Regards, Chun Tian (binghe) [1] http://article.gmane.org/gmane.lisp.usocket.devel/316

1 0