$Id: api-docs.shtml 417 2008-08-07 20:29:51Z
+ehuelsmann $
+Work in progress.
Please note that we're committed to the interface described
-below for the entire 0.x phase of the library. When 1.0 comes
+below for the entire 0.x phase of the library. When 1.0 comes
some of the functionality may be split up in different functions
and guarantees may change because of it.
-
-
Conventions
-
-
-
Specification of a host parameter
-
A host parameter may be any one of
+
Specification of a host parameter
+
A host parameter may be any one of
-
32-bit positive integer,
-
a string containing an IP addres in dotted notation, or
-
a host name to be resolved through DNS lookup.
+
32-bit positive integer,
+
a string containing an IP addres in dotted notation, or
+
a host name to be resolved through DNS lookup.
-
+
-
Functions for socket creation and manipulation
-
-
socket-connect host port &key element-type => socket
Creates a TCP (stream) or UDP (datagram) socket to the host
+and port specified. The return value is
+a socket object of class stream-usocket,
+or
-
-
Creates a tcp (stream) socket to the host and port specified. The return value is
-a socket object of class stream-usocket.
-
-
The element-type argument is used in the
-construction of the associated stream.
-
-
-socket-listen host port &key reuse-address backlog element-type => socket
-
Creates and returns a passive ("server") socket associated with host and port.
- The object returned is of subtype stream-server-usocket.
-
host names a local interface.
- port names a local port, or 0 (zero) to request a random free port.
- reuse-address is a boolean (t, nil) value signalling reuse of the address is requested (or not).
- backlog is the length of the queue containing connections which haven't actually been accepted yet.
- element-type is the default element type used for sockets created by socket-accept. character is
- the default when it's not explicitly provided.
-
Creates and returns an active ("connected") stream socket new-socket from the
- socket passed. The return value is a socket object of class
- stream-usocket.
-
element-type is the element type used to construct the associated stream. If it's not specified,
- the element-type of socket (as used when it was created by the call to socket-listen) is
- used.
+
+
+ datagram-usocket.
+
protocol should be :stream (default) or :datagram,
+which
+means
+TCP
+or
+UDP. (Start from USOCKET 0.5)
+ element-type argument is used in the
+construction of the associated stream, i.e. 'character or
+ '(unsigned-byte 8), only used by TCP.
+ timeout is a integer, it represents the socket option SO_RCVTIMEO
+(read timeout), in seconds.
+ deadline is only supported in Clozure CL and Digitool MCL,
+look up their documents please.
+ local-host and local-port, when specified, will
+cause the socket calling bind() on local address. This is useful for
+selecting interfaces to send, or listening on UDP port. Note: use only
+one of them are allowed when reasonable (listen on wildcard address, or
+bind to random free port).
+
+
+
+
socket-listen
+host port &key reuse-address backlog element-type => socket
+
+
Creates and returns a passive ("server") socket associated with host
+and port. The object returned is of subtype stream-server-usocket.
+
host names a local interface.
+ port names a local port, or 0 (zero) to request a random
+free port.
+ reuse-address is a boolean (t, nil) value signalling reuse
+of the address is requested (or not).
+ backlog is the length of the queue containing connections
+which haven't actually been accepted yet.
+ element-type is the default element type used for sockets
+created by socket-accept. character is the default when it's
+not explicitly provided.
Creates and returns an active ("connected") stream socket new-socket
+from the socket passed. The return value is a socket object
+of class stream-usocket.
+
element-type is the element type used to construct the
+associated stream. If it's not specified, the element-type of socket
+(as used when it was created by the call to socket-listen) is used.
+
+
socket-close
+socket
+
+
Flushes the stream associated with the socket and closes the
+socket connection.
+
+
get-local-name
+socket => address, port
+ get-local-address
+socket => address
+ get-local-port
+socket => port
+
+
Returns the local address and/or port information of socket.
+
+
get-peer-name
+socket => address, port
+ get-peer-address
+socket => address
+ get-peer-port
+socket => port
+
+
Returns the remote address and/or port information of socket.
+The socket passed to this function must be a connected socket.
+
+
socket-send
+socket buffer length &key host port
+
+
+
Send a (unsigned-byte 8) data buffer to a datagram socket, and
+return the number of bytes sent. (Start from USOCKET 0.5)
+
socket should be a datagram-usocket.
+ buffer is a Lisp vector, type of (simple-array
+(unsigned-byte 8) *).
+ length is used to tell socket-send
+the actual useful length of data buffer for sending to socket.
+ host and port are used for unconnected datagram
+sockets, for sending to specific destination.
-
+
+
socket-receive
+socket buffer length
+
+
+
Receive data from a datagram socket, and return 4 values: return-buffer,
-
socket-close socket
-
Flushes the stream associated with the socket and closes the socket connection.
-
get-local-name socket => address, port
-get-local-name socket => address
-get-local-port socket => port
-
Returns the local address and/or port information of socket.
-
-
get-peer-name socket => address, port
-get-peer-name socket => address
-get-peer-port socket => port
-
Returns the remote address and/or port information of socket.
- The socket passed to this function must be a connected socket.
+ return-length, remote-host, and remove-port.
+If
+the
+datagram
+socket
+was created by socket-connect
+with a timeout keyword argument, this function will block at
+most that timeout value (in seconds). (Start from USOCKET 0.5)
+
socket should be a datagram-usocket.
+ buffer is a Lisp vector, type of (simple-array
+(unsigned-byte 8) *). Using nil here is also
+allowed, new buffer will be created to hold data.
+ length is used to specify the length of a exist buffer for
+receiving at most these data. Using nil here is allowed, and
+the actual length of buffer will be used; when buffer
+is also nil, a default maximum length (65507) will be
+used.
+
Waiting on one or multiple sockets for given time, and returns
+once some of them are available of reading data. This is like UNIX's
+"select" function.
+
+It returns two values: the first is the list of sockets which are
+readable (or in case of server sockets acceptable). nil may be returned
+for this value either when waiting timed out or when it was interrupted
+(EINTR). The second value is a real number indicating the time
+remaining within the timeout period or nil if none.
+
+Without the READY-ONLY arg, WAIT-FOR-INPUT will return all sockets in
+the original list you passed it. This prevents a new list from being
+consed up. Some users of USOCKET were reluctant to use it if it
+wouldn't behave that way, expecting it to cost significant performance
+to do the associated garbage collection.
+
+Without the READY-ONLY arg, you need to check the socket STATE slot for
+the values documented in usocket.lisp in the usocket class.
+
+
+
socket-server
+host port function &optional arguments &key in-new-thread
+protocol timeout max-buffer-size element-type reuse-address
+multi-threading
+
+
+
Create a simple TCP or UDP socket server ... (Start from USOCKET
+0.5)
Indicates the default element-type to be used when
+constructing streams off this socket when no element type is specified
+in the call to socket-accept.
Indicates the default element-type to be used when constructing streams off this socket when
- no element type is specified in the call to socket-accept.
The host to use with socket-listen to make the socket listen on all available interfaces.
-
*auto-port*
-
The port number to use with socket-listen to make the socket listen on a random available port. The port number assigned can be
- retrieved from the returned socket by calling get-local-port.
+
*wildcard-host*
+
+
The host to use with socket-listen
+to make the socket listen on all available interfaces.
+
+
*auto-port*
+
+
The port number to use with socket-listen to make the socket
+listen on a random available port. The port number assigned can be
+retrieved from the returned socket by calling get-local-port.
+
+
*remote-host*
+
+
Special variable used in socket-server's
+handler function for getting current client address. (Start from
+USOCKET 0.5)
+
+
+
*remote-port*
+
+
Special variable used in socket-server's
+handler function for getting current client port. (Start from USOCKET
+0.5)
... force the output to be written to the network?
-
-
When you write output to the stream, it may be buffered before
- sent over the network - for optimal performance of small writes. You
- can force the buffer to be flushed the same way as with normal streams:
-
-
(format (socket-stream socket) "Hello there~%") ;; output into buffers
-(force-output (socket-stream socket)) ;; <== flush the buffers, if any
-
-
-
... check whether the other end has closed my socket stream?
-
-
Reading from a stream which has been closed at the remote end
- signals an END-OF-FILE condition, meaning that reading from the stream
- and detecting that condition is the way to do it.
-
-
... check whether reading from a socket stream will block?
-
-
When you want to check one stream for readiness of input,
- call the
- listen
- function on the stream object associated with the socket.
- Example:
-
(listen (usocket:socket-stream your-socket))
- ==> NIL (if no input is available)
-
-
-
... wait for input to become available on (at least) one stream (of a set)
-
-
Currently, that's hard to do efficiently if you want to use releases.
- The next minor release (0.4.0) will include this functionality and
- for all platforms (except SBCL and LispWorks; both Win32) it's already
- available in trunk (svn://common-lisp.net/project/usocket/svn/usocket/trunk).
-
- If you want to use this code you're most welcome and feedback is appreciated.
- Example to be used with trunk:
-
... convert my existing trivial-sockets based application to usocket?
-
-
There are actually 3 answers to that question.
-
-
Rewrite your code to keep a usocket object instead of the stream
- object returned by trivial-sockets.
-
The quick conversion with the good performance characteristics
- (use only when you don't want to use the socket object):
- Replace all your invocations of
-
... force the output to be written to the network?
+
When you write output to the stream, it may be buffered before
+sent over the network - for optimal performance of small writes. You
+can force the buffer to be flushed the same way as with normal streams:
+
(format (socket-stream socket) "Hello there~%") ;; output into buffers (force-output (socket-stream socket)) ;; <== flush the buffers, if any
+
+
... check whether the other end has closed my socket stream?
+
Reading from a stream which has been closed at the remote end
+signals an END-OF-FILE condition, meaning that reading from the stream
+and detecting that condition is the way to do it.
+
... check whether reading from a socket stream will block?
+
When you want to check one stream for readiness of input,
+call the listen
+function on the stream object associated with the socket.
+Example:
+
(listen (usocket:socket-stream your-socket)) ==> NIL (if no input is available)
+
+
... wait for input to become available on (at least) one stream
+(of a set)
+
Currently, that's hard to do efficiently if you want to use
+releases. The next minor release (0.4.0) will include this
+functionality and for all platforms (except SBCL and LispWorks; both
+Win32) it's already available in trunk
+(svn://common-lisp.net/project/usocket/svn/usocket/trunk).
+If you want to use this code you're most welcome and feedback is
+appreciated.
+Example to be used with trunk:
+
... convert my existing trivial-sockets based application to
+usocket?
+
There are actually 3 answers to that question.
+
+
Rewrite your code to keep a usocket object instead of the
+stream object returned by trivial-sockets.
+
The quick conversion with the good performance
+characteristics (use only when you don't want to use the socket object):
+Replace all your invocations of
+
(trivial-sockets:open-socket-stream ....)
with (usocket:socket-stream (usocket:socket-connect ...))
And the last option which provides a compatible
- (but slower, because it uses Gray streams) interface is to use
- trivial-usocket.
- The trivial-usocket package provides a 1-1 mapped interface to
- trivial-sockets, but uses Gray streams; that way, it's later possible
- to retrieve the socket object from the stream returned and to use that
- socket for other usocket operations. Use this approach as a migration
- path where you're not rewriting your application at once, but in
- small steps.
+
(trivial-sockets:open-server ...)
with (usocket:socket-listen ...)
+
And the last option which provides a compatible (but slower,
+because it uses Gray streams) interface is to use trivial-usocket.
+The trivial-usocket package provides a 1-1 mapped interface to
+trivial-sockets, but uses Gray streams; that way, it's later possible
+to retrieve the socket object from the stream returned and to use that
+socket for other usocket operations. Use this approach as a migration
+path where you're not rewriting your application at once, but in small
+steps.
Please note that we're committed to the interface described
below for the entire 0.x phase of the library. When 1.0 comes
@@ -44,10 +43,15 @@
and guarantees may change because of it.
Conventions
-
Specification of a host parameter
-
A host parameter may be any one of
+
Specification of a host or local-host
+parameter
+
A host or local-host parameter may be any one
+of
32-bit positive integer,
+
A four element integer list representing IPv4 address, i.e.
+#(127 0 0 1)
+
a string containing an IP addres in dotted notation, or
a host name to be resolved through DNS lookup.
@@ -63,16 +67,13 @@
and port specified. The return value is
a socket object of class stream-usocket,
or
-
-
-
datagram-usocket.
protocol should be :stream (default) or :datagram,
which
means
TCP
or
-UDP. (Start from USOCKET 0.5)
+UDP (Start from USOCKET 0.5) element-type argument is used in the
construction of the associated stream, i.e. 'character or
'(unsigned-byte 8), only used by TCP.
@@ -169,7 +170,13 @@
the
datagram
socket
-was created by socket-connect
+was
+created
+by
+
+
+
+ socket-connect
with a timeout keyword argument, this function will block at
most that timeout value (in seconds). (Start from USOCKET 0.5)
socket should be a datagram-usocket.
@@ -197,14 +204,16 @@
(EINTR). The second value is a real number indicating the time
remaining within the timeout period or nil if none.
-Without the READY-ONLY arg, WAIT-FOR-INPUT will return all sockets in
+Without the ready-only argument, WAIT-FOR-INPUT will return
+all sockets in
the original list you passed it. This prevents a new list from being
consed up. Some users of USOCKET were reluctant to use it if it
wouldn't behave that way, expecting it to cost significant performance
to do the associated garbage collection.
-Without the READY-ONLY arg, you need to check the socket STATE slot for
-the values documented in usocket.lisp in the usocket class.
+Without the ready-only arg, you need to check the socket
+STATE slot for
+the values documented in usocket class.
Create a simple TCP or UDP socket server ... (Start from USOCKET
-0.5)
+
Create a simple TCP or UDP socket server. (Start from USOCKET
+0.5)
+
+
host names a local interface,
+ port names a local port,
+ function names a function object, which is used to handle
+TCP or UDP connections, the actual API of this function will be
+explained later.
+ arguments is a list used for passing extra arguments to
+user-defined function.
+ in-new-thread is a boolean, default is nil.
+When it's T, the server will be created in a new thread
+and socket-server returns immediately in current thread.
+ protocol could be either :stream (default)
+or :datagram, which decide the socket server is TCP
+server or UDP server.
+ timeout is UDP only, it provides the internal socket-receive call (in UDP event
+loop of the socket server) a read timeout, default value is 1 (second).
+ max-buffer-size is UDP only, it's the max UDP data buffer
+size when handling UDP packets, default value is 65507.
+ element-type is TCP only, it's element-type of the stream
+provided for user-defined function,
+ reuse-address is TCP only, it's a boolean option for
+internal call of socket-listen in the socket server,
+ multi-threading is TCP only, it's a boolean, default value
+is nil. When it's T, each client connection
+will cause a new thread being created to handle that client, so that
+the TCP server could handle multiple clients at the same time. (Note:
+since UDP server is connectionless, it can always handle multiple
+clients, as long as the handler function run fast enough)
+
+
The handler function for TCP is stream-based. A template
+function
+is this one:
Note: 1. you don't need to close the stream as socket-server
+will do that for you.
+2. More function arguments can be defined, and these extra arguments
+must be feeded as the optional arguments of socket-server.
+
The handler function for UDP is buffer-based, that is,
+you receive a buffer of data as input, and you return another buffer
+for output. A template function is a simple UDP echo server:
Note: 1. data length is the length of the whole buffer. 2.
+Sometimes you may want to know the client's IP address and sending
+port, these informations are specially bounded on variables
+ *remote-host* and *remote-port* when handler function
+is running.
Parent classes: usocket
Slots:
@@ -294,17 +356,29 @@
retrieved from the returned socket by calling get-local-port.
-
*remote-host*
+
*remote-host*
Special variable used in socket-server's
-handler function for getting current client address. (Start from
+handler
+function
+for
+getting
+current
+client
+address. (Start from
USOCKET 0.5)
-
*remote-port*
+
*remote-port*
Special variable used in socket-server's
-handler function for getting current client port. (Start from USOCKET
+handler
+function
+for
+getting
+current
+client
+port. (Start from USOCKET
0.5)
usocket supports more backends than trivial-sockets.
-The latter implements different feature-sets for different backends
+The
+latter
+implements different feature-sets for different backends
while the former supplies consistent functionality for all backends.
@@ -96,7 +96,9 @@
kept up to date, please subscribe
to
-the commit message mailing list. To use the latest development
+the
+commit
+message mailing list. To use the latest development
version, make sure you have Subversion
installed and execute this command:
usocket supports more backends than trivial-sockets.
- The latter implements different feature-sets for different backends while
- the former supplies consistent functionality for all backends.
-
-
-
-
-
Feature
-
In trivial-sockets?
In usocket?
-
ABCL
-
ACL
-
clisp
-
CMUCL
-
LispWorks
-
OpenMCL
-
SBCL
-
overall
-
-
Client side tcp streams
:element-type
-
Yes
-
Yes*
-
Yes
-
Yes
-
Yes
-
Yes*
-
Yes
-
Yes
-
Yes
-
-
-
:external-format
-
No
-
No
-
Yes
-
No
-
No
-
No
-
No
-
No
-
No
-
-
binding local interface/port
-
No
-
Yes
-
No
-
No
-
No
-
Yes
-
Yes
-
No
-
No
-
-
Server socket creation
-
Binding specific local port
-
Yes
-
-
Binding specific local interface
-
No
-
Yes
-
No
-
Yes
-
No
-
Yes
-
Yes
-
No
-
Yes
-
-
Selectable backlog length
-
No
-
Yes
-
No
-
Yes
-
No
-
Yes
-
Yes
-
No
-
Yes
-
-
reuse-address
-
Yes
-
Yes
-
No*
-
Yes
-
Yes
-
Yes
-
Yes
-
No*
-
Yes*
-
-
:element-type for created connections
-
No
-
Yes
-
-
Accepting connections
-
:element-type for created stream
-
Yes
-
Yes*
-
Yes
-
Yes
-
Yes
-
Yes*
-
Yes
-
Yes
-
Yes*
-
-
:external-format for created stream
-
No
-
No
-
Yes
-
No
-
No
-
No
-
No
-
No
-
No
-
-
-
+The latter implements different feature-sets for different backends
+while the former supplies consistent functionality for all backends.
+
+
+
+
+
Feature
+
In trivial-sockets?
+
In usocket?
+
+
+
+
+
ABCL
+
ACL
+
clisp
+
CMUCL
+
LispWorks
+
OpenMCL
+
SBCL
+
overall
+
+
+
Client side tcp streams
+
:element-type
+
Yes
+
Yes*
+
Yes
+
Yes
+
Yes
+
Yes*
+
Yes
+
Yes
+
Yes
+
+
+
:external-format
+
No
+
No
+
Yes
+
No
+
No
+
No
+
No
+
No
+
No
+
+
+
binding local interface/port
+
No
+
Yes
+
No
+
No
+
No
+
Yes
+
Yes
+
No
+
Yes
+
+
+
Server socket creation
+
Binding specific local port
+
Yes
+
+
+
Binding specific local interface
+
No
+
Yes
+
No
+
Yes
+
No
+
Yes
+
Yes
+
No
+
Yes
+
+
+
Selectable backlog length
+
No
+
Yes
+
No
+
Yes
+
No
+
Yes
+
Yes
+
No
+
Yes
+
+
+
reuse-address
+
Yes
+
Yes
+
No*
+
Yes
+
Yes
+
Yes
+
Yes
+
No*
+
Yes*
+
+
+
:element-type for created connections
+
No
+
Yes
+
+
+
Accepting connections
+
:element-type for created stream
+
Yes
+
Yes*
+
Yes
+
Yes
+
Yes
+
Yes*
+
Yes
+
Yes
+
Yes*
+
+
+
:external-format for created stream
+
No
+
No
+
Yes
+
No
+
No
+
No
+
No
+
No
+
No
+
+
-
-
In summary: there are only a very limited number of features you can depend
+
In summary: there are only a very limited number of features you can
+depend
on to work on all platforms supported by trivial-sockets. While usocket
-doesn't support all features, you can depend on the features to be available.
+doesn't support all features, you can depend on the features to be
+available.
Different projects aim at providing TCP/IP sockets portably
-across Common Lisp implementations. The table below summarizes
+across Common Lisp implementations. The table below summarizes
the state of several of these libraries.
The project wants to provide a portable TCP/IP (and later on maybe
-UDP) socket interface for as many Common Lisp implementations as
+
The project wants to provide a portable TCP/IP and UDP/IP socket
+interface for as many Common Lisp implementations as
possible, while keeping the abstraction and portability layer as thin
as possible.
-
Because trivial-sockets
has been declared dead and its author has said he will declare usocket
-its successor if there is a zero effort path of migration, I'm also working
-on trivial-usocket which is supposed to be a sub-optimal, but zero
+its successor if there is a zero effort path of migration, I'm also
+working
+on trivial-usocket which is supposed to be a sub-optimal,
+but zero
effort migration from trivial-sockets.
-
If your lisp isn't mentioned in the list below, please feel free to
submit a request for it at the mailing list mentioned below.
-
Comparison to other socket libraries
-
-
Since usocket is effectively the succesor to trivial-sockets, see the
- feature comparison with
- trivial-sockets in order to find out which one you should use.
-
+
Since usocket is effectively the succesor to trivial-sockets, see
+the feature comparison with
+trivial-sockets in order to find out which one you should use.
After starting the project, many others turned out to have worked on
- something alike, many times as part of a broader project or library.
- Some of them were known at the start of this project, others have
- been conceived after the usocket project already started. Not all of
- them have exactly the same portability goal.
-
+something alike, many times as part of a broader project or library.
+Some of them were known at the start of this project, others have been
+conceived after the usocket project already started. Not all of them
+have exactly the same portability goal.
See the Implementation
- comparison page for a comparison of the portability of other
- libaries and how that relates to usocket.
-
-
+comparison page for a comparison of the portability of other
+libaries and how that relates to usocket.
This project has started Januari 2006. There isn't much of a community
- yet, though I'd like there to be one. So, you're invited to join
- the mailing list, announce yourself and even join the effort!
-
Project tracking happens in the
- project's Trac setup. Please take note of the guidelines before
- entering a bug or enhancement request into the database.
-
-
+
This project has started Januari 2006. There isn't much of a
+community yet, though I'd like there to be one. So, you're invited to
+join the mailing list, announce yourself and even join the effort!
Project tracking happens in the project's Trac setup.
+Please take note of the guidelines before entering a bug or enhancement
+request into the database.
Development will at least follow the steps outlined below.
- Yet to be determined is whether the currently mentioned steps will
- be enough to release version 1.0. Possibly, UDP sockets remain to be
- addressed before doing 1.0; that will depend on your reactions :-)
-
-
The targeted implementations listed in the status table below are not
- a final list: others can be added if/when the need or interest arrises.
-
Please send patches, bug reports and suggestions to the development
- mailing list address given above. The table below indicates the
- current state of development.
-
Development will at least follow the steps outlined below. Yet to be
+determined is whether the currently mentioned steps will be enough to
+release version 1.0. Possibly, UDP sockets remain to be addressed
+before doing 1.0; that will depend on your reactions :-)
+
The targeted implementations listed in the status table below are
+not a final list: others can be added if/when the need or interest
+arrises.
Please send patches, bug reports and suggestions to the development
+mailing list address given above. The table below indicates the current
+state of development.
The interfaces currently published in the :export part of the
package definition are guaranteed to stay compatible for the
-entire 0.x lifecycle. Extention in a backward compatible way is
+entire 0.x lifecycle. Extention in a backward compatible way is
ofcourse valid, as is the addition of new interface functions.
Releases are uploaded to the releases/
- directory. You can find short descriptions in the table below:
-
+directory. You can find short descriptions in the table below:
-
Release history
-
Date
Release
Summary
-
Dec 27, 2008
-
0.4.1
-
fixes for ECL, LispWorks, SBCL, SCL
-
Oct 28, 2008
-
0.4.0
-
select()-like api: make a single thread wait for multiple sockets.
- various socket options for socket-creation with SOCKET-CONNECT.
-
-
Jun 21, 2008
-
0.3.6
-
Code fixups based on advice from the ECL and OpenMCL maintainers.
- New exported symbols: WITH-MAPPED-CONDITIONS, NS-CONDITION,
- NS-ERROR, NS-UNKNOWN-ERROR and NS-UNKNOWN-CONDITION.
-
Jul 25, 2007
-
0.3.4
-
Fix clisp get-host-name, multiple ECL fixes.
-
Jun 05, 2007
-
0.3.3
-
Fix where host resolution routine was unable to resolve would return
- NIL instead of erroring.
-
Mar 04, 2007
-
0.3.2
-
Fixes for many backends related to closing sockets.
- LispWorks fix for broken server sockets.
- API guarantee adjustments in preparation of porting Drakma.
-
Feb 28, 2007
-
0.3.1
-
fixed with-server-socket; prevent creation of invalid sockets;
- 2 more convenience macros.
-
Feb 26, 2007
-
re-release
-
Re-release of 0.2.3, 0.2.4, 0.2.5 and 0.3.0 tarballs
- because the originals included Subversion administration areas.
-
Jan 21, 2007
-
0.3.0
Server sockets
-
Jan 19, 2007
-
0.2.5
Allegro compilation fix.
-
Jan 17, 2007
-
0.2.4
Various fixes for CMUCL, OpenMCL, Allegro and LispWorks.
-
-
Jan 04, 2007
-
0.2.3
Add :element-type support to support stacking
- flexi-streams on socket streams for portable :external-format
- support.
-
Jan 03, 2007
-
0.2.2
Add ECL support and a small SBCL bugfix.
-
Dec 21, 2006
-
0.2.1
Remove 'open-stream' interface which is supposed
- to be provided by the 'trivial-usocket' package.
-
Dec 18, 2006
-
0.2.0
Add support for
- Scieneer
- Common Lisp, fix issue #6 and
- API preparation for server side sockets (not in this release)
-
Feb 13, 2006
-
0.1.0
Initial release
+
Release history
+
+
Date
+
Release
+
Summary
+
+
+
Dec 27, 2008
+
0.4.1
+
fixes for ECL, LispWorks, SBCL, SCL
+
+
+
Oct 28, 2008
+
0.4.0
+
select()-like api: make a single thread wait for
+multiple sockets.
+ various socket options for socket-creation with
+SOCKET-CONNECT.
+
+
+
Jun 21, 2008
+
0.3.6
+
Code fixups based on advice from the ECL and OpenMCL
+maintainers. New exported symbols: WITH-MAPPED-CONDITIONS,
+NS-CONDITION, NS-ERROR, NS-UNKNOWN-ERROR and NS-UNKNOWN-CONDITION.
+
+
+
Jul 25, 2007
+
0.3.4
+
Fix clisp get-host-name, multiple ECL fixes.
+
+
+
Jun 05, 2007
+
0.3.3
+
Fix where host resolution routine was unable to resolve would
+return NIL instead of erroring.
+
+
+
Mar 04, 2007
+
0.3.2
+
Fixes for many backends related to closing sockets. LispWorks
+fix for broken server sockets. API guarantee adjustments in preparation
+of porting Drakma.
+
+
+
Feb 28, 2007
+
0.3.1
+
fixed with-server-socket; prevent creation of invalid
+sockets; 2 more convenience macros.
+
+
+
Feb 26, 2007
+
re-release
+
Re-release of 0.2.3, 0.2.4, 0.2.5 and 0.3.0 tarballs because
+the originals included Subversion administration areas.
+
+
+
Jan 21, 2007
+
0.3.0
+
Server sockets
+
+
+
Jan 19, 2007
+
0.2.5
+
Allegro compilation fix.
+
+
+
Jan 17, 2007
+
0.2.4
+
Various fixes for CMUCL, OpenMCL, Allegro and LispWorks.
+
+
+
Jan 04, 2007
+
0.2.3
+
Add :element-type support to support stacking flexi-streams
+on socket streams for portable :external-format support.
+
+
+
Jan 03, 2007
+
0.2.2
+
Add ECL support and a small SBCL bugfix.
+
+
+
Dec 21, 2006
+
0.2.1
+
Remove 'open-stream' interface which is supposed to be
+provided by the 'trivial-usocket' package.
+
+
+
Dec 18, 2006
+
0.2.0
+
Add support for Scieneer Common Lisp,
+fix
+ issue #6
+and API preparation for server side sockets (not in this release)
Long ago the project was conceived and started by Erik Enge in an
attempt to factor out all implementation specific sockets code from
cl-irc. This 'long ago' must have been
way before 2003 when I entered the cl-irc project.
-
In january 2006, Erik Huelsmann found Erik Enge willing to donate
-the code he had still laying around to restart the project. The restart
-took place at the 27th of january when the old code was imported into the
-public repository.
-
-
-
-
-Back to Common-lisp.net.
+the code he had still laying around to restart the project. The restart
+took place at the 27th of january when the old code was imported into
+the
+public repository.
+
+
Starting from 2008, Chun Tian (binghe) joined into usocket
+development team with his UDP code base.
+