Flask-Socketio is disconnecting web (& python) clients after 15 mins of data streaming

[m-yashy]

I have python socketio-client, which picks the live data from another websocket and publish them (after processing) onto flask-socketio ip:port using Emit. Socketio server listens to this particular event and on each such data it updates its internal dictionary with the latest data (lets call it "Curve")

Then there is a Web Flask UI, which on loading emits a message to Socketio server, which triggers a background task to process latest "Curve" data and pushes the updates to socketio on "bedata" topic. Web UI updates its table on each update received in socketio ip:port on "bedata".

The setup works like a charm for ~15 mins, after that both Web UI client and Python socketio-Client receives a "Disconnect" event from Flask and after the though both of them are connected back, the streaming stops and doesn't tick anymore!

More details of code is here: https://stackoverflow.com/questions/77084494/flask-socketio-is-disconnecting-web-python-clients-after-15-mins-of-data-str

Using:
flask:2.3.2
flask-socketio:5.3.5
python-socketio::5.8.0
eventlet:0.33.3
WsgiServer of Eventlet on IIS Express

WorkFlow:
Python based SocketIO client(DataStreamer.py) => app.py + MydataClient.py => JS of html (client.html) => GUI (client.html)

init.py:
from flask import Flask
from flask_socketio import SocketIO
from threading import Lock
import eventlet

eventlet.monkey_patch()
app = Flask(name, template_folder='./templates')
app.config['SECRET_KEY'] = 'privatekey!'

thread = None
thread_lock = Lock
socketio = SocketIO(app, cors_allowed_origins='*',ping_timeout=15,logging=True)

app.py:
from wwwroot.StreamingApp import app, thread, thread_lock, socketio
import MydataClient
import eventlet
from eventlet import wsgi

wsgi.server(eventlet.listen(("0.0.0.0", 90)), app)

@app.route("/live")
def main():
return render_template('client.html')

@socketio.on('connect', namespace='/web')
def connect():
print('Client Connected')

@socketio.on('mydata',namespace='/web')
def MsgHandler(data):
MydataClient.Curve = data

MydataClient.py:
from wwwroot.StreamingApp import app, thread, thread_lock, socketio

Curve=None
def CalculateBE():
while True:
response = {'status': True}
for args in live_be:
if args == None:
continue
be_price = #a method which does calculations on "Curve" data defined above
response['BE' + str(args[0])] = be_price
socketio.emit('bedata', response)
socketio.sleep(5)

@socketio.on('be')
def UpdateBE():
global thread
with thread_lock:
if thread is None:
thread = socketio.start_background_task(CalculateBE)

client.html (Following is the code in JS of html):

<script> $(document).ready( function () { var flask_socket = io.connect('http://localhost:90'); flask_socket.on('connect',()=>{ console.log('connected!'); }); flask_socket.on('disconnect',()=>{ console.log('disconnected!'); }); flask_socket.emit('be'); flask_socket.on("bedata", function (response) { #Update UI }); }); </script>

DataStreamer.py:
import socketio

sio = socketio.Client(reconnection_attempts=5,reconnection_delay=2,reconnection_delay_max=10)
sio.on('connect', on_connect)
sio.on('disconnect', on_disconnect)
sio.on('reconnect', on_reconnect)
sio.connect('http://localhost:90',namespaces=['/web'])
#some calculations from websocket data and then emit
sio.emit("mydata",curve_data,namespace="/web")

[miguelgrinberg]

Disconnections can happen for a lot of different reasons that are external to the actual server and client, so I'm going to assume that this is something that cannot be helped and that your goal is to figure out how to resume streaming once the clients are reconnected.

Looking at your log, the /web is not a connected namespace occurs because your streaming thread called emit() after the client was disconnected. If you want to avoid this error, you have to make your thread smarter. Whenever the disconnect handler for the client is invoked, the thread must be informed of this so that it stops the streaming.

Then when the client reconnects, it should request a new streaming thread to be started by the server.

[m-yashy]

After debugging more, the reason for streaming to stop is with how flask handles the disconnect of flask-socketio? (maybe)

Because, I have some data in app,py, which is in flask-cache (stored here when I initially start the streaming).
Once the flask-socketio issues disconnect event to its clients, the flask webapp is started again in a new thread/process I believe?
Because, I see that my logging is restarted with a new file and the data stored in flask-cache are all empty at this point.
Since cache is empty, even if my socketio clients are reconnected to flask-socketio server, they got no task to do.

I dont think, "disconnect" event from flask-socketio server to its clients, new log file right after this timestamp and empty flask-cache right after this in the new log files are co-incidence.

Any inputs on this?

FYI: I tried the caching with 2 approaches, one with global variables and other with flask-cache, both result in empty data after this restart point!

[miguelgrinberg]

I can't really answer questions that are not directly related to the Python Socket.IO logic. I don't have enough knowledge of your solution to comment or make suggestions about your caching strategy.

[m-yashy]

probably my question would be this w.r.t flask, (I know flask server works on threads) and if for some reason if flask server restarts what is the mechanism (or tools) to retain the previous state of flask server (before the restart)?

[m-yashy]

Also, can you point me to an example of how I can force socket.IO (& flask-socektIO) to manual ping-pong heartbeat mechanism?
i.e. instead of flask-socketIO handling the heartbeat mechanism on its own, I want to run events for "ping"-"pong" responses.

[miguelgrinberg]

Flask does store any state, so this is never a problem. The standard way to preserve application state is to store it in a database.

The ping/pong mechanism of Socket.IO is handled internally. If you want to send your own custom ping/pong events you can do it using normal events. The internal ones will still exist, though.