One more request:<div><br></div><div>Is there any way of having a timeout on socket-receive? Or at least have some way of checking whether there is any data waiting (so I don't have to block while waiting for packets to arrive)?</div>
<div><br></div><div>Thanks.<br><br><div class="gmail_quote">On Wed, Jan 13, 2010 at 6:02 PM, Elliott Slaughter <span dir="ltr"><<a href="mailto:elliottslaughter@gmail.com">elliottslaughter@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im">On Thu, Jan 7, 2010 at 11:02 AM, Chun Tian (binghe) <span dir="ltr"><<a href="mailto:binghe.lisp@gmail.com" target="_blank">binghe.lisp@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, usocket users<br>
<br>
I want to mention, the "experimental-udp" branch has been merged into usocket trunk.<br>
<br>
Changed API:<br>
<br>
[SOCKET-CONNECT]<br>
<br>
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.<br>
<br>
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:<br>
<br>
(SOCKET-CONNECT NIL NIL :PROTOCOL :DATAGRAM)<br></blockquote><div><br></div></div><div>It isn't clear to me how unconnected UDP sockets are to be used, since the host and port are unspecified. I would expect that most users would always want to use connected sockets.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
(SOCKET-CONNECT NIL NIL :PROTOCOL :DATAGRAM :LOCAL-HOST nil :LOCAL-PORT 10000)<br>
<br>
Notice: the "nil" as LOCAL-HOST means that you listen on wildcard address "0.0.0.0", same effect as *wildcard-host*.<br>
<br>
[SOCKET-SEND]<br>
<br>
Syntax: SOCKET-SEND usocket buffer length &key host port<br>
<br>
SOCKET-SEND is used for sending packets through a UDP usocket, the "buffer" arguments usually need to be a vector of (unsigned-byte 8).<br></blockquote><div><br></div></div><div>What does the return value of socket-send mean?</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[SOCKET-RECEIVE]<br>
<br>
Syntax: SOCKET-RECEIVE usocket buffer length &key<br>
<br>
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+.<br>
</blockquote><div><br></div></div><div>The constant +max-datagram-packet-size+ is not exported from the usocket package, and seems to be unbound when I try to access it.</div><div><br></div><div>When I try to call socket-receive with both buffer and length nil, it complains that they can't both be nil. I was under the impression that if I left both as nil then it would create a buffer of size +max-datagram-packet-size+.</div>
<div><div></div><div class="h5">
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
1. buffer (the same object as the "buffer" argument if it's not NIL when calling SOCKET-RECEIVE)<br>
2. size (how many bytes received)<br>
3. host (which address this data from)<br>
4. port (which IP port this data from)<br>
<br>
[SOCKET-SERVER]<br>
<br>
Syntax: SOCKET-SERVER host port function &optional arguments &key (timeout 1) (max-buffer-size +max-datagram-packet-size+)<br>
<br>
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.<br>
<br>
The arguments "function" and "arguments" controls your UDP server's function, declaration of this function:<br>
<br>
function (data &optional arguments)<br>
<br>
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:<br>
<br>
(defun echo-function (data)<br>
data)<br>
<br>
And following code created this server on local port 10000:<br>
<br>
(socket-server nil 10000 #'echo-function)<br>
<br>
What if your filter function need to know where the data from? Get this information from two special variables: *REMOTE-HOST* and *REMOTE-PORT*.<br>
<br>
The argument "timeout" can control the loop frequency, usually no need to modify. Read "server.lisp" for details.<br>
<br>
<br>
The last important thing USOCKET user need to know: UDP support haven't been done on all CL platforms.<br>
<br>
Current finished supported CL platforms:<br>
<br>
* CMUCL<br>
* SBCL and ECL (not on win32)<br>
* Allegro CL<br>
* LispWorks (not on win32)<br>
* SCL<br>
* Clozure CL<br>
<br>
Unfinished CL platforms:<br>
<br>
* CLISP<br>
* Armedbear Common Lisp (ABCL)<br>
* Macintosh Common Lisp (MCL/RMCL)<br>
<br>
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.<br>
<br>
Bug reports, optimization suggestions, patches on unfinished platforms are all welcome. Thank you for using USOCKET project.<br></blockquote></div></div></div><div><br></div><div>Thanks for working on this. I'm eagerly awaiting full compatibility win32 implementations.</div>
<br><font color="#888888">-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Elliott Slaughter<br><br>"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay<br>
</div>