gevent-socketio verwendet nicht meinen @ app.route-Endpunkt für Socket

9

Ich benutze Flask zusammen mit gevent-socketio:

%Vor%

Ich benutze ein hübsches Standard-Setup, um den Server zu starten:

%Vor%

Und ein hübscher Standard-Hook für meinen SocketIO-Namespace:

%Vor%

Ich habe jedoch Probleme, bei denen "Verbindungsereignisse" nicht auf dem Client ausgelöst werden. Nach ein wenig Graben erkannte ich, dass obwohl ich 127.0.0.1 - - [2013-08-19 12:53:57] "GET /socket.io/1/websocket/170191232666 HTTP/1.1" 101 - - Nachrichten in der Ausgabe bekam, ich die ws connect Nachricht nicht erhielt (während andere Druckanweisungen im Code gut funktionierten). Ich habe diesen Endpunkt auskommentiert, und tatsächlich wird er nicht einmal aufgerufen. Das würde erklären, warum mein Namensraum nicht benutzt wird. Aber warum? Registriere ich meinen Namensraum falsch?

print app.url_map ergibt:

%Vor%

Also nichts Außergewöhnliches.

Bearbeiten: Der Client-Code:

%Vor%     
Rotten194 19.08.2013, 17:11
quelle

2 Antworten

1

Das seltsame Verhalten ist wegen dieser Linie:

%Vor%

Socketio und der Werkzeug Debugger arbeiten nicht zusammen. Es gibt bereits eine offene Frage zu diesem Thema: Ссылка

Aber Sie können umgehen, indem Sie eine benutzerdefinierte Debugger-Klasse erstellen.

%Vor%

Der Patch basiert auf dem Umgebungsschlüssel wsgi.websocket, der anscheinend nur in Websocket-Aufrufen vorhanden ist. Sei vorsichtig, ich habe mir nicht viel Gedanken darüber gemacht, es könnte andere Probleme geben.

    
m2k 31.08.2013, 19:59
quelle
1

Nahm mich eine Weile, aber es sieht so aus, als hätte ich es gelöst, viel Spaß:

Ссылка

Auf den Punkt gebracht:

  • Sie müssen explizit die Werte aus dem Generator extrahieren, die von werkzeug.debug.DebuggedApplication immer dann zurückgegeben werden, wenn eine socket.io-Anfrage erkannt wird. Dies ermöglicht es, die Socket-Verbindung ordnungsgemäß herzustellen
  • socket.io-Namespace-Handler werden standardmäßig nicht von werkzeug abgedeckt. Sie müssen daher einen eigenen try catch einfügen, das traceback speichern, wenn eine Exception abgefangen wird, und sie dann innerhalb eines Request-Contexts erneut aufrufen
aldanor 29.09.2013 14:44
quelle