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

[usocket-devel] Release 0.4.0
by Erik Huelsmann 29 Oct '08

29 Oct '08

I'm happy to be able to release usocket 0.4.0. The major point in this release is the availability of the WAIT-FOR-INPUT function, which allows waiting (with or without timeout) for any number of sockets to become active for input. This means one can either accept a new connection from a server socket or read input off a stream socket. The API documentation page on the website still needs to be updated for the additional external symbols. (Any takers?) If you want to download this release, please check out http://common-lisp.net/project/usocket/releases/ A number of smaller features (options to SOCKET-CONNECT) have also been added, however, these may not be available on all implementations: * :no-delay, which disables Naggle's algorithm * :timeout, which sets a per-operation timeout on the socket * :deadline, which sets a maximum life-time to the socket * :local-host, which determines which interface is to be used locally * :local-port, which determines which port is to be used locally As always, any feedback - bugs or hugs - is greatly appreciated. If you use usocket, please let us know what for! Bye, Erik.

4 6

[usocket-devel] usocket on LispWorks (non-win32 and no multiprocessing)
by Chun Tian (binghe) 21 Oct '08

21 Oct '08

Hi, usocket-devel (testing 0.4 branch) In LispWorks Professional and Enterprise Edition, user can save a image without thread support. When such a lispworks image started, all function in MP package is there but no thread running: binghe@binghe-debian:~$ lispworks-cli LispWorks(R): The Common Lisp Programming Environment Copyright (C) 1987-2008 LispWorks Ltd. All rights reserved. Version 5.1.1 Saved by binghe as lispworks-5-1-1-64-bit-cli, at 12 Jun 2008 14:50 User binghe on binghe-debian.local CL-USER 1 > (mp:list-all-processes) NIL CL-USER 3 > mp:*current-process* NIL When there's no thread support in LispWorks, USOCKET:WAIT-FOR-INPUT cannot be used (on non-win32 platform) because it calls MP:PROCESS- WAIT on current thread, that will cause a UNKNOWN-ERROR: USOCKET 9 > (wait-for-input x) Error: The condition #<UNKNOWN-ERROR 405008A5B0> occurred 1 (abort) Return to level 0. 2 Restart top-level loop. Type :b for backtrace, :c <option number> to proceed, or :? for other options USOCKET 10 : 1 > :b Call to ERROR Call to RAISE-USOCK-ERR Call to SIGNAL Call to ERROR Call to MP::WITHOUT-PREEMPTION-ERROR Call to MP:PROCESS-WAIT Call to WAIT-FOR-INPUT-INTERNAL Call to WAIT-FOR-INPUT Call to WAIT-FOR-INPUT Call to EVAL I think may be there're some way not use MP-related function to achieve the same effect, i.e. direct call select() or turn to use LispWorks' SYS:WAIT-FOR-INPUT-STREAMS [1] instead (which works on all platform include win32 but just for stream usocket). Regards, Chun Tian (binghe) [1] http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-765.htm#pgfId-1…

2 2

[usocket-devel] Please test 0.4.x branch
by Erik Huelsmann 20 Oct '08

20 Oct '08

In preparation of a release, I've merged some changes from trunk/ to 0.4.x in order to make them appear in 0.4.0. However, to be sure that 0.4.0 actually WORKS, please check out the branch and test your applications with that version; any results (success *and* failure) can be reported to this list. Thanks in advance! Bye, Erik.

1 0

Re: [usocket-devel] Scieneer Common Lisp
by Chun Tian (binghe) 18 Oct '08

18 Oct '08

Hi Douglas Yes, the CMUCL port is already done. Though SCL is derived from CMUCL, the sockets API between them is a little different, some points I can list below (so far): 1) CMUCL already support basic UDP networking, it has three necessary UDP-related functions: EXT:INET-SENDTO, EXT:INET-RECVFROM, EXT:INET-SHUTDOWN, just direct mapping of UNIX sendto(), recvfrom(), and shutdown() SCL manual doesn't say about these functions, by actual running SCL, I think they're not exist (and should be added). SCL already have EXT:CREATE-INET-SOCKET function, I think it's useless for TCP users because they usually only care a TCP connection as a stream. But for UDP networking, it's essential. I should mention that: even SCL doesn't make any change, support UDP in SCL should be possible: we can always export these unix function through FFI (more code but should work), just like what I do for LispWorks (completely no UDP support in LW, but I wrote one from scratch). 2) The EXT:CONNECT-TO-INET-SOCKET function would be better if add two new keywords: LOCAL-HOST and LOCAL-PORT, this is not for UDP but TCP: sometimes user want to bind to specified local address/port when connect to remote address/port. Almost all other CL platform's sockets API support this. See following discuss on usocket mailing list: http://thread.gmane.org/gmane.lisp.usocket.devel/40 Days later, CMUCL author (Raymond Toy) added all I want in CMUCL 2008-08 snapshot, see this link (cvs diff) http://common-lisp.net/cgi-bin/viewcvs.cgi/src/code/internet.lisp?root=cmuc… I hope SCL could make a similar code change like above (if possible). Regards, Chun Tian (binghe) > Hello Chun, > > I would be happy to write the SCL port which would be easy if the > CMUCL > port was already done? > > Regards > Douglas Crosher > > Chun Tian (binghe) wrote: >> Hi, Douglas >> >> Thanks very much! I'll investigate the SCL sockets API and give a >> report >> days later, and tell you what to be added into SCL to support the new >> USOCKET package with UDP. >> >> Regards,

1 0

Re: [usocket-devel] Scieneer Common Lisp
by Chun Tian (binghe) 18 Oct '08

18 Oct '08

Hi, Douglas Thanks very much! I'll investigate the SCL sockets API and give a report days later, and tell you what to be added into SCL to support the new USOCKET package with UDP. Regards, Chun Tian (binghe) > Hello Chun, > > If I can be of any assistance with the ports then please let me know. > The SCL can be extended to support UDP if necessary. > > Regards > Douglas Crosher > > Chun Tian (binghe) wrote: >> Hi, Douglas Crosher >> >> I try them mainly for porting some CL packages to SCL. Currently I'm >> mainly working with Erik Huelsmann on USOCKET [1] project to bring >> UDP >> networking support into this portable networking package. >> >> And I myself also have a portable SNMP [2] (client & server) project >> which want to port to SCL. In passed years I wrote a SNMP client for >> retrieve remote status of UNIX server and a SNMP server which can be >> used for monitor remote large Common Lisp applications. I hear SCL >> mainly used in this area. >> >> Regards, >> >> Chun Tian (binghe) >> >> [1] http://common-lisp.net/project/usocket >> [2] http://sourceforge.net/projects/cl-net-snmp >> >> 在 2008-10-17，15:46， Douglas Crosher 写道： >> >>> Hello Chun, >>> >>> Thank you for your interest. You may now download and configure the >>> Scieneer CL >>> via your account. The direct links to the entitlements are: ... >>> >>> You may also be interested in the freeware collection which has a >>> number of >>> open source libraries that have been ported to the SCL, see: >>> https://www.scieneer.com/scl/support/freeware.html >>> >>> Scieneer has only recently made the SCL available for noncommercial >>> use, and if you >>> happen to encounter any difficulties then could you please let me >>> know >>> so it can be >>> corrected and improved. >>> >>> If you have any feedback on the SCL, or any questions, then please >>> also let me know. >>> Thank you again for your interest. >>> >>> Regards >>> Douglas Crosher >> >> >

1 0

[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] Request for new experimental branch about UDP and others
by Chun Tian (binghe) 03 Oct '08

03 Oct '08

Hi, usocket devel (Erik and Hans) (sorry for my poor English first) As you guys already know, I'm working on some UDP-relate packages' development, and already got a working UDP patch for usocket project. I also want to do more on this area (portable Common Lisp networking), following is my interesting part: * UDP (already have some code) * ICMP (ping) * UDP Multicasting * UNIX Domain Socket (AF_LOCAL) I want to stay in the framework which USOCKET already have, and try to extensive it to support more features. Erik agreed to give me SVN commit access and now I wish to open a new branch for above experimental work. As the first mission, I'll merge all my UDP patch into this new branch. I think a branch with name "udp" or "binghe" (like the "hans" branch before) will be OK, but as a new member I don't think I should make this branch by my self (that's not quite polite, I think). So I'm looking for opinions or a branch made by Erik for me to commit codes. Regards, Chun Tian (binghe)

2 4

[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

Re: [usocket-devel] Compile failure on CLISP 2.46
by Leslie P. Polzer 01 Oct '08

01 Oct '08

>> So the libc6 statement would work for 99% of UNIX users > > Unix or Linux? What statement would we need on Solaris/ *BSD? I don't have boxes to check on, but I suppose libc6.so is pretty safe for UNIX. >> whereas the current situation works for 0% of CLISP users. > > Well, if it really didn't work, I wouldn't have included it in the > distribution. Sorry for the bold statement. :) > It's definitely working for me: Debian/Etch on x86. Are > any of you also using Debian yet experiencing problems? I'm using ArchLinux. What does ls /lib/libc* give you? Maybe I'm missing a symbolic link? Leslie -- LinkedIn Profile: http://www.linkedin.com/in/polzer Xing Profile: https://www.xing.com/profile/LeslieP_Polzer Blog: http://blog.viridian-project.de/

3 3