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

[usocket-devel] "experimental-udp" branch merged into usocket trunk
by Chun Tian (binghe) 14 Jan '10

14 Jan '10

Hi, usocket users I want to mention, the "experimental-udp" branch has been merged into usocket trunk. Changed API: [SOCKET-CONNECT] SOCKET-CONNECT now has a new keyword argument PROTOCOL with default :STREAM as tcp, but if you set it to :DATAGRAM, this means you're creating a UDP socket. Be different with TCP socket, a UDP socket can be connected or unconnected. The method to create a unconnected UDP socket is to leave the first two argument of SOCKET-CONNECT as NIL: (SOCKET-CONNECT NIL NIL :PROTOCOL :DATAGRAM) Creating a server UDP socket which "listen" on local address is also supported, the method is to set additional keyword arguments: LOCAL-HOST and LOCAL-PORT: (SOCKET-CONNECT NIL NIL :PROTOCOL :DATAGRAM :LOCAL-HOST nil :LOCAL-PORT 10000) Notice: the "nil" as LOCAL-HOST means that you listen on wildcard address "0.0.0.0", same effect as *wildcard-host*. [SOCKET-SEND] Syntax: SOCKET-SEND usocket buffer length &key host port SOCKET-SEND is used for sending packets through a UDP usocket, the "buffer" arguments usually need to be a vector of (unsigned-byte 8). [SOCKET-RECEIVE] Syntax: SOCKET-RECEIVE usocket buffer length &key SOCKET-RECEIVE is used for receiving packets from a UDP usocket, the "buffer" argument will be filled into received data, but if you give NIL, this function will create a new buffer object for holding received data, the default buffer length will be 65536 which defined as a constant +max-datagram-packet-size+. Notice: if you use this function to receive data from a unconnected socket, you may need to know where the data from. Actually, SOCKET-RECEIVE will return multiple values, the exact number is 4: 1. buffer (the same object as the "buffer" argument if it's not NIL when calling SOCKET-RECEIVE) 2. size (how many bytes received) 3. host (which address this data from) 4. port (which IP port this data from) [SOCKET-SERVER] Syntax: SOCKET-SERVER host port function &optional arguments &key (timeout 1) (max-buffer-size +max-datagram-packet-size+) SOCKET-SERVER can create a simple single-threaded UDP server. This function is a indefinite loop, so you should create it in a new created thread using your platform's thread API. The arguments "function" and "arguments" controls your UDP server's function, declaration of this function: function (data &optional arguments) This function will work like a filter, received data in, and return data send out. For example, a UDP Echo server can be defined in following code: (defun echo-function (data) data) And following code created this server on local port 10000: (socket-server nil 10000 #'echo-function) What if your filter function need to know where the data from? Get this information from two special variables: *REMOTE-HOST* and *REMOTE-PORT*. The argument "timeout" can control the loop frequency, usually no need to modify. Read "server.lisp" for details. The last important thing USOCKET user need to know: UDP support haven't been done on all CL platforms. Current finished supported CL platforms: * CMUCL * SBCL and ECL (not on win32) * Allegro CL * LispWorks (not on win32) * SCL * Clozure CL Unfinished CL platforms: * CLISP * Armedbear Common Lisp (ABCL) * Macintosh Common Lisp (MCL/RMCL) And the USOCKET-UDP [1] project will be just closed. The function SOCKET-SYNC in that project will not be merged into USOCKET trunk because of less useful in most cases. Bug reports, optimization suggestions, patches on unfinished platforms are all welcome. Thank you for using USOCKET project. Regards, Chun Tian (binghe) [1] http://common-lisp.net/projects/cl-net-snmp/usocket.html

2 6

[usocket-devel] wait-for-input support on SBCL/Windows
by Elliott Slaughter 13 Jan '10

13 Jan '10

Hi, I noticed while reading sbcl.lisp that wait-for-input is not yet implemented on Windows. I'm wondering whether anyone is working on this and/or what it would take to get this working. 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 1

[usocket-devel] nameserver errors on Clozure CL
by R. Matthew Emerson 13 Jan '10

13 Jan '10

Some recent changes to the Clozure CL trunk (starting with http://trac.clozure.com/ccl/changeset/13377) try to report nameserver errors in the socket-creation-error condition object. Something like the crude attached patch would update the Clozure CL usocket backend to report these nameserver errors.

2 4

[usocket-devel] BUG: dangling references to split-sequence package
by Andy Chambers 13 Jan '10

13 Jan '10

There is a dangling reference to split-sequence but split-sequence itself is no longer marked as a dependency in the defsystem spec. This means that usocket cannot currently be loaded using asdf unless split-sequence has already been loaded by some other system. The attached patch just replaces calls to split-sequence:split-sequence with corresponding calls to cl-utilities:split-sequence. Also I think a few of the tests might need to be rewritten. Both before and after applying this patch, 6 out of 15 tests fail for me. Regards, Andy Chambers (format t "type: ~a version: ~a" (lisp-implementation-type) (lisp-implementation-version)) type: SBCL version: 1.0.18.debian (usocket-test:run-usocket-tests) Doing 15 pending tests of 15 tests total. USOCKET-TEST::MAKE-SOCKET.1 USOCKET-TEST::MAKE-SOCKET.2 #<USOCKET:UNSUPPORTED {B075EB9}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-NO-CONNECT.1 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:SOCKET-ERROR NIL) (USOCKET:SOCKET-CONNECT "127.0.0.0" USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) T) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B075EB9}>. #<USOCKET:UNSUPPORTED {B20A2B1}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-NO-CONNECT.2 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:SOCKET-ERROR NIL) (USOCKET:SOCKET-CONNECT #(127 0 0 0) USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) T) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B20A2B1}>. #<USOCKET:UNSUPPORTED {B3A5D81}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-NO-CONNECT.3 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:SOCKET-ERROR NIL) (USOCKET:SOCKET-CONNECT 2130706432 USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) T) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B3A5D81}>. #<USOCKET:UNSUPPORTED {B5461D9}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-FAILURE.1 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:NETWORK-UNREACHABLE-ERROR NIL) (USOCKET:SOCKET-CONNECT 2130706432 USOCKET-TEST::+UNUSED-LOCAL-PORT+ :TIMEOUT 0) :UNREACH) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B5461D9}>. #<USOCKET:UNSUPPORTED {B9C8229}> is a USOCKET:UNSUPPORTED. Its slot values are (:FEATURE USOCKET::TIMEOUT :CONTEXT USOCKET:SOCKET-CONNECT :MINIMUM NIL). Test USOCKET-TEST::SOCKET-FAILURE.2 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS ('USOCKET:HOST-UNREACHABLE-ERROR NIL) (USOCKET:SOCKET-CONNECT USOCKET-TEST::+NON-EXISTING-HOST+ 80 :TIMEOUT 0) :UNREACH) Expected value: NIL Actual value: #<USOCKET:UNSUPPORTED {B9C8229}>. USOCKET-TEST::SOCKET-CONNECT.1 USOCKET-TEST::SOCKET-CONNECT.2 USOCKET-TEST::SOCKET-CONNECT.3 USOCKET-TEST::SOCKET-STREAM.1 USOCKET-TEST::SOCKET-NAME.1 USOCKET-TEST::SOCKET-NAME.2 USOCKET-TEST::SOCKET-NAME.3 Test USOCKET-TEST::SOCKET-NAME.4 failed Form: (USOCKET-TEST::WITH-CAUGHT-CONDITIONS (NIL NIL) (LET ((USOCKET-TEST::SOCK (USOCKET:SOCKET-CONNECT USOCKET-TEST::+COMMON-LISP-NET+ 80))) (UNWIND-PROTECT (USOCKET:GET-LOCAL-ADDRESS USOCKET-TEST::SOCK) (USOCKET:SOCKET-CLOSE USOCKET-TEST::SOCK)))) Expected value: #(192 168 1 25) Actual value: #(192 168 0 3). 6 out of 15 total tests failed: USOCKET-TEST::SOCKET-NO-CONNECT.1, USOCKET-TEST::SOCKET-NO-CONNECT.2, USOCKET-TEST::SOCKET-NO-CONNECT.3, USOCKET-TEST::SOCKET-FAILURE.1, USOCKET-TEST::SOCKET-FAILURE.2, USOCKET-TEST::SOCKET-NAME.4. NIL CL-USER> -- ---- Andy Chambers Formedix Ltd

2 1

[usocket-devel] cl-utilities dependency
by Attila Lendvai 12 Jan '10

12 Jan '10

hi, any reason not depending on alexandria instead? cl-utilities with its split-sequence is a headache: it has a s-s but not a .asd file, so i can not drop the repo-less s-s in favor of cl-utilities. but if i keep them both, then it brainlessly redefines, which stops the build... -- attila

1 0

Re: [usocket-devel] [drakma-devel] Drakma - problem with http-request on SBCL 1.0.34
by Erik Huelsmann 08 Jan '10

08 Jan '10

Did we (usocket developers) miss a function argument? Chun, shouldn't we at least accept it? Bye, Erik. On Thu, Jan 7, 2010 at 9:33 PM, Fred Gibson <fred(a)streamfocus.com> wrote: > I've found a small problem in Drakma's http-request where in a call to > usocket:socket-connect it sent the key :nodelay which doesn't exist > for sbcl's socket connect version, so I changed that call in drakma to > this: > > (usocket:socket-stream > (usocket:socket-connect host port > :element-type 'octet > #+:openmcl :deadline > #+:openmcl deadline > #-:sbcl :nodelay > #-:sbcl t)) > > Then it seemed to work just fine. > > My best, > > Fred Gibson > > Founder / Software Developer > http://www.streamfocus.com > > (c)2010 Organon Technologies LLC > > _______________________________________________ > drakma-devel mailing list > drakma-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/drakma-devel >

3 4

Re: [usocket-devel] Multiprocess MCL usocket
by Chun Tian (binghe) 07 Jan '10

07 Jan '10

Committed as r514. Thanks very much. Your idea on using a lock is also useful for some other CLs, I think. --binghe 在 2010-1-7，01:13， Terje Norderhaug 写道： > Binghe, > > Below is an upgrade to the usocket MCL backend that allows a socket server to be shared between multiple processes. It adds a lock so only one process at a time polls for an established connection for the socket. > > (defclass passive-socket (socket) > ((streams :accessor socket-streams :type list :initform NIL > :documentation "Circular list of streams with first element the next to open") > (reuse-address :reader reuse-address :initarg :reuse-address) > (lock :reader socket-lock :initform (ccl:make-lock "Socket")))) > > (defmethod socket-accept ((socket passive-socket) &key element-type &aux (lock (socket-lock socket))) > (flet ((connection-established-p (stream) > (ccl::with-io-buffer-locked ((ccl::stream-io-buffer stream nil)) > (let ((state (ccl::opentransport-stream-connection-state stream))) > (not (eq :unbnd state)))))) > (with-mapped-conditions () > (ccl:with-lock-grabbed (lock nil "Socket Lock") > (let ((connection (shiftf (car (socket-streams socket)) > (socket-open-listener socket element-type)))) > (pop (socket-streams socket)) > (ccl:process-wait "Accepting" #'connection-established-p connection) > connection))))) > > > -- Terje Norderhaug > terje(a)in-progress.com > > > >

1 0

[usocket-devel] patches for usocket mcl backend and tests
by james anderson 06 Jan '10

06 Jan '10

good evening; please find attached patches for the mcl back-end and the tests. the system names follow from the local conventions for asdf systems, but the other changes should be generally useful. given these changes mcl 5.2 passes all 15. i cross-checked with openmcl ("Version 1.3-r11936 (DarwinPPC32)") which succeded as well. * test/test-usocket.lisp : added timeout arguments to the no-connect tests, as both mcl and openmcl otherwise hang : added mcl to the caught conditions for failure tests : wrapped typep tests to force t/nil : corrected #\newline to be #\linefeed : added a +local-ip+ variable * test/usocket-test.asd : changed dependencies to be fully qualified * usocket.asd : modified dependency to use cl-utilities (by fully qualified system name) * backend/mcl.lisp : handle-condition : corrected to formulate the error argument as required for the respective error class : socket-connect : reinstated with-mapped-conditions : socket-listen : reinstated with-mapped-conditions : socket-accept : reinstated with-mapped-conditions : %*-wait operators : added no-op versions

3 4

[usocket-devel] r507 : open-mcl : socket-connect scales the timeout value incorrectly
by james anderson 03 Jan '10

03 Jan '10

good evening; in the openmcl backend, socket-connect[1] converts the timeout value to internal runtime units, but (at least for a tcp connection) the respective ccl operator[2] intends to convert from seconds to milliseconds ---- [1] http://trac.common-lisp.net/usocket/browser/usocket/trunk/backend/ openmcl.lisp?rev=499#L89 [2] http://trac.clozure.com/ccl/browser/trunk/source/level-1/l1- sockets.lisp#L774 socket-connect -> make-socket -> make-ip-socket -> make-tcp-socket -> make-tcp-stream-socket

2 1

Re: [usocket-devel] [info-mcl] USOCKET?
by Chun Tian (binghe) 03 Jan '10

03 Jan '10

Hi, > On Jan 2, 2010, at 11:42 PM, Chun Tian (binghe) wrote: >> Your file has been committed into USOCKET trunk [1], and I'll use it as my work base. What you didn't implement is the WAIT-FOR-INPUT-INTERNAL function, which used to detect if there's anything available to read in a group of sockets (it's based on select() on UNIX). I'll try to investigate how MCL do this job if you don't have a quick solution. > > It seems like WAIT-FOR-INPUT-INTERNAL is like the CONNECTION-ESTABLISHED-P local function within SOCKET-ACCEPT in the usocket MCL backend draft that I sent you? Or is it more like LISTEN in Common Lisp? It's more like LISTEN, but it can listen on multiple connections at the same time. So, do you have any idea on how to implement it? And please notice: the WAIT-FOR-INPUT-INTERNAL should wait on "socket" but "stream", because that's what USOCKET API defined. And, more important, having that function wait on "sockets" could make the function also fit into usage of UDP sockets which doesn't have correspond stream objects. > > One important detail is that the MCL OpenTransport module establishes connections for passive streams on a port in a FIFO manner. That is, the first passive stream stream created with (ccl::open-tcp-stream NIL ...) will be the first to be connected. Hence you only have to test the top queued passive tcp stream for whether it is an established connection rather than poll all the streams in the socket. > > -- Terje

1 0