Improve documentation for end stream/connection

[tracker1]

Just suggesting related to #136 is to maybe improve the documentation slightly...

I'm presuming the stream to the process will be flushed and closed before the signal is sent. Also, is it SIGTERM?

NOTE: I'm not actually using this project, but wanted to point out the potential for confusion in the README.

[asergeyev]

Let's start from basics.

Websocketd can see following things from the client:

• connect
• disconnect

Connect makes server start a program; disconnect makes server to do following:

• close stdin
• send SIGINT and, if it was not successful, follow with SIGKILL

Then process might just terminate on it's own... In this case websocketd will see that stdout got closed, that would cause it to also close socket to client. That would trigger onclose() in browser.

I don't see though why you would really need that in README

[tracker1]

My concern would be the condition where stdin handling wasn't done (cleanup) before a SIGINT/SIGTERM was issued... if the stream to the child process (worker) was closed first, then some time given on disconnect it might leave for a better chance of a clean exit for workers that aren't specifically handling SIGINT/SIGTERM ...

[asergeyev]

I don't see where in real life use this sort of situation would happen. Could you try to make example and demonstrate what happens where?

if websocketd kills process it means there is no client anymore. Sure, if you have stateful program that does something you might be left out without cleanup but websockets are not really for something like that. This case needs special handling and there is not much we can do in websocketd imo... It's like running wordpress under inetd. Nobody goes there even that it could be somewhat possible with small PHP program.

[tracker1]

Connect to socket... authenticate... push a bunch of data, disconnect.. The server could be doing something with the stream of data, and for instance sending records into a database... if the sigterm happens before the data has flushed, and all the data is written out.. some records could be missing from that push/stream. As an example, a service that an importer process (event or trigger from ftp upload) can connect to, push data into, then drop said connection.

I know that a client should wait for an acknowledge, but I can see someone writing such a system without said checks.

[asergeyev]

So far I think you're continuing theoretical discussion and I'm not seeing why it should be different in websocketd from what it's now. Special custom use (as a component that would hold websocket on one end and ftp upload socket on another one) should be implemented with care. There is nothing in current termination logic that prevents building a carefully constructed solution for a given problem.

As you wrote for your theoretic one, it could simply be a stream of "bytes received from browser, bytes successfully uploaded" tuples. Client should be smart enough to not call ws.close() until those reach number of bytes it had sent to server.