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

[usocket-devel] proxy support?
by Yaroslav Kavenchuk 21 Jun '07

21 Jun '07

Hi! Support of a proxy in the usocket is meaningful? It will add dependence on cl-base64. -- WBR, Yaroslav Kavenchuk.

2 3

[usocket-devel] Proposed wait-for-input API for waiting for input for (one out of) a list of sockets
by Erik Huelsmann 21 May '07

21 May '07

I've come to the conclusion that in order to be able to use sockets, even in the blocking mode which usocket supports now, we need an API to wait for one or more sockets to become ready for input (or accept() in case of server sockets). If this call would support time-outs, that would be even better. So, I've investigated all supported implementations and -apart from LispWorks- they all support a 'wait-for-input-on-one-or-more-sockets-with-timeout' api. (I've sent LispWorks tech support a mail about this, hoping they actually do provide a function to achieve this.) As for the API which I think I'll be able to support on all platforms, it'll look like this: (defmethod wait-for-input (stream-or-streams &key timeout)) => (values ready-streams time-remaining-within-timeout) So, the input is a stream or a list of streams and a real or integer value timeout (in seconds). It will return the remaining time in the timeout and the streams ready for reading/accepting. When the ready-streams list is empty, there are 2 possible situations: 1) We timed out (time-remaining-within-timeout <= 0) 2) We were interrupted while waiting (time-remaining-within-timeout > 0) Does this API seem acceptable to you? If not, please tell me so! BTW: Discussing sockets and event schedulers on #lisp, drewc brought up that IOLib has an event dispatcher the API which he would really like to see copied into usocket. I counter proposed we abstract the api into a general event dispatching mechanism into which many different libraries can provide their hooks. I don't think that providing hooks like these is beyond the scope of this project, but I do think that adding a dispatcher as complex as the one I found in IOLib is contrary to the short term goal of 'getting a useable portability library out there'. IOW: I'd love to work on it, but not before 1.0. bye, Erik.

1 2

[usocket-devel] Re: (Lisp Support Call #35530) Sockets / COMM-package questions: select()-like function && UDP sockets
by Erik Huelsmann 19 May '07

19 May '07

Almost two weeks ago I sent the mail below. I've been looking for a good way to achieve my goal with what APIs I found in LispWorks. For Unix, I found a good way by using process-wait-with-timeout, the right wait-function (which checks read-readyness of the server socket using socket-listen) and mp:notify-fd. When working on a solution that would work on Windows, I noticed that socket-listen behaves very differently on windows: it won't return T when a socket is ready to accept new connections. The unix variant *does* include that behaviour. Also, making a stream from the socket fd [make-instance 'comm::socket-stream] doesn't work either: it sends system:wait-for-input-streams into endless recursion. Now, I'm absolutely not afraid of a bit of Foreign Function Interface programming, but if this is at all possible, I'd like a hint from your side, hopefully to a function which already provides the 'wait-for-all-streams-including-passive-sockets(servers)-at-once' behaviour. Could you help me out please? I used the suggestion you gave me last time to look in other sockets libraries on the net, but those don't provide this functionality. Thank you very much for any information you can provide. bye, Erik. On 5/7/07, lisp-support(a)lispworks.com <lisp-support(a)lispworks.com> wrote: > The LispWorks Support call tracking system attaches an id > number to the subject line of each new call we receive. > > Your message about > > Sockets / COMM-package questions: select()-like function && UDP sockets > > has been entered into our call tracking system as id 35530. Please > put (Lisp Support Call #35530) in the subject line of any further > mail about this call. (Note that replying to this or any further > messages from us about this call will do this for you automatically). > > Thank you for using LispWorks Products > > The LispWorks Support Team -------------------------------------------------------- Hi! Martin? I've sent you mails before regarding the Lispworks COMM package because of my work for the usocket project for a portable sockets access implementation. It turns out that I'm going to succeed to go where no portability library has gone before: UDP sockets. I'm currently working on 'efficient multiple socket waiting' (ie select() call like behaviour) and it looks like LispWorks provides something like it with its wait-for-input-streams function. I do have questions about it though: 1) From the reference material I've concluded it's only available on LispWorks 5.0. Is there anything you recommend using for 4.x? 2) When I've got a server socket retrieved through create-tcp-socket-for-service, is that a stream object I can pass to wait-for-input-stream? And, although I haven't completed implementing the wait-behaviour yet, I'm also collecting data on creation of UDP sockets. You can find what I have so far on http://trac.common-lisp.net/usocket/wiki/DatagramSockets. What you'll find is that of all supported implementations, LispWorks is the only one I haven't been able to identify a means to create (and use) UDP sockets for. I'm hoping you can help me here, because the sources you've referred me to in the past (acl-compat) don't 'do' UDP. I hope you can give me some directions or direct help! Thanks for your time in any case. bye, Erik Huelsmann main author of usocket PS: If you're interested: I've published a (work in progress) api description at http://common-lisp.net/project/usocket/api-docs.shtml.

1 0

[usocket-devel] Your CL sockets API paper
by Erik Huelsmann 12 May '07

12 May '07

Hi Dave, I found your December 2005 paper on a general sockets API for Lisp at http://www.findinglisp.com/papers/sockets-analysis-0-2-5.pdf. Interesting reading for someone working on exactly that topic. You're saying there that there's a lot to be desired in Lisp sockets and I agree. Though you also claim that UDP is not feasible in many lisp implementations. I have to disagree there: I'm working on usocket, a minimal sockets portability library. Minimal in the sense that I try to keep the layer between the implementation and the application as thin as possible to prevent as much overhead as possible. When you're interested, you can find my analysis on providing UDP sockets on all supported implementations but LispWorks at http://trac.common-lisp.net/usocket/wiki/DatagramSockets. I'm currently working on implementing a multiplexing model other than blocking threads (important!). After that I'll proceed to UDP. From there on I'll go the socket options and shutdown route. I hope you'll follow the usocket project with interest and I'm hoping for any comments you can provide. bye, Erik.

1 0

[usocket-devel] Socket status check
by Mikhail Shevchuk 11 May '07

11 May '07

Hi, Is there any way to check the status of the socket? E.g, to be sure not to write to a closed socket or to read from one. -- A vivid and creative mind characterizes you.

1 0

[usocket-devel] socket-listen issue
by Mikhail Shevchuk 05 May '07

05 May '07

Hi I have a small server that uses usocket as a socket library and sbcl as a compiler: (defun server () (let ((sock (usocket:socket-listen "88.204.87.138" 3690 :backlog 4))) (loop (let ((csock (usocket:socket-accept sock))) (let ((cstream (usocket:socket-stream csock))) (when cstream (loop for line = (read-line cstream nil) while line do (progn (format t "XMPP: ~A~%" line) (cl-irc:privmsg *irc-connection* "#abcd" line)))) (close cstream)))))) After terminating the thread and reevaluating the function, I get the following error: Socket error in "bind": EADDRINUSE (Address already in use) [Condition of type SB-BSD-SOCKETS:ADDRESS-IN-USE-ERROR] I also tried to use :reuseaddress t, but that doesn't help. What is the correct way to stop such server and thread? P.S. One more thing, are there any examples of how can I build multi-thread server using usocket for serving bunch of clients? -- Mikhail

1 0

[usocket-devel] :reuseaddress
by Attila Lendvai 29 Mar '07

29 Mar '07

dear list, the :reuseaddress keyword arg does not follow the usual naming convention. what do you think about renaming it to :reuse-address? -- - attila "- The truth is that I've been too considerate, and so became unintentionally cruel... - I understand. - No, you don't understand! We don't speak the same language!" (Ingmar Bergman - Smultronstället)

1 0

[usocket-devel] allegro.lisp
by Paul O'Rorke 24 Mar '07

24 Mar '07

Hi: I am trying to use usocket to port some projects from CLisp to ACL and possible SBCL and hoping usocket will enable me to have something general. In ACL, there seem to be problems in the get-XXX methods that I think are patched as follows... ; 070315 PaulO: this seems too specific and doesn't match get-local-address ; (defmethod get-peer-address ((usocket stream-server-usocket)) (defmethod get-peer-address ((usocket usocket)) (hbo-to-vector-quad (socket:remote-host (socket usocket)))) (defmethod get-local-port ((usocket usocket)) (socket:local-port (socket usocket))) ; 070315 PaulO: this seems too specific and doesn't match get-local-name ; (defmethod get-peer-port((usocket stream-server-usocket)) (defmethod get-peer-port ((usocket usocket)) (socket:remote-port (socket usocket))) (defmethod get-local-name ((usocket usocket)) (values (get-local-address usocket) (get-local-port usocket))) ; 070315 PaulO: this seems too specific and doesn't match get-local-name ; (defmethod get-peer-name ((usocket stream-server-usocket)) (defmethod get-peer-name ((usocket usocket)) (values (get-peer-address usocket) (get-peer-port usocket)))

2 2

[usocket-devel] SBCL test failures
by Paul O'Rorke 15 Mar '07

15 Mar '07

Hi: I am evaluating usocket as a way to help generalize and port a program that currently uses CLisp and I am using SBCL. I dug up cl-rt and split-sequence in cl-utilities and ran the tests and got the following errors on my Intel MacBook Pro running OS X... Is it just that the tests need to allow SBCL to return timeout error? (I don't see SBCL in the with-caught-conditions.) #<USOCKET:TIMEOUT-ERROR {11862E89}> is a USOCKET:TIMEOUT-ERROR. Its slot values are (:SOCKET #<USOCKET:STREAM-USOCKET {11862A31}>). 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+) :UNREACH) Expected value: NIL Actual value: #<USOCKET:TIMEOUT-ERROR {11862E89}>. #<USOCKET:TIMEOUT-ERROR {1195CCB1}> is a USOCKET:TIMEOUT-ERROR. Its slot values are (:SOCKET #<USOCKET:STREAM-USOCKET {1195C761}>). 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) :UNREACH) Expected value: NIL Actual value: #<USOCKET:TIMEOUT-ERROR {1195CCB1}>. The only other test that failed was: (deftest socket-name.4 (with-caught-conditions (nil nil) (let ((sock (usocket:socket-connect +common-lisp-net+ 80))) (unwind-protect (usocket::get-local-address sock) (usocket:socket-close sock)))) #(192 168 1 65)) Should I have replaced the 192 168 1 65 with my machine's local IP? ---Paul O

2 1

[usocket-devel] with-* style macros for sockets
by Harold Lee 26 Jan '07

26 Jan '07

Hi, I've just started using usocket, and it is very nice. The first thing I did was to write a couple of helper macros for server-side socket handling, and I thought they might be worth including in the library: (defmacro with-listener (socket-specs &rest body) "Listen for connections and clean up when done." (destructuring-bind (socket-var &rest socket-options) socket-specs (let ((var-name (gensym))) `(let* ((,var-name (socket-listen ,@socket-options)) (,socket-var ,var-name)) (unwind-protect (progn ,@body) (socket-close ,var-name)))))) (defmacro with-client-stream (socket-specs &rest body) "Work with a client socket stream and clean up when done." (destructuring-bind (stream-var listener-var &rest socket-options) socket-specs (let ((var-name (gensym))) `(let* ((,var-name (socket-accept ,listener-var ,@socket-options)) (,stream-var (socket-stream ,var-name))) (unwind-protect (progn ,@body) (socket-close ,var-name)))))) They let you easily get started listening for connections and working with connected clients (partly because all you see are the listener socket and a stream for each client). e.g. (defun handle-one-request () (with-listener (listener "127.0.0.1" 40389) (with-client-stream (stream listener) (handle-request stream)))) -Harold

2 1