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

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

[ANNOUNCE] usocket 0.6.2
by Chun Tian (binghe) 20 Apr '15

20 Apr '15

Dear lispers, We announce the usocket 0.6.2 release, a small patch release after 0.6.1 (June 2013). Changes in this release: * Bugfix: [CCL] Fixed CCL-1.11 compatibility. * Bugfix: [ECL] Fixed compatibility on recent versions. * Bugfix: [LispWorks] Added support address-in-use-error condition on LW/Win32. (patch from Sergey Katrevich). 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 As usual, any feedback - bugs or hugs - is greatly appreciated. We have turned to use Git [1] instead of SVN, so maybe now it’s easier to receive patches. P. S. Something currently still in progress (will be released soon): * New feature: IPv6 support (by Hans Hübner) Regards, Chun Tian (binghe) USOCKET Team [1] https://github.com/usocket/usocket.git

1 0

status of openmcl and :ccl-1.11-sockets feature
by Mark H. David 16 Apr '15

16 Apr '15

I see there's code to add feature :ccl-1.11-sockets and to use it via a read-time feature check in the same file. The file is backend/openmcl.lisp. I don't think this can work reliably. It seems to work, but I don't think Common Lisp guarantees it. The code is (eval-when (:compile-toplevel :load-toplevel :execute) (when (find-class 'ccl::ip6-socket-address nil) (pushnew :ccl-1.11-sockets *features*))) I think a much more robust solution would be for this to go in an earlier file that is guaranteed to be loaded before backend/openmcl.lisp is compiled. Can one of the developers review this? Also, any word on when this will propagate to Quicklisp? Thanks, Mark

3 3