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

[usocket-devel] Fwd: [usocket-cvs] r245 - usocket/trunk/backend
by Erik Huelsmann 23 Jul '08

23 Jul '08

Hi Douglas, I recently added some functionality in usocket and even though I think I could have copy-pasted from the CMU backend, I want to verify with you if this is true. The functions I added: - get-host-name (as you can see in the commit mail below based on copy-paste from CMU) - wait-for-input-internal which I didn't copy-paste yet. I would be especially gratefull if you could copy-paste and verify the latter for me and optionally even supply a patch. For testing of the multiplexing code, I use this 'script': (load "asdf.lisp") (asdf:oos 'asdf:load-op :usocket) (defvar sockets nil) (defparameter crlf (format nil "~C~C" #\Return #\Linefeed)) (defparameter host "mirror.w3media.nl") (defparameter offset-path "/apache") (dotimes (i 10) (let ((s (usocket:socket-connect host 80))) (format (usocket:socket-stream s) "GET http://~A~A/httpd/httpd-2.0.~A.tar.gz HTTP/1.0~%~%" host offset-path (+ 50 i)) (force-output (usocket:socket-stream s)) (push s sockets))) (let ((buffer (make-array 8192 :element-type 'character))) (loop (let ((ready (usocket:wait-for-input sockets :timeout 15))) (unless ready (sleep 1) (format t "No ready sockets!~%")) (dolist (r ready) (format t "Reading from ~A~%" r) (read-sequence buffer (usocket:socket-stream r)))))) HTH and thanks for your reaction in advance! bye, Erik. ---------- Forwarded message ---------- From: ehuelsmann(a)common-lisp.net <ehuelsmann(a)common-lisp.net> Date: May 18, 2007 12:03 AM Subject: [usocket-cvs] r245 - usocket/trunk/backend To: usocket-cvs(a)common-lisp.net Author: ehuelsmann Date: Thu May 17 18:03:55 2007 New Revision: 245 Modified: usocket/trunk/backend/scl.lisp Log: Add cl-smtp 'requirement': get-host-name (SCL backend); needs verification. Modified: usocket/trunk/backend/scl.lisp ============================================================================== --- usocket/trunk/backend/scl.lisp (original) +++ usocket/trunk/backend/scl.lisp Thu May 17 18:03:55 2007 @@ -129,3 +129,6 @@ (t (error 'ns-unknown-error :host-or-ip name :real-error errno)))))))) + +(defun get-host-name () + (unix:unix-gethostname)) _______________________________________________ usocket-cvs mailing list usocket-cvs(a)common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-cvs

4 8

[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