Re: New patch for server sockets and datagram (UDP) support.

[Kim F. Storm]

Helmut Eller <address@hidden> writes:

Thanks Helmut,
I appreciate your comments.  See below.


> address@hidden (Kim F. Storm) writes:
> 
> > What do you think?
> 
> You are adding many features at the same time; it's a bit hard to see
> what your problem actually is :-)

I agree -- but doing it all in one big step does reveal more of the
API related problems than doing it step by step (as I did with the
non-blocking argument to open-network-stream).
 
> I think it's a _very good_ idea to rename open-network-stream to
> something different, because this frees you from being backward
> compatible.

That's right.  It definitely has advantages to do that.
> 
> Have you considered to use keyword arguments, e.g., in the spirit of
> the make-socket function found in Allegro CL?
> <http://www.franz.com/support/documentation/5.0.1/doc/cl/socket.htm>
> 

I have considered doing that, but I don't think there is any tradition
for doing that in emacs lisp built-in functions.  But I agree that it
gives more flexibility in combining various options, so if that is
ok with the rest of the developers, I will look into that path.

> It's probably a pain to parse keyword arguments in C, but it frees you
> from overloading positional arguments in an unnatural way.  It would
> also be quite nice to use from Lisp.  Another advantage is that you
> could add new arguments without much backward compatibility
> restrictions.

It still has the problem of what to do with unknown arguments --
but at least it will not trigger the debugger due to an incorrect
number of arguments.

> 
> Another point: if someone wants to bind a socket to a specific
> interface he must be able to specify the IP address, the hostname is
> IMHO not sufficient for this.  Any ideas for this problem?

I'll have to think about that, but again keyword arguments could
be helpful here.

>  I propose
> to make gethostbyname and related functions available to Lisp.  IP
> addresses could be represented by vectors of 4 bytes (it's a pity that
> 32bit don't fit into a ELisp fixnum).
>

Not that I object to this in general, but for what purpose? 

> Yet another point: please, please, please make accept-connection a
> separate function.  Then one could make a _blocking_ accept; also
> accept with a timeout argument would be possible.

I understand that you want to serialize the connections.
Why is it necessary to do that?  Each connection gets its own
process (and buffer etc), so they should be able to co-exist.

If it is a matter of resources, then I think there are other ways we
could consider to handle this (e.g. a `:max-conn 5' parameter) to
limit the number of concurrent servers running.  Or we could make the
`stop-process' function applicable to server sockets to stop/start
listening.

AFAICS, your accept-connection call doesn't really accept anything;
it just allows the server to accept a (one) connection if one is
received.  If you don't want to accept more connections, you can
delete the server process in the sentinel.

And you can start a timer to cancel the accept (by calling
delete-process) if a connection hasn't been received.
The sentinel can cancel (or restart) that timer if a
connection is accepted.


>  Would this add any > implementation complexity?

Yes.  (I'll elaborate more on this when I understand what
you are trying to accomplish).


> 
> Helmut.
> 

-- 
Kim F. Storm <address@hidden> http://www.cua.dk