[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Helmut Eller
Subject: Re: New patch for server sockets and datagram (UDP) support.
Date: Fri, 8 Mar 2002 08:38:55 +0100

address@hidden (Kim F. Storm) writes:

> Below is the doc-string for make-network-process which is a keyword
> based replacement for the built-in open-network-stream.  I already
> implemented most of the code handling this, and it looks quite clean
> compared to the previous version.
> IMO, this it by far the best proposal for the API so far.

Yes.  This looks very good now.

> :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

> 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

> 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?

> > 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.

> 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 :-)

Thanks for all your work, Kim.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]