usocket-devel

usocket-devel@common-lisp.net

248 discussions

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

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

16 Oct '06

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. Regards, Marijn

2 1

[usocket-devel] Test failures under SBCL 0.9.16
by nick thomas 16 Oct '06

16 Oct '06

I get test failures for SOCKET-FAILURE.2 and SOCKET-NAME.4 under SBCL 0.9.16, with both svn and 0.1.0. Here is the test output: Doing 15 pending tests of 15 tests total. MAKE-SOCKET.1 MAKE-SOCKET.2 SOCKET-NO-CONNECT.1 SOCKET-NO-CONNECT.2 SOCKET-NO-CONNECT.3 SOCKET-FAILURE.1 #<USOCKET:TIMEOUT-ERROR {AB8A4B1}> is a USOCKET:TIMEOUT-ERROR. Its slot values are (:SOCKET #<USOCKET:USOCKET {AB89FD9}>). Test SOCKET-FAILURE.2 failed Form: (WITH-CAUGHT-CONDITIONS ('USOCKET:HOST-UNREACHABLE-ERROR NIL) (USOCKET:SOCKET-CONNECT +NON-EXISTING-HOST+ 80) :UNREACH) Expected value: NIL Actual value: #<USOCKET:TIMEOUT-ERROR {AB8A4B1}>. SOCKET-CONNECT.1 SOCKET-CONNECT.2 SOCKET-CONNECT.3 SOCKET-STREAM.1 SOCKET-NAME.1 SOCKET-NAME.2 SOCKET-NAME.3 Test SOCKET-NAME.4 failed Form: (WITH-CAUGHT-CONDITIONS (NIL NIL) (LET ((SOCK (USOCKET:SOCKET-CONNECT #(65 110 12 237) 80))) (UNWIND-PROTECT (USOCKET:GET-LOCAL-ADDRESS SOCK) (USOCKET:SOCKET-CLOSE SOCK)))) Expected value: #(10 0 0 252) Actual value: #(192 168 2 3). 2 out of 15 total tests failed: SOCKET-FAILURE.2, SOCKET-NAME.4. No clue what's going on here. Any ideas?

2 1

[usocket-devel] is usocket in active development?
by Rüdiger Sonderfeld 09 Sep '06

09 Sep '06

hello, I have written a library for fastcgi. At the moment it only works with sbcl (and propably ecl). Because I'm using the sbcl socket-api. Now I want to port the library to a portable socket-api. I found usocket library on cliki.net. It seems to be really nice especially after trivial-socket isn't maintained anymore. But the last changes to the svn where made about 3 month ago and there is only one release in a very early stage. So my question is: Is usocket maintained and developed at the moment or is the project dead? Would it be save for me to use usocket in my library? Regards, Rüdiger Sonderfeld

2 2

[usocket-devel] Trac permission change.
by Erik Enge 08 May '06

08 May '06

cl-xml's ticket section was just spammed. So I've removed the ability for anonymous users to modify tickets. If you don't like this, change it by doing: $ trac-admin /project/<PROJECT>/trac add remove anonymous TICKET_MODIFY Thanks, Erik.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

usocket-devel