Как перерегистрировать сообщение WAMP после повторного подключения с использованием Autobahn Python с Twisted ReconnectingClientFactory?

Question

У меня есть клиентское приложение Autobahn Python с использованием Twisted, который подключен к серверу Crossbar.io. Клиентское приложение может успешно повторно подключиться после потери сетевого подключения, используя ReconnectingClientFactory. Клиент регистрирует имя вызываемого абонента при подключении, чтобы другие приложения могли его вызвать. Это всегда срабатывает при первоначальном подключении.

Однако при восстановлении после утерянного соединения имя вызываемого абонента не может быть перерегистрировано, поскольку имя вызываемого абонента все еще зарегистрировано из предыдущего потерянного соединения. Это приводит к ошибке «wamp.error.procedure_already_exists». Поскольку регистрация имени вызываемого абонента все еще связана с предыдущим потерянным соединением, я должен отменить регистрацию старого имени вызываемого абонента.

Единственное решение, которое я вижу, - это создать и зарегистрировать уникальное новое имя вызываемого абонента в каждом соединении, чтобы избежать столкновения с ранее зарегистрированными именами вызываемых лиц.

Есть ли лучший или простой способ справиться с этим? Похоже, что протокол WAMP позволяет отменить регистрацию имени вызываемого абонента из другого соединения с использованием идентификатора регистрации, но клиентская библиотека Autobahn Python, похоже, не позволяет этого.

Answer 1

Я задал неправильный вопрос. Сервер Crossbar.io должен обнаруживать, когда клиент отключен, и автоматически отмените учетные записи, принадлежащие к этому отключенному сеансу (для Tobias Oberstien on Twitter: https://twitter.com/oberstet/status/642241167216746496). Это не ответственность клиентов Autobahn.

Моя проблема заключалась в том, что мой сервер Crossbar.io не обнаруживал отключения клиентов, возникающие при внезапном отключении сетевых подключений клиентов, поэтому очистка не происходила.

Такое поведение просто связано с конфигурацией сервера Crossbar. Я с тех пор следил за примером «настройки производства», зарегистрированным на сайте Crossbar (http://crossbar.io/docs/WebSocket-Options/). Теперь у меня есть поведение, которое я искал, когда сеансы, оставшиеся после сломанного соединения, обнаруживаются и очищаются автоматически.