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

[usocket-devel] UDP support in usocket, ideas explained
by Erik Huelsmann 03 Oct '08

03 Oct '08

When looking at usocket.lisp, you'll find there is a datagram-usocket class commented out. I think this class (even without any additional slot definitions) should be used for UDP sockets. Then there's datagram-usocket-p, which should start returning T when the passed in object is a true descendant of DATAGRAM-USOCKET. Looking further, you'll find there are functions defined for creating stream and stream-server objects. A function like that should be created for UDP sockets. I think it's only sane to extend WAIT-FOR-INPUT to apply to UDP sockets as well as any of the currently supported sockets. The LispWorks variant of this function (for win32) is still on my laptop. I'll try to finish it up soon, so that you can all start testing it. I propose we implement recv()/recvfrom() as one function: SOCKET-RECEIVE. I think we shouldn't bother implementing recv() and recvfrom() as separate interfaces: I think we should return the recvfrom-address field as the second return value of SOCKET-RECEIVE. I also propose we implement send()/sendto() as one function: SOCKET-SEND. I think we should provide the sendto address as an optional parameter to the SOCKET-SEND function. Also, I think the function should check for connected-ness of the datagram socket. If the sendto address is specified on a connected socket AND the address specified is unequal to the connected address, the function should error. Oh. One last thing: local and peer address retrieval functions should be adapted to apply to UDP sockets as well as the currently supported stream sockets. I hope this is all a bit clear! If you have (m)any questions, please don't hesitate to ask. Bye, Erik.

2 9

[usocket-devel] bind interface?
by Chris Dean 04 Aug '08

04 Aug '08

I'm new to usocket and would like to bind a socket to a specific address. (bind as in http://www.istild.com/man-pages/man2/bind.2.html) Is there an api for that? Cheers, Chris Dean

3 11

[usocket-devel] Rebranching 0.4.x branch && road to 0.4.x release
by Erik Huelsmann 31 Jul '08

31 Jul '08

Over the last month(s), many commits have happened on trunk/ which should also be in 0.4.x. On inspection, out of 30 or 40 commits, only 4 should *not* be on 0.4.x. (The UDP socket changes.) With r405, basically everything I want to have in 0.4.x is now on trunk/. (Except - ofcourse - the SCL changes Douglas is looking into, but that can come later too.) For efficiency, I have decided to rebranch the 0.4.x branch and afterwards undoing the UDP socket changes on that branch. When that's done - at the end of this week - all that needs to happen for 0.4.x is testing. So, anybody who's interested in a release with WAIT-FOR-INPUT and :local-host binding for SOCKET-CONNECT, please provide your feedback starting Monday August 4th: we need to asses the quality of the code currently up for release on the branch! Thanks for your patience, it's been a big task to get this release done! And of course: thanks to everybody who invested time into providing feedback as well as patches! Bye, Erik.

2 2

[usocket-devel] Working the hans/ branch into trunk
by Erik Huelsmann 27 Jul '08

27 Jul '08

Hi Hans, I have a question regarding the hans/ branch: in usocket.lisp, you added the SET-SOCKET-TIMEOUTS function. However, other than the default method from the 'defgeneric' form, it doesn't look very much implemented anywhere. Did you find this is at this time not possible? If so, shouldn't we just ditch it for the moment (ie, not move to trunk/)? Bye, Erik.

1 0

[usocket-devel] HOST-TO-HBO bug on SBCL
by Chun Tian (binghe) 27 Jul '08

27 Jul '08

Hi, Erik On SBCL (I'm using 1.0.18.x), HOST-TO-HBO cannot work for string: * (usocket::host-to-hbo "localhost") debugger invoked on a SB-KERNEL:CASE-FAILURE: #(127 0 0 1) fell through ETYPECASE expression. Wanted one of (INTEGER (VECTOR T 4) STRING). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. This is because SBCL return #(127 0 0 1) as type (simple-array (unsigned-byte 8) (4)), it's not a subtype of (VECTOR T 4). An solution is add more type to the ETYPECASE of HOST-TO-HBO: (and HOST-TO-VECTOR-QUAD) #-(or clisp armedbear) (progn (defun host-to-vector-quad (host) "Translate a host specification (vector quad, dotted quad or domain name) to a vector quad." (etypecase host (string (let* ((ip (ignore-errors (dotted-quad-to-vector-quad host)))) (if (and ip (= 4 (length ip))) ;; valid IP dotted quad? ip (get-random-host-by-name host)))) ((vector t 4) host) ((simple-array (unsigned-byte 8) (4)) host) (integer (hbo-to-vector-quad host)) (null nil))) (defun host-to-hbo (host) (etypecase host (string (let ((ip (ignore-errors (dotted-quad-to-vector-quad host)))) (if (and ip (= 4 (length ip))) (host-byte-order ip) (host-to-hbo (get-host-by-name host))))) ((vector t 4) (host-byte-order host)) ((simple-array (unsigned-byte 8) (4)) (host-byte-order host)) (integer host) (null nil)))) For some reason, I think just let (HOST-TO-HBO NIL) returns NIL will be good, can save us some coding. Please review this, thanks. Regards, Chun Tian (binghe)

2 6

[usocket-devel] some inline in usocket.lisp (trunk)
by Chun Tian 27 Jul '08

27 Jul '08

Hi, Erik See this: (declaim (inline %setup-wait-list %add-waiter %remove-waiter)) When usocket.lisp compiled, these three haven't be defined, how can compiler inline them? I just found, with these inline declaim, CMUCL even not to call the real %remove-waiter in remove-waiter: (defun remove-waiter (wait-list input) (%remove-waiter wait-list input) (setf (wait-list-waiters wait-list) (remove input (wait-list-waiters wait-list)) (wait-list input) nil) (remhash (socket input) (wait-list-map wait-list))) CMUCL give me this: * (snmp:snmp-get "binghe-debian.local" "sysDescr.0") Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #<USOCKET:DATAGRAM-USOCKET {487AD7C5}> is not of type USOCKET::WAIT-LIST [Condition of type TYPE-ERROR] Restarts: 0: [ABORT] Return to Top-Level. Debug (type H for help) (USOCKET:REMOVE-WAITER #S(USOCKET::WAIT-LIST :%WAIT (11) :WAITERS (#) :MAP #<HASH-TABLE :TEST EQL :WEAK-P NIL :COUNT 1 {487B0EFD}>) #<USOCKET:DATAGRAM-USOCKET {487AD7C5}>) Source: (%REMOVE-WAITER WAIT-LIST INPUT) 0] 0 I set up a format in %remove-waiter, and didn't got any output, so to confirm %remove-waiter wasn't be called, just because the inline declaim. Without these declaims, everything goes well again: * (snmp:snmp-get "binghe-debian.local" "sysDescr.0") XXX: #S(USOCKET::WAIT-LIST :%WAIT (12) :WAITERS (#<USOCKET:DATAGRAM-USOCKET {4953EC4D}>) :MAP #<HASH-TABLE :TEST EQL :WEAK-P NIL :COUNT 1 {4954C0CD}>), #<USOCKET:DATAGRAM-USOCKET {4953EC4D }> "Linux binghe-debian.local 2.6.25-2-amd64 #1 SMP Fri Jun 27 00:16:12 UTC 2008 x86_64" So I think this is a misuse of inline, and at least break CMUCL. Hope you can remove it. Regards, Chun Tian (binghe)

1 1

[usocket-devel] bugs in trunk: condition.lisp, usocket.lisp
by Chun Tian (binghe) 27 Jul '08

27 Jul '08

Hi, Erik When I try to compile recent usocket trunk code, two issues found: In condition.lisp, the (define-condition insufficient-implementation) cannot compiled on LispWorks: **++++ Error in (SUBFUNCTION (DEFCLASS USOCKET:INSUFFICIENT-IMPLEMENTATION) (DEFINE-CONDITION USOCKET:INSUFFICIENT- IMPLEMENTATION)): FUNCTION is defined as an ordinary function #<Function SYSTEM::UNDEFINED-FEXPR-FUNCTION 20259C4A> I checked CLHS ( http://www.lispworks.com/documentation/HyperSpec/Body/s_fn.htm ), it says FUNCTION is a "Special Operator" which serves as a function: (defun adder (x) (function (lambda (y) (+ x y)))) (setq add3 (adder 3)) (funcall add3 5) => 8 So you define it into a slot reader will cause symbol conflict with Common Lisp itself. LispWorks is quite strict, other CLs just pass it. I suggest you use FUNCTION-OF instead of FUNCTION, like this: (define-condition insufficient-implementation (error) ((feature :initarg :feature :reader feature) (function :initarg :function :reader function-of)) (:documentation "The ancestor of all errors usocket may generate because of insufficient support from the underlying implementation with respect to the arguments given to `function'. One call may signal several errors, if the caller allows processing to continue. ")) With this change, I can compile and load on LispWorks now. But I don't know where else you use this reader function. Please review this, and make some change for LispWorks. Thanks, --binghe

3 2

[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] SBCL cannot compile trunk (sometimes...)
by Chun Tian (binghe) 22 Jul '08

22 Jul '08

Hi, Erik Would you please put (defun DATAGRAM-USOCKET-P) on behind of (defclass DATAGRAM-USOCKET)? It seems that under some compiler options, SBCL complains that he don't know about the DATAGRAM-USOCKET type: Index: usocket.lisp =================================================================== --- usocket.lisp (revision 362) +++ usocket.lisp (working copy) @@ -72,14 +72,14 @@ (defun stream-server-usocket-p (socket) (typep socket 'stream-server-usocket)) -(defun datagram-usocket-p (socket) - (typep socket 'datagram-usocket)) - (defclass datagram-usocket (usocket) ((connected-p :initarg :connected-p :accessor connected-p)) ;; ###FIXME: documentation to be added. (:documentation "")) +(defun datagram-usocket-p (socket) + (typep socket 'datagram-usocket)) + (defun make-socket (&key socket) "Create a usocket socket type from implementation specific socket." (unless socket --binghe

2 1

[usocket-devel] [patch] Networking: bind to local-host/local-port when connect
by Chun Tian (binghe) 21 Jul '08

21 Jul '08

Hi, CMUCL & rtoy CMUCL's networking API do not have standalone BIND function. And it's EXT:CONNECT-TO-INET-SOCKET and EXT:CREATE-INET-SOCKET function do not have any LOCAL-HOST/LOCAL-PORT argument. So a client socket is IMPOSSIBLE to bind to specific local host/port when CONNECT to remote address. I wrote a loadable CMUCL patch, which create a new function BIND-INET- SOCKET, and add LOCAL-HOST, LOCAL-PORT keyword arguments to above two functions to support this feature. I think it's quite safe to merge it in next CMUCL version. Please review it. Regards, Chun Tian (binghe)

1 0