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

[Kim F. Storm]

Helmut Eller <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> 
> 
> > :nowait BOOL -- Don't wait for client process to complete the
> > connection to the server if BOOL is non-nil; instead, the sentinel
> > function will be called with second matching "open" (if successful) or
> > "failed" when the connect completes.  Default is to use a blocking
> > connect.
> 
> I would prefer :wait that defaults to t.  Is shorter and avoids the
> negation.

Since we will normally use this through wrappers -- and there is
really only one usage which does actually wait (corresponsing to the
old, blocking open-network-stream), it makes more sense to have a
:wait key with default nil.  I'll change that.

> 
> > Notice that the FILTER and SENTINEL args are never used directly by
> > the server process.  Also, the BUFFER argument is not used directly by
> > the server process, but via `network-server-log-function' hook, a log
> > of the accepted (and failed) connections may be recorded in the server
> > process' buffer.
> 
> network-server-log-function is a global variable.  This may cause
> problems when used by independent packages.  Is it a problem to make
> this an attribute of the server process?  E.g. as :log-function
> argument?
> 
I actually didn't expect any `packages' as such to use this, as I just
intended it to be a way to trace/debug connectivity problems.
But I agree that it would be cleaner to add it per-connection 
via a :log argument.  I'll think about that...

> > The following special call returns t iff a given KEY VALUE
> > pair is supported on this system:
> >   (make-network-process :feature KEY VALUE)  */)
> 
> Hmm... this looks a bit strange.  Can you give some examples?
> Especially, what do you supply as VALUE?
> 

It simply tests whether using KEY VALUE as arguments to make-network-stream
is supported, e.g. :datagram t, :nowait t, :family 'local.

> > > Because there is currently no way to get the IP address(es) of the
> > > current host.  It MAY also simplify the C level implementation,
> > > because you could require that e.g. the SERVICE argument is actually a
> > > port number and not a string or a number; similar for the HOST
> > > argument.
> > > 
> > I don't think this is necessary, so I'll leave that for a future
> > enhancement.  To restrict connections to the local host, I suggest 
> > using either "localhost" for the HOST or as local (UNIX) socket.
> 
> It was indented to implement protocols like DCC.  But it is better to
> leave this for the feature.

Yes!  I think I'm trying to cope with enough new functionality here :-)

> 
> > Ok, but as you mention yourself, this is the exception, so it
> > shouldn't be the standard behaviour.  I will take a look at using
> > stop-process and start-process to temporarily inhibit a server socket
> > from accepting connections.  If you can use stop-process in
> > the sentinel, this seems to be a cleaner solution than 
> > having to (re-)enable the server by calling accept-connection.
> 
> OK.  I will not bother you again :-)

Actually, I will make `:wait t' work for a server socket -- that
will allow you to start the server in the stopped state.

> 
> Thanks for all your work, Kim.

Thank you for your initial work on this, as well as your valuable
feedback, Helmut!

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