Re: Feature suggestion: server sockets

Re: Feature suggestion: server sockets

[Kim F. Storm]

In gnu.emacs.bug, helmut@xaital.km4u.net (Helmut Eller) wrote:

> Dear Emacs Developers,
> 
> Emacs has currently no support for server sockets.  Server sockets
> (sometimes called passive sockets) would be useful for packages like
> emacserver, gnuserv, or EmacsHttpd.  Such "server like" packages are
> currently somewhat hard to write, because they must use an external
> program that opens the server socket and forwards the input to Emacs.
> With the patch below, Emacs would be able to open server sockets
> itself.

This sounds like a useful addition to me.

I am currently working on a different aspect of network support
(optionally making open-network-stream non-blocking), and I have
modified open-network-stream to take two optional arguments:
        FILTER and SENTINEL
to set the process filter and sentinel as part of opening the
network stream (to avoid race conditions).  The SENTINEL is
called when the connect completes (either in success or failure).

I suspect that your proposal for open-server-socket could similarly
have the FILTER and SENTINEL functions as arguments.  Then I don't see
any need for your accept-connection function as SENTINEL could be
called when a new connection is accepted, and the FILTER could be used
as a normal filter (processing received data) for the connection.

If you don't want to accept more connections on the server-socket,
it should be closed in the sentinel.

> 
> I propose the following Lisp level interface to server sockets:
> 
> Server sockets, like network connections, are represented as
> processes.  The only purpose of a "server socket process" is to handle
> incoming connections.  Server socket processes work asynchronous: the
> process waits for an incoming connection and passes the connection to
> the filter function.  The new connection is treated afterwards exactly
> like a connection created with `open-network-stream'.  Two new
> primitives are needed for server sockets:
> 
>   - Function: open-server-socket NAME PORT -> PROCESS
> 
>     This function opens a TCP server socket on the given port and
>     returns a process object.  NAME is the name for the process.
> 
> Incoming connections are accepted one at a time with the second new
> primitive: accept-connection.  accept-connection allows the server
> socket process to accept the next connection.  accept-connection is
> non-blocking and returns nil.
> 
>   - Function: accept-connection PROCESS NAME -> nil 
> 
>     PROCESS is a server socket process.  NAME is the name for the
>     incoming connection that will be passed to the process filter.
> 
> Server sockets can be closed with delete-process.  The process-status
> of a server socket process is either `listen' or `closed'.  The
> process-buffer slot is unused for server sockets.  
> 
> I hope the following example helps to clarify a bit; it implements an
> echo server:
> 
>   (defun server-socket-filter (server-socket client-socket)
>     (set-process-filter client-socket #'send-string)
>     (accept-connection server-socket "client-socket")) 
>     
>   (defun start-echo-server ()
>     (let ((server-socket (open-server-socket "server-socket" 7)))
>       (set-process-filter server-socket #'server-socket-filter)
>       (accept-connection server-socket "client-socket")))
> 
> We open a server socket on port 7; install a filter function and allow
> the process to accept the next connection.  When the next request
> arrives, Emacs will create a network stream with name "client-socket"
> and pass it along with the server socket to server-socket-filter.  In
> server-socket-filter we set #'send-string as filter function (to
> perform the actual echoing) and accept the the next connection (to
> handle multiple connections in parallel).
> 
> Note that filter functions are called only when Emacs is idle or
> waiting for something.
> 
> 
> The patch affects the files process.c and process.h (a comment).  I
> have tested it only on my GNU/Linux box.
> 
> Let me know if you decide to integrate the patch in the standard
> Emacs.
> 

In that case, I guess papers are needed.

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


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Helmut Eller]

storm@cua.dk (Kim F. Storm) wrote: 

>
> This sounds like a useful addition to me.

Nice to hear.

> I am currently working on a different aspect of network support
> (optionally making open-network-stream non-blocking), and I have
> modified open-network-stream to take two optional arguments:
>         FILTER and SENTINEL
> to set the process filter and sentinel as part of opening the
> network stream (to avoid race conditions).  The SENTINEL is
> called when the connect completes (either in success or failure).
> 
> I suspect that your proposal for open-server-socket could similarly
> have the FILTER and SENTINEL functions as arguments.  Then I don't see
> any need for your accept-connection function as SENTINEL could be
> called when a new connection is accepted, and the FILTER could be used
> as a normal filter (processing received data) for the connection.
>
> If you don't want to accept more connections on the server-socket,
> it should be closed in the sentinel.

Yes, this is certainly possible.

But what is the advantage of not having accept-connection?

The behavior you describe can easily be implemented at the Lisp level
when you have accept-connection.  I choose to use two functions
because I think this is (slightly) more flexible.  When I have a
choice, I prefer having more low-level functions, than having fewer
high-level functions.  The high-level functions can be implemented in
terms of the lower level functions; the reverse is not possible.

If you are concerned about race conditions: open-server-socket is
blocking, so no danger here.  I'm not sure, but doing wired things
with accept-connection in combination with accept-process-output (like
nested calls to accept-process-output in filters) can result in
"unexpected behaviour".  This is more a problem of my implementation
than of the interface.  Your proposal is safer in this respect,
because one can not even do this wired things.  But again, if you want
a fool-proof interface, provide it as Lisp wrapper.

I think this are mostly style questions.  If you prefer a single
function I have no problem with that.

Regards,
Helmut.










_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Richard Stallman]

This is a useful feature, and a clean Lisp interface.
I see a couple of possible gaps in the implementation, though.

Doing this from Emacs itself is cleaner than running an actual
subprocess like emacsserver to do the job.  But the subprocess runs
all the time, in parallel with Emacs, while this code seems to be able
to accept a server connection only inside wait_reading_process_input.
If Emacs is running a Lisp program for a long time, it may go for a
long time without ever calling wait_reading_process_input.  This could
conceivably mean that Emacs takes too long to respond and the request
fails.

Can you make connection acceptance happen in response to a signal
such as SIGIO, or make it happen in an alarm that happens frequently?
(Such as the one used to poll for available terminal input.)
The actual running of the filter function would have to wait until
wait_reading_process_input, of course.  Something like this already
happens with sentinels, I recall.

One other point: this seems to be designed to work with PF_INET
sockets only.  If you look at emacsclient, you'll see it uses either a
PF_UNIX socket or SYSVIPC.  To make server sockets replace
emacsserver, they would have to support both PF_UNIX sockets and
SYSVIPC (unless SYSVIPC is obsolete nowadays and all systems support
sockets).


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Helmut Eller]

rms@gnu.org wrote:

> This is a useful feature, and a clean Lisp interface.
> I see a couple of possible gaps in the implementation, though.
> 
> Doing this from Emacs itself is cleaner than running an actual
> subprocess like emacsserver to do the job.  But the subprocess runs
> all the time, in parallel with Emacs, while this code seems to be able
> to accept a server connection only inside wait_reading_process_input.
> If Emacs is running a Lisp program for a long time, it may go for a
> long time without ever calling wait_reading_process_input.  This could
> conceivably mean that Emacs takes too long to respond and the request
> fails.
> 
> Can you make connection acceptance happen in response to a signal
> such as SIGIO, or make it happen in an alarm that happens frequently?
> (Such as the one used to poll for available terminal input.)
> The actual running of the filter function would have to wait until
> wait_reading_process_input, of course.  Something like this already
> happens with sentinels, I recall.

I think this is not necessary.  Connection requests are queued by the
OS; accept just takes the first established connection out of the
queue.  A request only fails if the queue is already full.

> One other point: this seems to be designed to work with PF_INET
> sockets only.  If you look at emacsclient, you'll see it uses either a
> PF_UNIX socket or SYSVIPC.  To make server sockets replace
> emacsserver, they would have to support both PF_UNIX sockets and
> SYSVIPC (unless SYSVIPC is obsolete nowadays and all systems support
> sockets).

I modified the code to work with Unix domain sockets.
open-server-socket takes now 3 arguments: NAME, PROTOCOL and
PORT-OR-PATHNAME.  Protocol is either 'inet or 'unix.

Supporting SYSVIPC would be a lot of work, because SYSVIPC uses a
different API, e.g. msgrcv/msgsnd where sockets use read/write.  I
think SYSVIPC is not worth the trouble.

Helmut.
 


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Richard Stallman]

    I think this is not necessary.  Connection requests are queued by the
    OS; accept just takes the first established connection out of the
    queue.  A request only fails if the queue is already full.

So are you saying that the system responds automatically right away
by saying "connection accepted", and it is ok if Emacs then waits a minute
to get back to it?

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Helmut Eller]

> So are you saying that the system responds automatically right away
> by saying "connection accepted", and it is ok if Emacs then waits a minute
> to get back to it?

Yes.


_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Richard Stallman]

    Supporting SYSVIPC would be a lot of work, because SYSVIPC uses a
    different API, e.g. msgrcv/msgsnd where sockets use read/write.  I
    think SYSVIPC is not worth the trouble.

Are there any systems on which emacsserver still uses SYSVIPC?
If so, we cannot replace emacsserver with server streams
unless server streams support SYSVIPC too.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Feature suggestion: server sockets

[Helmut Eller]

> Are there any systems on which emacsserver still uses SYSVIPC?

I don't know.

> If so, we cannot replace emacsserver with server streams
> unless server streams support SYSVIPC too.

INET sockets could be used where supported.  There are probably few
systems that support SYSVIPC but neither INET nor Unix sockets.

Are server sockets only useful if they replace emacsserver?

Helmut.

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel