usocket-devel September 2008

usocket-devel@common-lisp.net

5 participants
5 discussions

[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] [bug] WAIT-FOR-INPUT cannot be called without :TIMEOUT
by Chun Tian (binghe) 02 Oct '08

02 Oct '08

Hi, usocket Just found a bug on 0.4.x branch, on LispWorks (non-win32 version). The WAIT-FOR-INPUT-INTERNAL function has a TRUNCATE operation on TIMEOUT: (defun wait-for-input-internal (wait-list &key timeout) (with-mapped-conditions () ;; unfortunately, it's impossible to share code between ;; non-win32 and win32 platforms... ;; Can we have a sane -pref. complete [UDP!?]- API next time, please? (dolist (x (wait-list-waiters wait-list)) (mp:notice-fd (os-socket-handle x))) (mp:process-wait-with-timeout "Waiting for a socket to become active" (truncate timeout) ;; IT'S HERE!!!!!!!!!!!!!!!!!!!!!!!!! #'(lambda (socks) (let (rv) (dolist (x socks rv) (when (usocket-listen x) (setf (state x) :READ rv t))))) (wait-list-waiters wait-list)) (dolist (x (wait-list-waiters wait-list)) (mp:unnotice-fd (os-socket-handle x))) wait-list))) So if I call WAIT-FOR-INPUT on a usocket instance with no TIMEOUT keyword supply, (TRUNCATE NIL) will be called, and error happens. How to fix this issue to make sure I can just wait "infinitely" on a usocket? Regards, Chun Tian (binghe)

2 3

[usocket-devel] What if a usocket instance be garbage collected?
by Chun Tian (binghe) 01 Oct '08

01 Oct '08

Hi, usocket devel If a usocket instance has been garbage collected (or just cannot refer to it, i. e. lost it by set the variable to new value), does anyone (either usocket or CL platform) will consider closing the correspond socket fd automatically? I know at least one CL platform, LispWorks, has some related API (HCL:ADD-SPECIAL-FREE-ACTION) [1], and I want to use it in my UDP applications. Just don't know if this will be a common feature to be considered by usocket itself. Any opinions? --binghe [1] http://www.lispworks.com/documentation/lw51/LWUG/html/lwuser-149.htm#pgfId-…

3 4

[usocket-devel] Compile failure on CLISP 2.46
by Zach Beane 30 Sep '08

30 Sep '08

When compiling usocket 0.3.7 on CLISP 2.46, I get this error: ;; Loading file /Users/xach/src/zs3-test/source/usocket-0.3.7/backend/clisp.fas ... ** - Continuable Error FFI::FIND-FOREIGN-FUNCTION: foreign function "gethostname" does not exist Any ideas? Zach

3 7

[usocket-devel] Re: usocket-devel post from larsnostdal@gmail.com requires approval
by Erik Huelsmann 18 Sep '08

18 Sep '08

Hi Lars! Thanks for the report. Sorry for the delay; I finally committed your fix. I've applied a similar fix to SOCKET-LISTEN. Bye, Erik. On Tue, Aug 26, 2008 at 2:10 PM, <usocket-devel-owner(a)common-lisp.net> wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: usocket-devel(a)common-lisp.net > From: larsnostdal(a)gmail.com > Subject: [Fwd: Don't want FD leaks (patch)] > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > http://common-lisp.net/cgi-bin/mailman/admindb/usocket-devel > > to approve or deny the request. > > > ---------- Forwarded message ---------- > From: Lars Rune Nøstdal <larsnostdal(a)gmail.com> > To: usocket-devel(a)common-lisp.net > Date: Tue, 26 Aug 2008 14:11:33 +0200 > Subject: [Fwd: Don't want FD leaks (patch)] > > > > ---------- Forwarded message ---------- > From: Lars Rune Nøstdal <larsnostdal(a)gmail.com> > To: > Date: Tue, 26 Aug 2008 14:04:09 +0200 > Subject: Don't want FD leaks (patch) > Hi, > Noticed that FDs leak in some cases. Quick test and a patch: > > (defun test () > (loop > (handler-case > (let ((socket (usocket:socket-connect "aoeuaoeu.com" 80))) > (princ socket) (terpri)) > (t (c) > (format t "do i leak? ~A~%" c))))) > > > I use lsof to test for leaks while this is running: > lnostdal@blackbox:~/programming/lisp/usocket$ lsof -a -p 25803 | nl > > Here is the patch; not tested much but seems to work for me: > > > lnostdal@blackbox:~/programming/lisp/usocket$ svn diff > Index: backend/sbcl.lisp > =================================================================== > --- backend/sbcl.lisp (revision 423) > +++ backend/sbcl.lisp (working copy) > @@ -213,27 +213,32 @@ > (not (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay))) > (unsupported 'nodelay 'socket-connect)) > > - (let* ((socket (make-instance 'sb-bsd-sockets:inet-socket > - :type :stream :protocol :tcp)) > - (stream (sb-bsd-sockets:socket-make-stream socket > - :input t > - :output t > - :buffering :full > - :element-type element-type)) > - ;;###FIXME: The above line probably needs an :external-format > - (usocket (make-stream-socket :stream stream :socket socket)) > - (ip (host-to-vector-quad host))) > - (when (and nodelay-specified > - (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay)) > - (setf (sb-bsd-sockets:sockopt-tcp-nodelay socket) nodelay)) > - (when (or local-host local-port) > - (sb-bsd-sockets:socket-bind socket > - (host-to-vector-quad > - (or local-host *wildcard-host*)) > - (or local-port *auto-port*))) > - (with-mapped-conditions (usocket) > - (sb-bsd-sockets:socket-connect socket ip port)) > - usocket)) > + (let ((socket (make-instance 'sb-bsd-sockets:inet-socket > + :type :stream :protocol :tcp))) > + (handler-case > + (let* ((stream (sb-bsd-sockets:socket-make-stream socket > + :input t > + :output t > + :buffering :full > + :element-type element-type)) > + ;;###FIXME: The above line probably needs an :external-format > + (usocket (make-stream-socket :stream stream :socket socket)) > + (ip (host-to-vector-quad host))) > + (when (and nodelay-specified > + (fboundp 'sb-bsd-sockets::sockopt-tcp-nodelay)) > + (setf (sb-bsd-sockets:sockopt-tcp-nodelay socket) nodelay)) > + (when (or local-host local-port) > + (sb-bsd-sockets:socket-bind socket > + (host-to-vector-quad > + (or local-host *wildcard-host*)) > + (or local-port *auto-port*))) > + (with-mapped-conditions (usocket) > + (sb-bsd-sockets:socket-connect socket ip port)) > + usocket) > + (t (c) > + ;; Make sure we don't leak filedescriptors. > + (sb-bsd-sockets:socket-close socket) > + (error c))))) > > (defun socket-listen (host port > &key reuseaddress > > > > -- > Lars Rune Nøstdal || AJAX/Comet GUI type stuff for Common Lisp > http://nostdal.org/ || http://groups.google.com/group/symbolicweb > > > ---------- Forwarded message ---------- > From: usocket-devel-request(a)common-lisp.net > To: > Date: > Subject: confirm c133299de2b1ebf623d1c8e5ce04db0e85ab23b7 > If you reply to this message, keeping the Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply. >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

usocket-devel September 2008