usocket-devel

usocket-devel@common-lisp.net

248 discussions

Re: [usocket-devel] Status of UDP on Windows?
by Elliott Slaughter 03 Apr '10

03 Apr '10

It seems that your response missed the mailing list. 2010/3/22 Chun Tian (binghe) <binghe.lisp(a)gmail.com> Strange ... for long time I thought there's no "select()" on win32, and I do > see Erik (USOCKET author) use "WSAEventSelect" to implement the LispWorks > version of WAIT-FOR-INTPUT-INTERNAL on win32. Now it seems that I was > confused by another the speciality of "select()" function on win32: > > * On UNIX, select() can be used to wait for both networking sockets and > disk file handlers, > * On Windows, select() can only be used on networking sockets, so it's > implemented by winsock library. > > What you found, seems show me a very direct way to have all you want done > immediately: just use SB-ALIEN to export the "select()" for win32, and > remove the reader macro around exist Unix version of WAIT-FOR-INPUT-INTERNAL > for SBCL. > > Would you like a try on this approach? > I'll give it a shot. Thanks (to both you and Erik) for the information. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

1 2

[usocket-devel] Announcing ip-interfaces (was: Re: Determining the local host address from wildcard host)
by Elliott Slaughter 02 Apr '10

02 Apr '10

On Mon, Mar 8, 2010 at 12:08 PM, Elliott Slaughter < elliottslaughter(a)gmail.com> wrote: > On Mon, Mar 8, 2010 at 10:50 AM, R. Matthew Emerson <rme(a)clozure.com>wrote: > >> >> On Mar 7, 2010, at 2:36 PM, Elliott Slaughter wrote: >> >> > What I am actually trying to do is to search for other nodes on the >> local network which are also running my application. My idea was to >> construct one or more broadcast addresses, send UDP packets to each of them, >> and listen for responses. This may not be the best way to go about this (and >> suggestions would be appreciated), but if I choose this route, I would want >> to know the IP address of each of the interfaces together with its subnet >> mask. >> > >> > On 2010-03-07, at 07:20 , Elliott Slaughter wrote: >> > >> > if you really need this, you might look at the implementation for >> %get-ip-interfaces in clozure. >> > it uses getifaddrs in a fairly transparent manner, so, if you're >> unix-based, you should be ok with it. >> > >> > I need this to work on Windows and *nix, which is why I can't use IOlib >> or other Unix-based solutions. That said, Clozure does run on Windows, so >> hopefully the code you mentioned has already been ported. >> >> There's an internal function ccl::%get-ip-interfaces that's >> conditionalized for a bunch of platforms. I can't really recommend that you >> use it, of course, but it might be something to look at. >> > > I glanced over the source briefly, and might give porting it to CFFI a shot > when I can find some free time. > I've ported the code to CFFI, and tested on SBCL, CCL, ECL, and Allegro on Mac OS X, SBCL on Linux, and SBCL on Windows. The source code is available as a darcs repository at: http://common-lisp.net/~eslaughter/darcs/ip-interfaces/ The code is licensed under the LLGPL to maximize license compatibility with Clozure CL. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

1 1

[usocket-devel] Status of UDP on Windows?
by Elliott Slaughter 22 Mar '10

22 Mar '10

Hi, I would really like to use UDP sockets on Windows, so I'm wondering if someone can tell me what needs to be done for it to work on a minimal set of platforms (at least SBCL, and Clozure CL would be nice). I am willing to contribute time and code for the next week or so if someone can direct me to what needs work. Thanks. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

3 4

Re: [usocket-devel] Determining the local host address from wildcard host
by Elliott Slaughter 08 Mar '10

08 Mar '10

On Sun, Mar 7, 2010 at 8:02 AM, james anderson <james.anderson(a)setf.de>wrote: > good evening; > > i asked chun tian about this some while ago and he didn't think it was > necessary as the 0.0.0.0 address suffices for most purposes. > Yes, for listening for messages, the 0.0.0.0 is quite sufficient. What I am actually trying to do is to search for other nodes on the local network which are also running my application. My idea was to construct one or more broadcast addresses, send UDP packets to each of them, and listen for responses. This may not be the best way to go about this (and suggestions would be appreciated), but if I choose this route, I would want to know the IP address of each of the interfaces together with its subnet mask. On 2010-03-07, at 07:20 , Elliott Slaughter wrote: > > if you really need this, you might look at the implementation for > %get-ip-interfaces in clozure. > it uses getifaddrs in a fairly transparent manner, so, if you're > unix-based, you should be ok with it. > I need this to work on Windows and *nix, which is why I can't use IOlib or other Unix-based solutions. That said, Clozure does run on Windows, so hopefully the code you mentioned has already been ported. I'm wondering if there is any way to determine the local host address (or >> addresses) used when I create a socket with :local-host *wildcard-host* . >> When I try to call get-local-address on such a socket, I just get #(0 0 0 >> 0). >> >> Thanks. >> > -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

4 4

[usocket-devel] Determining the local host address from wildcard host
by Elliott Slaughter 07 Mar '10

07 Mar '10

Hi, I'm wondering if there is any way to determine the local host address (or addresses) used when I create a socket with :local-host *wildcard-host* . When I try to call get-local-address on such a socket, I just get #(0 0 0 0). Thanks. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

4 7

[usocket-devel] ECL support
by Marko Kocić 16 Feb '10

16 Feb '10

Hi all, what is the status of latest ECL support in usocket? By running tests it seems that some stuff is not supported yet. I'm trying to get hunchentoot to run with ECL, managed to make it compile hunchentoot with some patches, but when running it fails in usocket:wait-for-input-internal. If someone is interested to give it a try, I can send WIP hunchentoot patch. Regards, Marko Kocić

3 6

[usocket-devel] license verification for inclusion in de.setf.amqp
by james anderson 15 Feb '10

15 Feb '10

good morning; i have released a library, de.setf.amqp[1], which incorporates work of yours. the combined license is the gnu affero. please see the readme[2] for more information. this is to verify the contact information for your library's license. yours is the last respective contact. in some cases, there was none and i have substituted a mailing list as an immediate place-holder, even though, as subscription-only lists, it is not well suited to this purpose. please advise me, should an alternative contact be available. [1] : http://github.com/lisp/de.setf.amqp [2] : http://github.com/lisp/de.setf.amqp/blob/master/README.md

3 2

[usocket-devel] "experimental-udp" branch merged into usocket trunk
by Chun Tian (binghe) 14 Jan '10

14 Jan '10

Hi, usocket users I want to mention, the "experimental-udp" branch has been merged into usocket trunk. Changed API: [SOCKET-CONNECT] SOCKET-CONNECT now has a new keyword argument PROTOCOL with default :STREAM as tcp, but if you set it to :DATAGRAM, this means you're creating a UDP socket. Be different with TCP socket, a UDP socket can be connected or unconnected. The method to create a unconnected UDP socket is to leave the first two argument of SOCKET-CONNECT as NIL: (SOCKET-CONNECT NIL NIL :PROTOCOL :DATAGRAM) Creating a server UDP socket which "listen" on local address is also supported, the method is to set additional keyword arguments: LOCAL-HOST and LOCAL-PORT: (SOCKET-CONNECT NIL NIL :PROTOCOL :DATAGRAM :LOCAL-HOST nil :LOCAL-PORT 10000) Notice: the "nil" as LOCAL-HOST means that you listen on wildcard address "0.0.0.0", same effect as *wildcard-host*. [SOCKET-SEND] Syntax: SOCKET-SEND usocket buffer length &key host port SOCKET-SEND is used for sending packets through a UDP usocket, the "buffer" arguments usually need to be a vector of (unsigned-byte 8). [SOCKET-RECEIVE] Syntax: SOCKET-RECEIVE usocket buffer length &key SOCKET-RECEIVE is used for receiving packets from a UDP usocket, the "buffer" argument will be filled into received data, but if you give NIL, this function will create a new buffer object for holding received data, the default buffer length will be 65536 which defined as a constant +max-datagram-packet-size+. Notice: if you use this function to receive data from a unconnected socket, you may need to know where the data from. Actually, SOCKET-RECEIVE will return multiple values, the exact number is 4: 1. buffer (the same object as the "buffer" argument if it's not NIL when calling SOCKET-RECEIVE) 2. size (how many bytes received) 3. host (which address this data from) 4. port (which IP port this data from) [SOCKET-SERVER] Syntax: SOCKET-SERVER host port function &optional arguments &key (timeout 1) (max-buffer-size +max-datagram-packet-size+) SOCKET-SERVER can create a simple single-threaded UDP server. This function is a indefinite loop, so you should create it in a new created thread using your platform's thread API. The arguments "function" and "arguments" controls your UDP server's function, declaration of this function: function (data &optional arguments) This function will work like a filter, received data in, and return data send out. For example, a UDP Echo server can be defined in following code: (defun echo-function (data) data) And following code created this server on local port 10000: (socket-server nil 10000 #'echo-function) What if your filter function need to know where the data from? Get this information from two special variables: *REMOTE-HOST* and *REMOTE-PORT*. The argument "timeout" can control the loop frequency, usually no need to modify. Read "server.lisp" for details. The last important thing USOCKET user need to know: UDP support haven't been done on all CL platforms. Current finished supported CL platforms: * CMUCL * SBCL and ECL (not on win32) * Allegro CL * LispWorks (not on win32) * SCL * Clozure CL Unfinished CL platforms: * CLISP * Armedbear Common Lisp (ABCL) * Macintosh Common Lisp (MCL/RMCL) And the USOCKET-UDP [1] project will be just closed. The function SOCKET-SYNC in that project will not be merged into USOCKET trunk because of less useful in most cases. Bug reports, optimization suggestions, patches on unfinished platforms are all welcome. Thank you for using USOCKET project. Regards, Chun Tian (binghe) [1] http://common-lisp.net/projects/cl-net-snmp/usocket.html

2 6

[usocket-devel] wait-for-input support on SBCL/Windows
by Elliott Slaughter 13 Jan '10

13 Jan '10

Hi, I noticed while reading sbcl.lisp that wait-for-input is not yet implemented on Windows. I'm wondering whether anyone is working on this and/or what it would take to get this working. Thanks. -- Elliott Slaughter "Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay

2 1

[usocket-devel] nameserver errors on Clozure CL
by R. Matthew Emerson 13 Jan '10

13 Jan '10

Some recent changes to the Clozure CL trunk (starting with http://trac.clozure.com/ccl/changeset/13377) try to report nameserver errors in the socket-creation-error condition object. Something like the crude attached patch would update the Clozure CL usocket backend to report these nameserver errors.

2 4

← Newer
1
...
9
10
11
12
13
14
15
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

usocket-devel