I have a lighttpd server with python installed, its using cgi. I'm able to set up a connection with Server Sent Events, but I'm unsure of how to detect if the client disconnects. I read somewhere that its impossible to tell whether a client disconnects or not, unless you send a message to detect it. I'm unsure of how to detect the client disconnect after sending a message. Whenever I send a message I just do...
print(message)
sys.stdout.flush()
Do I have to read stdin to check if the client disconnected or not?
The next version of lighttpd (1.4.40) detects if a client disconnects and sends a TERM signal to the CGI if the CGI is still running.
Related
I'm working with django-websocket-redis lib, that allow establish websockets over uwsgi in separated django loop.
By the documentation I understand well how to send data from server through websockets, but I don't understand how to receive.
Basically I have client and I want to send periodically from the client to server status. I don't understand what I need to do, to handle receiving messages from client on server side? What URL I should use on client?
You can achieve that by using periodically ajax calls from client to server. From documentation:
A client wishing to trigger events on the server side, shall use
XMLHttpRequests (Ajax), as they are much more suitable, rather than
messages sent via Websockets. The main purpose for Websockets is to
communicate asynchronously from the server to the client.
Unfortunately I was unable to find the way to achieve it using just websocket messages.
I am using Python Tornado's websocket_connect function ( http://tornadokevinlee.readthedocs.org/en/latest/websocket.html ) to listen to a websocket feed.
Sometimes the websocket server will die, or disconnect the client (this is detectable ) and I need to figure out a way to clean up the old connection and reconnect the client. I could of course just restart the program but what is the proper way to do this through tornado?
There's nothing automatic for this. When it disconnects, just call websocket_connect() again.
I'm trying to push some messages to client (browser) without any request.
For that I use WebSockets and python to do. I know WebSockets provide a full-duplex communication, but I just need server to client push. I could only find bi-directional communication examples for WebSockets over internet, for a request a response model. When I tried to send in an infinite loop from server after handshake process, the browser hung up.
the code I used is in this post
Is there any solution to do that or whether it is better to go for SSE..
Once the client initiates the web socket connection the server then is eligible to send anything to client side
I have Tornado websocket handler and I am sending messages from my browser ( I have override on_message,on_close,open).
In javascript on close I want to send some data to handler ( to clean some storages, I am sending some numbers in json like {'storage':22, 'time':96} ).
How in websocket handler in tornado to receive that closing message ?
I looked at close and on_close but there is no option to receive data.
If I understand what you're asking for correctly, it's impossible.
You want to make sure that when the connection is closed, and the browser calls the on_close function on your client-side JavaScript code, it can send some final data to the Tornado server.
But when the connection is closed, there's no way to send any more data. That's what it means to be closed.
What you need to do is create a "quit" or similar message, at the application level. When Tornado sends a "quit" message to the JS code, then it can send its final message; when Tornado receives that message, it can close the socket. (Of course this means you need to write your code to handle the case where that "graceful shutdown" never happens because, e.g., the client machine has been vaporized by a nuclear bomb.)
We have a server, written using tornado, which sends asynchronous messages to a client over websockets. In this case, a javascript app running in Chrome on a Mac. When the client is forcibly disconnected, in this case by putting the client to sleep, the server still thinks it is sending messages to the client. Additionally, when the client awakens from sleep, the messages are delivered in a burst.
What is the mechanism by which these messages are queued/buffered? Who is responsible? Why are they still delivered? Who is reconnecting the socket? My intuition is that even though websockets are not request/response like HTTP, they should still require ACK packets since they are built on TCP. Is this being done on purpose to make the protocol more robust to temporary drops in the mobile age?
Browsers may handle websocket client messages in a separate thread, which is not blocked by sleep.
Even if a thread of your custom application is not active, when you force it to sleep (like sleep(100)), TCP connection is not closed in this case. The socket handle is still managed by OS kernel and the TCP server still sends the messages until it reaches the TCP client's receive window overflow. And even after this an application on server side can still submit new messages successfully, which are buffered on TCP level on server side until TCP outgoing buffer is overflown. When outgoing buffer is full, an application should get error code on send request, like "no more space". I have not tried myself, but it should behave like this.
Try to close the client (terminate the process), you will see totally different picture - the server will notice disconnect.
Both cases, disconnect and overflow, are difficult to handle on server side for highly reliable scenarios. Disconnect case can be converted to overflow case (websocket server can buffer messages up to some limit on user space while client is being reconnected). However, there is no easy way to handle reliably overflow of transmit buffer limit. I see only one solution - propagate overflow error back to originator of the event, which raised the message, which has been discarded due to overflow.