[usocket-devel] Support for Server Connections

[nick thomas]

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!