Lispworks Windows UDP behaviour
Chun Tian (binghe)
binghe.lisp at gmail.com
Fri May 22 08:24:06 UTC 2015
Hi Frank,
Today I have modified SOCKET-SEND and SOCKET-RECEIVE for LispWorks, to be able to detect and report socket errors. I think in this way, these APIs on LispWorks could behavior closer to other platforms.
Now on Windows, your test code should return a USOCKET:CONNECTION-RESET-ERROR condition, which equals to WSA error ECONNRESET. However, when I test the same code on Mac OS X, it instead returns USOCKET:CONNECTION-REFUSED-ERROR, I think this is a behavior of BSD sockets.
I hope you can try latest usocket code from Git [1], to see if it works better for your case now. My code changes commit can be seen here [2].
For wait-for-input, I can’t see what you see (the socket object remains in a :READ state), if you still think this is an issue, I hope you can create another test code to demonstrate this issue.
Regards,
Chun
[1] https://github.com/usocket/usocket
[2] https://github.com/usocket/usocket/commit/13386639889fa812540fc4f77824c47e7616db37
Il giorno 10/apr/2015, alle ore 23:00, Frank James <frank.a.james at gmail.com> ha scritto:
> 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.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20150522/61760a10/attachment.sig>
More information about the usocket-devel
mailing list