usocket-devel May 2015

usocket-devel@common-lisp.net

5 participants
7 discussions

Lispworks Windows UDP behaviour
by Frank James 27 May '15

27 May '15

I've been testing some UDP codes on Lispworks (personal 32bit Windows version) and have encountered some undocumented behaviour, I think it's a matter of opinion whether it's a bug or not but it should probably have a sentence or two documenting it somewhere. Basically I'm sending a UDP packet to a host and listening for a reply, using socket-send and socket-receive. If the host in question is not listening for UDP traffic on that particular port, the Windows socket API says it should return an ECONNRESET error immediately on the socket-receive call, this is indicated by a -1 return value from the underlying recvfrom call. When this happens the Lispworks backend code returns a length of -1 (and buffer nil). This is perfectly acceptable behaviour I think (although it'd be somewhat nicer to signal an error, but that's a matter of taste). But it should be documented that checking the length here is the correct way to detect an error occurred. Example code would be something like: (let ((sock (usocket:socket-connect "localhost" 1234 :protocol :datagram :element-type '(unsigned-byte 8)))) (unwind-protect (progn (usocket:socket-send sock (make-array 16 :element-type '(unsigned-byte 8) :initial-element 0) 16) (let ((buffer (make-array 16 :element-type '(unsigned-byte 8) :initial-element 0))) (usocket:socket-receive sock buffer 16))) (usocket:socket-close sock))) What is somewhat more annoying is that the socket object remains in a :READ state. This means that a polling loop using wait-for-input spins continuously, with each socket-receive returning -1 (as explained above). Probably the socket state should be cleared if a socket-receive fails. Apologies if this is all well-known to those reading this list, but it caused me 10 minutes of head scratching earlier today and thought it was worth mentioning. Frank.

2 7

[ANN] usocket 0.6.3
by Chun Tian (binghe) 23 May '15

23 May '15

Dear Lispers, We’re glad to announce the usocket 0.6.3, a small patch release after 0.6.2 (April 2015). Changes in this release: * Bugfix: [CCL] Further fixed CCL-1.11 compatibility and a typo in SOCKET-CONNECT for old CCL versions. * Bugfix: [ECL] Fixed build in some versions. * Bugfix: [LispWorks] SOCKET-SEND and SOCKET-RECEIVE now throw conditions if something goes wrong. Also, IPv6 is partial supported in SBCL (1.2.5+) and CCL (1.11), now we’re working on more platforms, especially LispWorks and Allegro CL. Special thanks to Mark H. David, Frank James and other people who provided valuable bug reports, test cases and suggestions. As usual, if you want to download this release, please check http://common-lisp.net/project/usocket/releases/ or just wait for next Quicklisp monthly dist updates. The API documentation page was here: http://common-lisp.net/project/usocket/api-docs.shtml Any feedback - bugs or hugs - is greatly appreciated. Anyone is welcome to send pull request to our Git [1]: https://github.com/usocket/usocket.git Regards, Chun Tian (binghe) USOCKET Team

1 0

Re: [Usocket-devel] use of unexported symbols in backend/openmcl.lisp
by Chun Tian (binghe) 22 May '15

22 May '15

Hi, Today I have modified USOCKET to depend on this new :IPv6 feature. And now I’ve created a new backend file “clozure.lisp” [1] for holding all functions specific to CCL-1.11, I think this is many people wanted for years. The old backend file “openmcl.lisp” is not only for old CCL versions, but new backend is only for new CCL versions. P. S. I’m preparing a new release 0.6.3 for all recent changes. Regards, Chun [1] https://github.com/usocket/usocket/commit/059d9747c62ac92a525de955d5fb7441d… Il giorno 20/dic/2014, alle ore 04:49, R. Matthew Emerson <rme(a)clozure.com> ha scritto: > >> On Dec 19, 2014, at 3:40 AM, Hans Hübner <hans.huebner(a)gmail.com> wrote: >> >> Hi Chun, >> >> Matthew said that he intends to add an IPv6 *feature* to CCL, which might be even more appropriate. Matthew, did you decide on the feature keyword yet? > > I decided to put :ipv6 on *features* (which is also what Allegro CL uses). >

1 0

Re: [Openmcl-devel] bug with usocket and/or trunk ccl - "error #22"
by Chun Tian (binghe) 20 May '15

20 May '15

Issue fixed, problem is in usocket (of course). The created server socket is IPv4, but client socket is IPv6, that’s why the sending data cannot be received … now using “localhost” they’re both IPv6 sockets. I’ve committed to Git master [1], this time the original test code runs perfectly. Thanks to everyone, let me know if there’re still other issues for CCL 1.11. -- Chun [1] https://github.com/usocket/usocket/commit/966de96f5f1954f7f5aa91e1191317e12… Il giorno 20/mag/2015, alle ore 20:44, Karsten Poeck <Karsten.Poeck(a)gmail.com> ha scritto: > On 20.05.15 20:25, Chun Tian (binghe) wrote: >> Hi, >> >> I was working on this issue since 10 hours ago when I firstly saw the mail. I’ve already committed an initial fix [1] to usocket Git master, in which I handled two compatibility issues between usocket and ccl-1.11, and now there’s no error reported when creating and sending sockets. But it seems that CCL::SEND-TO cannot actually send out the data to a “connected” UDP socket, as a result the test code is blocked at (usocket:socket-receive …). >> >> Usocket’s backend code for CCL is basically just a wrapper (even more true for ccl-1.11), my next step is to remove all usocket wrappers and only use CCL’s native API to reproduce the same issue. I’ll submit trac tickets to CCL if I found something. >> >> Regards, >> >> Chun >> > > Looking at the code for socket-connect in current usocket from quicklisp there are a 2 things that leaved me slightly puzzled. > > The signature is: > (defun socket-connect (host port &key (protocol :stream) element-type > timeout deadline nodelay > local-host local-port) > > But later it does (host-to-hbo local-host). This fails miserably when local-host is nil, which seems to be an ok use of it (and happens in our example for the client socket) > > It also does pass :address-family (openmcl-socket:socket-address-family remote) to openmcl-socket:make-socket. > > But remote is only set, when (and host port) otherwise it stays nil, so the socket-address will also fail. This happens for me in the server socket. > > Looking at your commit you seem to have addressed this already though :-) > > Karsten > > > > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel(a)clozure.com > https://lists.clozure.com/mailman/listinfo/openmcl-devel

1 0

Re: [Openmcl-devel] bug with usocket and/or trunk ccl - "error #22"
by Chun Tian (binghe) 20 May '15

20 May '15

CCL 1.11’s make-udp-socket function will call "%socket-connect” if keyword arguments remote-host and remote-port are provided with make-socket. This is new in CCL 1.11: (defun make-udp-socket (&rest keys &key (fd -1) (connect :active) (address-family :internet) remote-host remote-port &allow-other-keys) (unwind-protect (let (socket) (when (< fd 0) (setq fd (socket-call nil "socket" (c_socket (ecase address-family (:internet #$PF_INET) (:internet6 #$PF_INET6)) #$SOCK_DGRAM #$IPPROTO_UDP)))) (setq socket (make-instance 'udp-socket :device fd :keys keys)) (apply #'set-socket-options socket keys) (when (and (eql connect :active) remote-host remote-port) (%socket-connect fd (apply #'resolve-address :host remote-host :port remote-port :allow-other-keys t keys) nil)) (setq fd -1) socket) (unless (< fd 0) (fd-close fd)))) Il giorno 20/mag/2015, alle ore 20:00, Patrick Stein <clozure(a)nklein.com> ha scritto: > usocket from the current quicklisp dist is calling (ccl::inet-connect ...) with a few parameters it gets by calling other unexported CCL functions. > > Just this line is sufficient to get to the (first?) problem: >> (usocket:socket-connect "localhost" 1111 :protocol ':datagram) > > In a quick glance around trunk, I didn't see where make-udp-socket would invoke connect(2) or any way to do it after-the-fact. > > -- Patrick <pat(a)nklein.com> > > On May 20, 2015, at 12:49 PM, R. Matthew Emerson <rme(a)clozure.com> wrote: > >> I can try to look at it. What version of usocket are you using? Is there a place I can get it easily so I can try to run your test case and duplicate the problem? >> >> >>> On May 19, 2015, at 6:10 PM, Mark H. David <mhd(a)yv.org> wrote: >>> >>> This works on an earlier CCL: >>> Welcome to Clozure Common Lisp Version 1.10-r16196 (LinuxX8664)! >>> >>> (let* ((host "localhost") >>> (port 1111) >>> (server-sock >>> (usocket:socket-connect nil nil :protocol ':datagram :local-host host :local-port port)) >>> (client-sock >>> (usocket:socket-connect host port :protocol ':datagram)) >>> (octet-vector >>> (make-array 2 :element-type '(unsigned-byte 8) :initial-contents `(,(char-code #\O) ,(char-code #\K)))) >>> (recv-octet-vector >>> (make-array 2 :element-type '(unsigned-byte 8)))) >>> (usocket:socket-send client-sock octet-vector 2) >>> (usocket:socket-receive server-sock recv-octet-vector 2) >>> (prog1 (and (equalp octet-vector recv-octet-vector) >>> recv-octet-vector) >>> (usocket:socket-close server-sock) >>> (usocket:socket-close client-sock))) >>> >>> => >>> >>> #(79 75) >>> >>> >>> >>> On trunk CCL, updated/built on 5/19/15: >>> Welcome to Clozure Common Lisp Version 1.11-dev-r16393M-trunk (DarwinX8664)! >>> >>> It gets an error: >>> >>>> Debug: The condition Invalid argument (error #22) during attempt to connect to [unparsed, AF 2] occurred. >>>> While executing: (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER), in process repl-thread(12). >>>> Type :POP to abort, :R for a list of available restarts. >>>> Type :? for other options. >>> 1 > :b >>> >>> (24034210) : 0 (FUNCALL #'#<(:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER)>) 53 >>> (24034230) : 1 (FUNCALL #'#<SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK> NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 >>> (240342B8) : 2 (CALL-WITH-DEBUGGER-HOOK NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 >>> (240342E8) : 3 (INVOKE-DEFAULT-DEBUGGER #<USOCKET:UNKNOWN-ERROR #x30200250C31D>) 189 >>> (24034308) : 4 (SWANK-DEBUGGER-HOOK #<USOCKET:UNKNOWN-ERROR #x30200250C31D> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x3020008ADAEF>) 565 >>> (24034338) : 5 (BREAK-LOOP-HANDLE-ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> 75524225) 637 >>> (240343E0) : 6 (%ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> (:SOCKET NIL :REAL-ERROR #<SOCKET-CREATION-ERROR #x30200250D79D>) 75524225) 333 >>> (24034408) : 7 (RAISE-ERROR-FROM-ID :UNKNOWN NIL #<SOCKET-CREATION-ERROR #x30200250D79D>) 213 >>> (24034438) : 8 (HANDLE-CONDITION #<SOCKET-CREATION-ERROR #x30200250D79D> NIL) 709 >>> (24034470) : 9 (FUNCALL #'#<(:INTERNAL USOCKET:SOCKET-CONNECT)> #<SOCKET-CREATION-ERROR #x30200250D79D>) 61 >>> (24034490) : 10 (SIGNAL #<SOCKET-CREATION-ERROR #x30200250D79D>) 981 >>> (240344E8) : 11 (%ERROR #<SOCKET-CREATION-ERROR #x30200250D79D> NIL 75524258) 117 >>> (24034510) : 12 (SOCKET-ERROR NIL "connect" 22 NIL :CONNECT-ADDRESS #<SOCKET-ADDRESS [unparsed, AF 2]>) 1053 >>> (24034580) : 13 (INET-CONNECT 20 16777343 22276 NIL) 637 >>> (240345C8) : 14 (SOCKET-CONNECT "localhost" 1111 :PROTOCOL :DATAGRAM :ELEMENT-TYPE NIL :TIMEOUT NIL :DEADLINE NIL :NODELAY NIL :LOCAL-HOST NIL :LOCAL-PORT NIL) 1149 >>> (24034690) : 15 (FUNCALL #'#<Anonymous Function #x30200250E67F>) 149 >>> (240346A8) : 16 (CHEAP-EVAL (LET* (# # # # # ...) (USOCKET:SOCKET-SEND CLIENT-SOCK OCTET-VECTOR 2) (USOCKET:SOCKET-RECEIVE SERVER-SOCK RECV-OCTET-VECTOR 2) (PROG1 # # #))) 101 >>> >>> >>> >>> What's up with that? >>> >>> Thanks, >>> >>> Mark >>> >>> >> >> > _______________________________________________ > Openmcl-devel mailing list > Openmcl-devel(a)clozure.com > https://lists.clozure.com/mailman/listinfo/openmcl-devel

1 0

bug with usocket and/or trunk ccl - "error #22"
by Mark H. David 20 May '15

20 May '15

This works on an earlier CCL: Welcome to Clozure Common Lisp Version 1.10-r16196 (LinuxX8664)! (let* ((host "localhost") (port 1111) (server-sock (usocket:socket-connect nil nil :protocol ':datagram :local-host host :local-port port)) (client-sock (usocket:socket-connect host port :protocol ':datagram)) (octet-vector (make-array 2 :element-type '(unsigned-byte 8) :initial-contents `(,(char-code #\O) ,(char-code #\K)))) (recv-octet-vector (make-array 2 :element-type '(unsigned-byte 8)))) (usocket:socket-send client-sock octet-vector 2) (usocket:socket-receive server-sock recv-octet-vector 2) (prog1 (and (equalp octet-vector recv-octet-vector) recv-octet-vector) (usocket:socket-close server-sock) (usocket:socket-close client-sock))) => #(79 75) On trunk CCL, updated/built on 5/19/15: Welcome to Clozure Common Lisp Version 1.11-dev-r16393M-trunk (DarwinX8664)! It gets an error: > Debug: The condition Invalid argument (error #22) during attempt to connect to [unparsed, AF 2] occurred. > While executing: (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER), in process repl-thread(12). > Type :POP to abort, :R for a list of available restarts. > Type :? for other options. 1 > :b (24034210) : 0 (FUNCALL #'#<(:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER)>) 53 (24034230) : 1 (FUNCALL #'#<SWANK/BACKEND:CALL-WITH-DEBUGGER-HOOK> NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 (240342B8) : 2 (CALL-WITH-DEBUGGER-HOOK NIL #<COMPILED-LEXICAL-CLOSURE (:INTERNAL SWANK::INVOKE-DEFAULT-DEBUGGER) #x302002623FFF>) 181 (240342E8) : 3 (INVOKE-DEFAULT-DEBUGGER #<USOCKET:UNKNOWN-ERROR #x30200250C31D>) 189 (24034308) : 4 (SWANK-DEBUGGER-HOOK #<USOCKET:UNKNOWN-ERROR #x30200250C31D> #<Compiled-function SWANK:SWANK-DEBUGGER-HOOK #x3020008ADAEF>) 565 (24034338) : 5 (BREAK-LOOP-HANDLE-ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> 75524225) 637 (240343E0) : 6 (%ERROR #<USOCKET:UNKNOWN-ERROR #x30200250C31D> (:SOCKET NIL :REAL-ERROR #<SOCKET-CREATION-ERROR #x30200250D79D>) 75524225) 333 (24034408) : 7 (RAISE-ERROR-FROM-ID :UNKNOWN NIL #<SOCKET-CREATION-ERROR #x30200250D79D>) 213 (24034438) : 8 (HANDLE-CONDITION #<SOCKET-CREATION-ERROR #x30200250D79D> NIL) 709 (24034470) : 9 (FUNCALL #'#<(:INTERNAL USOCKET:SOCKET-CONNECT)> #<SOCKET-CREATION-ERROR #x30200250D79D>) 61 (24034490) : 10 (SIGNAL #<SOCKET-CREATION-ERROR #x30200250D79D>) 981 (240344E8) : 11 (%ERROR #<SOCKET-CREATION-ERROR #x30200250D79D> NIL 75524258) 117 (24034510) : 12 (SOCKET-ERROR NIL "connect" 22 NIL :CONNECT-ADDRESS #<SOCKET-ADDRESS [unparsed, AF 2]>) 1053 (24034580) : 13 (INET-CONNECT 20 16777343 22276 NIL) 637 (240345C8) : 14 (SOCKET-CONNECT "localhost" 1111 :PROTOCOL :DATAGRAM :ELEMENT-TYPE NIL :TIMEOUT NIL :DEADLINE NIL :NODELAY NIL :LOCAL-HOST NIL :LOCAL-PORT NIL) 1149 (24034690) : 15 (FUNCALL #'#<Anonymous Function #x30200250E67F>) 149 (240346A8) : 16 (CHEAP-EVAL (LET* (# # # # # ...) (USOCKET:SOCKET-SEND CLIENT-SOCK OCTET-VECTOR 2) (USOCKET:SOCKET-RECEIVE SERVER-SOCK RECV-OCTET-VECTOR 2) (PROG1 # # #))) 101 What's up with that? Thanks, Mark

3 2

bug with usocket and/or trunk ccl - "error #22"
by Mark H. David 19 May '15

19 May '15

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

usocket-devel May 2015