[usocket-devel] Support for Server Connections

[nick thomas]

Here's a patch (based on svn) which implements some of the
modifications discussed. Specifically, it fixes *DEFAULT-BACKLOG-SIZE*
and factors out the common parts of USOCKET and USOCKET-SERVER to a
base class, USOCKET-BASIC, and makes various API changes (none which
break backcompat with 0.1.0, of course) to accomodate the new scheme.
Also, for symmetry, I rename USOCKET to USOCKET-PEER, with USOCKET as
a deprecated alias.

On 10/20/06, nick thomas <jesuswaffle at gmail.com> wrote:
> On 10/20/06, Erik Huelsmann <ehuels at gmail.com> wrote:
> > > On 10/16/06, Nick Thomas <jesuswaffle at 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.
> >
> > Thanks! ;-)
> >
> > I've copied parts of the patch into this mail below and have given
> > comments inline.
> >
> > [From README]
> >
> > + - usocket-server (class)
> >
> > You decided to create a class without inheriting from the existing
> > usocket class. I'd like to inherit from some superclass, so that we
> > can at least use get-local-name for both server sockets and stream
> > sockets: when a server is created with a :port 0 (any port), it may be
> > usefull to be able to query the assigned port number afterwards...
> >
> > Obviously, we can't inherit every behaviour, because there's no remote
> > address which can be queried. We'd have to find a way to work around
> > that. Maybe by creating a new superclass (bound-usocket or something
> > like it) which only has a local address.
> >
> I did consider inheriting from USOCKET, but I decided not to, because
> of the problems you mentioned. However, I don't have any objection to
> making a common superclass for both types of socket. Actually, it
> would be a win in a couple different ways: it would make the API more
> symmetrical, we could share some code between the two socket types in
> some backends, and it would give us room for extensions when we want
> to add UDP sockets.
>
> One question that comes to mind is: should the slot containing the
> implementation-specific socket object be in the common superclasses or
> in the subclasses? This is not immediately obvious because some
> implementations use distinct types for peer and server sockets, while
> others use the same type.
>
> In my opinion, the slot should be in the common superclass, because,
> in the case of implementations which have a unified socket type, we
> can define the common functions (GET-LOCAL-* and SOCKET-CLOSE) as a
> single method over the common superclass, and, in the case of
> implementations with separate socket types, we can define two methods
> over the subclasses.
>
> > + - server-close (method)
> > +     server-close server-socket
> >
> > well, we could inherit this one too, if we were to create the right
> > inheritance structure.
> >
> Yes, we could, as described above. I don't really see any reason not to do so.
>
> > + - *default-host* (variable)
> > +     the default host to bind server sockets to. 0.0.0.0 by default.
> > + - *default-backlog-size* (variable)
> > +      the default connection backlog size. 16 by default.
> >
> > Ah, but supposedly, some systems only support 5 as the default value.
> >
> I didn't know that bit of trivia. Might as well change it, then.
>
> > Next to that, there's 8 in the actual definition :-)
> >
> Oops. :)
>
> > I like how your patch makes the server-accept function return a stream
> > related usocket.
> >
> Thanks!
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: listen-r1.patch
Type: application/octet-stream
Size: 12985 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20061020/d8d7e8fe/attachment.obj>