Wie wird ein WAMP-Aufrufer nach einer erneuten Verbindung mit Autobahn Python mit Twisted ReconnectingClientFactory erneut registriert?

Question

Ich habe eine Autobahn-Python-Client-Anwendung mit Twisted, die mit einem Crossbar.io-Server verbunden ist. Die Clientanwendung kann die Verbindung nach dem Verlust der Netzwerkverbindung mithilfe von ReconnectingClientFactory erfolgreich wiederherstellen. Der Client registriert bei der Verbindung einen Angerufenen, so dass andere Anwendungen ihn anrufen können. Dies funktioniert immer bei der ersten Verbindung.

Bei der Wiederherstellung nach einer verlorenen Verbindung kann der Name des Angerufenen jedoch nicht erneut registriert werden, da der Name des Angerufenen weiterhin von der zuvor verlorenen Verbindung registriert wird. Dies führt zu dem Fehler 'wamp.error.procedure_already_exists'. Da die Registrierung des Angerufenen immer noch mit der zuvor verlorenen Verbindung verbunden ist, muss ich den alten Angerufenen abmelden.

Die einzige Lösung, die ich sehen kann, ist die Generierung und Registrierung eines eindeutigen neuen Angerufenen-Namens auf jeder Verbindung, um Kollisionen mit zuvor registrierten Angerufenen-Namen zu vermeiden.

Gibt es einen besseren oder einfacheren Weg, damit umzugehen? Es scheint, dass das WAMP-Protokoll es ermöglichen würde, einen Angerufenen-Namen von einer anderen Verbindung mit der Registrierungs-ID zu entfernen, aber die Autobahn-Python-Client-Bibliothek scheint dies nicht zu erlauben.

Answer 1

Ich habe die falsche Frage gestellt. Der Crossbar.io-Server sollte erkennen, wenn ein Client getrennt wird, und automatisch die Registrierung von Anrufern aufheben, die zu dieser getrennten Sitzung gehören (nach Tobias Oberstien auf Twitter: https://twitter.com/oberstet/status/642241167216746496). Dies liegt nicht in der Verantwortung der Autobahnkunden.

Mein Problem war, dass mein Crossbar.io-Server keine Client-Verbindungsabbrüche feststellte, die auftraten, wenn Client-Netzwerkverbindungen abrupt getrennt wurden, sodass die Bereinigung nicht stattfand.

Dieses Verhalten ist einfach auf die Konfiguration des Crossbar-Servers zurückzuführen. Ich habe seitdem das Beispiel "Produktionseinstellungen" verfolgt, das auf der Crossbar-Site dokumentiert ist (http://crossbar.io/docs/WebSocket-Options/). Ich habe jetzt das Verhalten, nach dem ich gesucht habe, wo Sitzungen, die von einer unterbrochenen Verbindung übrig geblieben sind, automatisch erkannt und bereinigt werden.