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

Re: [usocket-devel] Portably supporting :external-format
by Erik Huelsmann 23 Oct '06

23 Oct '06

> > So, to stay backward compatible, this is what I'd like to do: > > > > - If no external-format is given: just return the raw stream returned > > by the implementation (as we do now) > > - If an external-format is specified, create a raw stream with 'octet' > > element-type and wrap the returned stream with a flexi-stream, > > exposing the flexi-stream to the caller. > > > > How about that? > Flexi-streams depends on trivial-gray-streams, which appears to > support the following implementations: > > - Allegro > - CMUCL > - LispWorks > - OpenMCL > - CLISP > - SBCL > > It doesn't appear to support ABCL or Scieneer CL. For that reason, we > can't simply make it a mandatory dependency, unless we want to give up > on those implementations. How do you propose we make it optional? Well, there's another option: I talked to David Lichteblau and he will accept patches to support more implementations. I already had ABCL installed on my system, so I've been working to add ABCL support today. ABCL users probably won't want to use the facility, because (as the authors say themselves) "CLOS is dead slow" and Gray streams use CLOS... As far as Scieneer is concerned, well given their prices, I won't be able to afford to have an installation, but maybe Douglas Crosher (who I CC'ed in with this message) can provide a patch to trivial-gray-streams too? > One idea that comes to mind is to only use flexi-streams if it has > already been loaded when package.lisp is loaded. If it has, we set a > *use-flexi-streams* variable (or something), and then test that > whenever we need to deal with :external-format. In addition, we could > expose this variable to the user, allowing them to test or set it. Well, I'd like to check and see if it's possible to extend trivial-gray-streams (and possibly flexi-streams) to support our use-case. Looking at ABCL and flexi-streams though, I do see a problem: ABCL doesn't have a generic function close, but defines STREAM-CLOSE instead... At least flexi-streams 0.5.10 seems to depend on close, open-stream-p and maybe others too, to be generic functions, not just defuns... Well, ABCL isn't in wide use anyway and not going very fast development, but, well, I could ask around with the developers what to expect there. It would indeed be too bad not to be able to support :external-format there, but that's an option too (just ignore the external-format in case of ABCL). We need to make sure to document that though. bye, Erik. PS: Douglas, do you have interface documentation for Scieneer Gray streams somewhere for me? Or could you have a look at trivial-gray-streams (and flexi-streams) and tell us if it's possible to add code for Scieneer to them?

3 3

[usocket-devel] Portably supporting :external-format
by Erik Huelsmann 22 Oct '06

22 Oct '06

On IRC, I had some discussions whether it would be enough to just support octet streams, but it looks like not all implementations support octet streams. Definitely not all of them support :external-format for sockets. So, as I mentioned in earlier posts, it might be a good idea to start depending on flexi-streams: this gives us portable external-formats as well as *bivalent* streams. The latter is important for many TCP/IP protocols: HTTP has a character header, but binary content. Other protocols have that too (8BIT smtp). So, to stay backward compatible, this is what I'd like to do: - If no external-format is given: just return the raw stream returned by the implementation (as we do now) - If an external-format is specified, create a raw stream with 'octet' element-type and wrap the returned stream with a flexi-stream, exposing the flexi-stream to the caller. How about that? bye, Erik.

1 0

Re: [usocket-devel] Support for Server Connections
by nick thomas 22 Oct '06

22 Oct '06

On 10/20/06, Erik Huelsmann <e.huelsmann(a)gmx.net> wrote: > Hi Nick, > > Thanks for the - now correct - patch. I'd love to react to it, but you sent > both patches only to me. Was that accidental? If so, I'd like to reply to this > message on-list giving my comments for consideration and discussion. > Sorry! That was, indeed, accidental. For the benefit of those on the list: On 10/16/06, Nick Thomas <jesuswaffle(a)gmail.com> wrote: > A couple weeks ago, I hacked together the beginnings of a TCP server > socket implementation. It has documentation, but no tests. I wrote the > backend for SBCL, and it seems to be working fine. > > It doesn't support a lot of the requirements [that Erik] discussed. It > doesn't support setting socket options, and it only works with IPv4. > However, it might be useful as a basis for further work. Patch attached.

2 4

[usocket-devel] socket volunteerism
by Captain Fourier 18 Oct '06

18 Oct '06

Hey, I am interested in helping make usocket get developed. Is there anyway I can help?

4 3

[usocket-devel] Re: [usocket-cvs] r119 - in usocket/trunk: . backend doc notes
by Erik Huelsmann 18 Oct '06

18 Oct '06

Sorry. That was a bit more than Douglas submitted, I'll revert the non-related part when I get back from work. bye, Erik. On 10/18/06, ehuelsmann(a)common-lisp.net <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Wed Oct 18 02:56:33 2006 > New Revision: 119 > > Added: > usocket/trunk/backend/scl.lisp > usocket/trunk/notes/accept-apis.txt > Modified: > usocket/trunk/condition.lisp > usocket/trunk/doc/design.txt > usocket/trunk/usocket.asd > usocket/trunk/usocket.lisp > Log: > Add Scieneer support. > > Donated by Douglas Crosher <dtc at scieneer dot com>. > > > Added: usocket/trunk/backend/scl.lisp > ============================================================================== > --- (empty file) > +++ usocket/trunk/backend/scl.lisp Wed Oct 18 02:56:33 2006 > @@ -0,0 +1,101 @@ > +;;;; $Id: scl.lisp$ > +;;;; $URL: svn://common-lisp.net/project/usocket/svn/usocket/trunk/backend/scl.lisp $ > + > +;;;; See LICENSE for licensing information. > + > +(in-package :usocket) > + > +(defparameter +scl-error-map+ > + (append +unix-errno-condition-map+ > + +unix-errno-error-map+)) > + > +(defun scl-map-socket-error (err &key condition socket) > + (let ((usock-err (cdr (assoc err +scl-error-map+ :test #'member)))) > + (cond (usock-err > + (if (subtypep usock-err 'error) > + (error usock-err :socket socket) > + (signal usock-err :socket socket))) > + (t > + (error 'unknown-error > + :socket socket > + :real-error condition))))) > + > +(defun handle-condition (condition &optional (socket nil)) > + "Dispatch correct usocket condition." > + (etypecase condition > + (ext::socket-error > + (format t "erron: ~D~%" (ext::socket-errno condition)) > + (scl-map-socket-error (ext::socket-errno condition) > + :socket socket > + :condition condition)) > + (error > + (error 'unknown-error > + :real-condition condition > + :socket socket)))) > + > +(defun socket-connect (host port) > + (let* ((socket > + (with-mapped-conditions (nil) > + (ext:connect-to-inet-socket (host-to-hbo host) port :kind :stream))) > + (stream (sys:make-fd-stream socket :input t :output t > + :element-type 'character > + :buffering :full))) > + ;;###FIXME the above line probably needs an :external-format > + (make-socket :socket socket :stream stream))) > + > +(defmethod socket-close ((usocket usocket)) > + "Close socket." > + (with-mapped-conditions (usocket) > + (ext:close-socket (socket usocket)))) > + > +(defmethod get-local-name ((usocket usocket)) > + (multiple-value-bind (address port) > + (with-mapped-conditions (usocket) > + (ext:get-socket-host-and-port (socket usocket))) > + (values (hbo-to-vector-quad address) port))) > + > +(defmethod get-peer-name ((usocket usocket)) > + (multiple-value-bind (address port) > + (with-mapped-conditions (usocket) > + (ext:get-peer-host-and-port (socket usocket))) > + (values (hbo-to-vector-quad address) port))) > + > +(defmethod get-local-address ((usocket usocket)) > + (nth-value 0 (get-local-name usocket))) > + > +(defmethod get-peer-address ((usocket usocket)) > + (nth-value 0 (get-peer-name usocket))) > + > +(defmethod get-local-port ((usocket usocket)) > + (nth-value 1 (get-local-name usocket))) > + > +(defmethod get-peer-port ((usocket usocket)) > + (nth-value 1 (get-peer-name usocket))) > + > + > +(defun get-host-by-address (address) > + (multiple-value-bind (host errno) > + (ext:lookup-host-entry (host-byte-order address)) > + (cond (host > + (ext:host-entry-name host)) > + (t > + (let ((condition (cdr (assoc errno +unix-ns-error-map+)))) > + (cond (condition > + (error condition :host-or-ip address)) > + (t > + (error 'ns-unknown-error :host-or-ip address > + :real-error errno)))))))) > + > +(defun get-hosts-by-name (name) > + (multiple-value-bind (host errno) > + (ext:lookup-host-entry name) > + (cond (host > + (mapcar #'hbo-to-vector-quad > + (ext:host-entry-addr-list host))) > + (t > + (let ((condition (cdr (assoc errno +unix-ns-error-map+)))) > + (cond (condition > + (error condition :host-or-ip name)) > + (t > + (error 'ns-unknown-error :host-or-ip name > + :real-error errno)))))))) > > Modified: usocket/trunk/condition.lisp > ============================================================================== > --- usocket/trunk/condition.lisp (original) > +++ usocket/trunk/condition.lisp Wed Oct 18 02:56:33 2006 > @@ -102,8 +102,8 @@ > ;; isn't really an error: there's just no data to return. > ;; with lisp, we just return NIL (indicating no data) instead of > ;; raising an exception... > - (ns-host-not-found > - ns-no-recovery) > + (ns-host-not-found-error > + ns-no-recovery-error) > (ns-error)) > > (define-condition ns-unknown-error (ns-error) > > Modified: usocket/trunk/doc/design.txt > ============================================================================== > --- usocket/trunk/doc/design.txt (original) > +++ usocket/trunk/doc/design.txt Wed Oct 18 02:56:33 2006 > @@ -13,7 +13,7 @@ > * Motivation > * Design goal > * Functional requirements > - > + * Comments on the functional requirements > > > > @@ -83,6 +83,33 @@ > - OpenMCL > > > +The lifetime of a socket can be described with these steps: > + > + 1. Socket creation (socket() function) > + 2. Socket initializaiton (setsockopt(), bind() and listen()/connect() funcs) > + 3. Socket use (accept() / recv[from], send[to]) > + 4. Socket termination (shutdown()) > + 5. Socket destruction (close()) > + > +While for most applications steps 1-3 can be condensed into 1 (which most > +implementations do), if the library wants to be extensible into other > +domains than IP, a means should be provided to do socket initialization > +without knowing what parameters to accept beforehand: other protocols > +require parameters for setsockopt we will not know about in advance. > + > +There are several possibilities to address this issue: > + > + a. Force the 3 steps apart [hard to get done with the current status > + for some implementations, as they are currently integrated in the > + public interface]. > + b. Find a mechanism to pass options which we want setsockopt to > + be called with. Problem: what to do with implementations which > + don't support setting of all options *before* the bind() call? > + Does it matter that some options may be set after the bind() > + call? What if they're not set before connect() [buffer size changes > + have to be set before connect()]? > + c. ... ? > + > Comments on the design above > ============================ > > > Added: usocket/trunk/notes/accept-apis.txt > ============================================================================== > --- (empty file) > +++ usocket/trunk/notes/accept-apis.txt Wed Oct 18 02:56:33 2006 > @@ -0,0 +1,173 @@ > + > + -*- text -*- > + > +Part of 'Step 3': Server/passive tcp socket interfaces supplied by > +the different implementations in order to provide the same externally. > + > + > +ABCL > +==== > + > + - ext:make-server-socket port > + - ext:socket-accept socket > + - ext:socket-close socket > + > +Allegro > +======= > + > + - socket:make-socket :type :stream :connect :passive > + :local-port <port> :reuse-address t :backlog <nr> > + :local-host <host-ip> > + - socket:accept-connection sock &key wait > + - close > + > + > +clisp > +===== > + > + - socket:socket-server &optional port &key interface backlog > + - socket:socket-server-close sock > + - socket:socket-server-host sock > + - socket:socket-server-port sock > + - socket:socket-accept sock &key element-type external-format buffered timeout > + - socket:socket-options sock &rest options > + > +... and ofcourse, there's the raw-sockets > + > +CMUCL > +===== > + > + - ext:create-inet-listener port &optional kind > + &key reuseaddress backlog interface > + - ext:accept-tcp-connection socket > + > + > +LispWorks > +========= > + > + - comm::get-fd-from-socket (socket-os-fd lispworks-socket) > + - comm::create-tcp-socket-for-service port > + (may use comm::*use_so_reuseaddr* for that socket option) > + misses the ability to specify an interface to bind to. > + - comm::socket-close > + > + > +OpenMCL > +======= > + > + - openmcl-socket:accept-connection > + - openmcl-socket:make-socket :local-host <if> :local-port port > + :reuse-address t :type :stream :connect :passive > + :backlog <nr> > + - close > + > + > +SBCL > +==== > + > + - make-instance 'inet-socket > + - sb-bsd-sockets:sockopt-* > + - sb-bsd-sockets:socket-bind > + - sb-bsd-sockets:socket-listen > + - sb-bsd-sockets:socket-accept > + > + > +;; > +;; > +;; The above APIs are good enough to implement a simple > +;; accept interface, but doesn't give access to specifying > +;; socket options before the socket is bound to the interface > +;; ==> This may only actually be required for SO_REUSEADDRESS?!??? > +;; > +;; The other option would be to use lots of FFI - where needed - > +;; and use the (mostly internal) glue routines from the implementations > + > + > +ABCL > +==== > + > + With ABCL - lacking a good sockets API - it's still possible to implement > + whatever we need to get good access... > + > + > +Allegro > +======= > + > + Hmm. The accept function in this implementation does not allow limiting > + connections to a given host/ip, but it does allow to create sockets > + with mostly the right options. > + > + Is that enough reason to do this entirely in ffi?! > + > + Also, doing this in FFI would require to reverse engineer the creation > + of socket streams. Maybe Franz tech support could help there though. > + > + Need to investigate the IPC_* symbols an the sockets package: > + there are lots of functions which look like they should be useable. > + > + > +clisp > +===== > + > + This implementation allows access to the full sockets as described > + in http://clisp.cons.org/impnotes/rawsock.html. > + > + > +CMUCL > +===== > + > + Provides (in unix package): > + > + - unix-accept > + - unix-bind > + - unix-listen > + - unix-socket > + > + Provides (in extentions): > + > + - inet-sockaddr > + - get-socket-option > + - set-socket-option > + - create-inet-listener port &key host reuse-address backlog > + > + > +LispWorks > +========= > + > + The implementation provides a lot of undocumented functions the library > + could tap into: > + > + - comm::socket > + - comm::bind > + - comm::accept > + - comm::getsockopt > + - comm::setsockopt > + - comm::initialize-sockaddr_in (helper) > + - comm::streams-from-fd (helper) > + > + > +OpenMCL > +======= > + > + - make-socket provides all options which we'll need to set, > + it doesn't however provide access to [gs]etsockopt... > + > + > +SBCL > +==== > + > + provides (in sb-bsd-sockets): > + socket-bind > + socket-accept > + sokcet-listen > + > + provides (in sb-bsd-sockets-internal [sockint]): > + getsockopt > + setsockopt > + > + SO-* constants > + TCP-* constant(s) > + AF-* constants (and, since AF-* == IF-*, we don't need others) > + > + > + > > Modified: usocket/trunk/usocket.asd > ============================================================================== > --- usocket/trunk/usocket.asd (original) > +++ usocket/trunk/usocket.asd Wed Oct 18 02:56:33 2006 > @@ -28,6 +28,8 @@ > :depends-on ("condition")) > #+cmu (:file "cmucl" :pathname "backend/cmucl" > :depends-on ("condition")) > + #+scl (:file "scl" :pathname "backend/scl" > + :depends-on ("condition")) > #+sbcl (:file "sbcl" :pathname "backend/sbcl" > :depends-on ("condition")) > #+lispworks (:file "lispworks" :pathname "backend/lispworks" > > Modified: usocket/trunk/usocket.lisp > ============================================================================== > --- usocket/trunk/usocket.lisp (original) > +++ usocket/trunk/usocket.lisp Wed Oct 18 02:56:33 2006 > @@ -164,8 +164,8 @@ > (string (let ((ip (ignore-errors > (dotted-quad-to-vector-quad host)))) > (if (and ip (= 4 (length ip))) > - ip > - (host-to-hbo (get-host-by-name host))))) > + (host-byte-order ip) > + (host-to-hbo (get-host-by-name host))))) > ((vector t 4) (host-byte-order host)) > (integer host)))) > > @@ -186,9 +186,19 @@ > ;; > > (setf (documentation 'socket-connect 'function) > - "Connect to `host' on `port'. `host' is assumed to be a string of > + "Connect to `host' on `port'. `host' is assumed to be a string or > an IP address represented in vector notation, such as #(192 168 1 1). > `port' is assumed to be an integer. > > Returns a usocket object.") > > +;; Documentation for the function > +;; > +;; (defun SOCKET-LISTEN (host port &key local-ip local-port > +;; reuseaddress backlog) ..) > + > + > +;; Documentation for the function > +;; > +;; (defun SOCKET-ACCEPT (socket &key element-type external-format > +;; buffered timeout) ..) > _______________________________________________ > usocket-cvs mailing list > usocket-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/usocket-cvs >

1 0

[usocket-devel] Scieneer CL support.
by Douglas Crosher 17 Oct '06

17 Oct '06

Attached are patches for the Scieneer Common Lisp implementation, plus the files backend/scl.lisp and test/scl.conf.in. All the tests pass. Regards Douglas Crosher Index: usocket.asd =================================================================== --- usocket.asd (revision 114) +++ usocket.asd (working copy) @@ -28,6 +28,8 @@ :depends-on ("condition")) #+cmu (:file "cmucl" :pathname "backend/cmucl" :depends-on ("condition")) + #+scl (:file "scl" :pathname "backend/scl" + :depends-on ("condition")) #+sbcl (:file "sbcl" :pathname "backend/sbcl" :depends-on ("condition")) #+lispworks (:file "lispworks" :pathname "backend/lispworks" Index: usocket.lisp =================================================================== --- usocket.lisp (revision 114) +++ usocket.lisp (working copy) @@ -147,8 +147,8 @@ (string (let ((ip (ignore-errors (dotted-quad-to-vector-quad host)))) (if (and ip (= 4 (length ip))) - ip - (host-to-hbo (get-host-by-name host))))) + (host-byte-order ip) + (host-to-hbo (get-host-by-name host))))) ((vector t 4) (host-byte-order host)) (integer host)))) Index: condition.lisp =================================================================== --- condition.lisp (revision 114) +++ condition.lisp (working copy) @@ -95,8 +95,8 @@ ;; isn't really an error: there's just no data to return. ;; with lisp, we just return NIL (indicating no data) instead of ;; raising an exception... - (ns-host-not-found - ns-no-recovery) + (ns-host-not-found-error + ns-no-recovery-error) (ns-error)) (define-condition ns-unknown-error (ns-error) ;;;; $Id: scl.lisp$ ;;;; $URL: svn://common-lisp.net/project/usocket/svn/usocket/trunk/backend/scl.lisp $ ;;;; See LICENSE for licensing information. (in-package :usocket) (defparameter +scl-error-map+ (append +unix-errno-condition-map+ +unix-errno-error-map+)) (defun scl-map-socket-error (err &key condition socket) (let ((usock-err (cdr (assoc err +scl-error-map+ :test #'member)))) (cond (usock-err (if (subtypep usock-err 'error) (error usock-err :socket socket) (signal usock-err :socket socket))) (t (error 'unknown-error :socket socket :real-error condition))))) (defun handle-condition (condition &optional (socket nil)) "Dispatch correct usocket condition." (etypecase condition (ext::socket-error (format t "erron: ~D~%" (ext::socket-errno condition)) (scl-map-socket-error (ext::socket-errno condition) :socket socket :condition condition)) (error (error 'unknown-error :real-condition condition :socket socket)))) (defun socket-connect (host port) (let* ((socket (with-mapped-conditions (nil) (ext:connect-to-inet-socket (host-to-hbo host) port :kind :stream))) (stream (sys:make-fd-stream socket :input t :output t :element-type 'character :buffering :full))) ;;###FIXME the above line probably needs an :external-format (make-socket :socket socket :stream stream))) (defmethod socket-close ((usocket usocket)) "Close socket." (with-mapped-conditions (usocket) (ext:close-socket (socket usocket)))) (defmethod get-local-name ((usocket usocket)) (multiple-value-bind (address port) (with-mapped-conditions (usocket) (ext:get-socket-host-and-port (socket usocket))) (values (hbo-to-vector-quad address) port))) (defmethod get-peer-name ((usocket usocket)) (multiple-value-bind (address port) (with-mapped-conditions (usocket) (ext:get-peer-host-and-port (socket usocket))) (values (hbo-to-vector-quad address) port))) (defmethod get-local-address ((usocket usocket)) (nth-value 0 (get-local-name usocket))) (defmethod get-peer-address ((usocket usocket)) (nth-value 0 (get-peer-name usocket))) (defmethod get-local-port ((usocket usocket)) (nth-value 1 (get-local-name usocket))) (defmethod get-peer-port ((usocket usocket)) (nth-value 1 (get-peer-name usocket))) (defun get-host-by-address (address) (multiple-value-bind (host errno) (ext:lookup-host-entry (host-byte-order address)) (cond (host (ext:host-entry-name host)) (t (let ((condition (cdr (assoc errno +unix-ns-error-map+)))) (cond (condition (error condition :host-or-ip address)) (t (error 'ns-unknown-error :host-or-ip address :real-error errno)))))))) (defun get-hosts-by-name (name) (multiple-value-bind (host errno) (ext:lookup-host-entry name) (cond (host (mapcar #'hbo-to-vector-quad (ext:host-entry-addr-list host))) (t (let ((condition (cdr (assoc errno +unix-ns-error-map+)))) (cond (condition (error condition :host-or-ip name)) (t (error 'ns-unknown-error :host-or-ip name :real-error errno)))))))) # lisp binary test setup file args= # lisp_bin is required! lisp_bin="/opt/scl/bin/scl" lisp_name=SCL # lisp_exit is required! lisp_exit="(unix:unix-exit result)"

2 1

Re: [usocket-devel] Support for external-format, element-type
by Erik Huelsmann 17 Oct '06

17 Oct '06

> In the meantime I've also come to the conclusion that using something like > flexi-streams is more practical than setting a single external format for > a > stream. If usocket supports octets as element type, it's not even really > necessary to integrate flexi-streams into the library itself, people can > just wrap the socket stream when they want to. That's right. This makes me wonder whether we need to support character streams at all, or that we expect our users to use flexi-streams if they want anything but octet streams: for example the http pipe-lining protocol treats the connection as ascii/character stream for the header and octets for the body of the request, but given there may be several requests, it alternatingly treats connections as octets and characters. No lisp implementation - I know of - supports bivalent streams out-of-the-box, so something like flexi-streams will always be required, right? bye, Erik. -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

1 0

Re: [usocket-devel] Support for Server Connections
by Erik Huelsmann 17 Oct '06

17 Oct '06

> On 10/16/06, Erik Huelsmann <e.huelsmann(a)gmx.net> wrote: > > These requirements came up: > > - Support for other-than-ipv4 addresses/sockets > > > Do you mean just IPv4 vs. IPv6, or do you also intend to support, > e.g., UNIX sockets? If so, isn't that beyond the scope of usocket? > > > - Support for create-time options (such as REUSEADDRESS) > > > Here's the situation as far as create-time options go in the various > target implementations: > > SBCL -- Supports getting and setting of most socket options. > CMUCL -- Supports getting and setting of all socket options. > Allegro -- Doesn't support any of the usual BSD socket options > (unsurprisingly). > LispWorks -- Unless I'm missing something, doesn't support socket options. > OpenMCL -- Supports setting some socket options at creation time. > CLISP -- Supports getting and setting of all socket options. > Support is somewhat spotty, as you can see. However, since many of the > socket options are, in fact, sometimes useful, we ought to provide a > way to set them on supporting implementations (necessarily at creation > time, to support OpenMCL). If the user specifies an option that the > implementation doesn't support, then we simply ignore it and produce a > warning. Well, I don't really like warnings, but using the system of restarts might be appropriate: the software can select itself whether the unsupported option is a continuable situation or not. > > What were your ideas? > > > A couple weeks ago, I hacked together the beginnings of a TCP server > socket implementation. It has documentation, but no tests. I wrote the > backend for SBCL, and it seems to be working fine. That's great news! One backend is a start... > It doesn't support a lot of the requirements discussed. It doesn't > support setting socket options, and it only works with IPv4. However, > it might be useful as a basis for further work. Patch attached. Thanks for the patch. I was looking for the implementation you chose for accept, especially since you decided not to derive the usocket-server from the usocket class. I'm missing the actual implementation. Could you provide the missing bit? bye, Erik. -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer -- GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl

1 0

Fwd: [usocket-devel] Support for external-format, element-type
by Marijn Haverbeke 17 Oct '06

17 Oct '06

(Woops, accidentally sent to just Erik, forwaring to list). ---------- Forwarded message ---------- From: Marijn Haverbeke <marijnh(a)gmail.com> Date: Oct 17, 2006 9:27 AM Subject: Re: [usocket-devel] Support for external-format, element-type To: Erik Huelsmann <e.huelsmann(a)gmx.net> In the meantime I've also come to the conclusion that using something like flexi-streams is more practical than setting a single external format for a stream. If usocket supports octets as element type, it's not even really necessary to integrate flexi-streams into the library itself, people can just wrap the socket stream when they want to. Regards, Marijn On 10/16/06, Erik Huelsmann <e.huelsmann(a)gmx.net> wrote: > > > > Hello list, > > > > I'm considering switching from trivial-sockets to usocket, seeing that > the > > former is completely unmaintained. But, while the open-stream function > > does > > accept :external-format and :element-type arguments, it just raises an > > 'unsupported' condition when they are passed. It would be rather trivial > > to > > support these parameters in SBCL, but that would mean changing the > > open-stream function itself, either make it throw those errors depending > > > on > > the platform (ugly), or move the error throwing into the > platform-specific > > functions. I guess the latter is preferrable, and I'm willing to write > the > > patch for that, but I'd like to hear if you people agree with this. > > I've been using flexi streams in cl-irc to provide cross platform > consistent :external-format for the library. Would it be an idea to do the > same with usocket? > > I know it doesn't work well with Allegro Common Lisp, but if we provide > the patch, the author will probably fix flexi streams... > > bye, > > Erik. > -- > GMX DSL-Flatrate 0,- Euro* - Überall, wo DSL verfügbar ist! > NEU: Jetzt bis zu 16.000 kBit/s! http://www.gmx.net/de/go/dsl >

1 0

[usocket-devel] Support for Server Connections
by nick thomas 16 Oct '06

16 Oct '06

I'd like to see support for server connections in usocket soon. Is any work being done at the moment in this direction? If not, I'd be happy to work on it.

2 1