Oсобенности реализации клиентской части. XEP-0410 MUC Self-Ping (Schrödinger's Chat) ------------------------------------------------------------------------------------------------------------------------ xep-0410 реализован не польностью. Согласно https://xmpp.org/extensions/xep-0410.html, существует минимум 2 варианта реализации обнаружения, что киент оотвалился от чатика. * С двухступенчатым пингом. Когда с jid-а локального пнгуется jid в конференции. Ответ доставляется на один из клиентов. Который в свою очередь должен ответить на этот ответ (отвечайте на мои ответы!), результат этого ответа передаётся оригинальному запросившему клиенту. * С серверной орптимизацией. (оптимизация анонсируется в ответе на запрос disco#info MUC-а) В этом случае пинг будет одноступенчатым и нам сразу же должен по идее вернуться result (то бишь pong) Двухступенчатая реализация вызывает вопросы. Во-первых, своей двухступенчатастью, а во-вторых, ответ на начальный пинг доставляется на один из клиентов (не на все!), а если этот клиент испытывает сетевые проблемы, то получается, страдают все клиенты. В нашем случае предполагается, что если клиентов больше одного, то он не должен своим состоянием аффектить других клиентов. И... тут есть другой момент - двухступенчатый пинг гораздо сложнее в реализации на клиентской стороне, т.к. надо обрабатывать значительно бОльшее количество кейсов сочетаний ошибок, которые могут возникнуть в ходе пинга. Вобщем, поддерживаем только второй вариант пинга, который с серверной оптимизацией. N.B. Но на IQ get ping с xmlns="urn:xmpp:ping" из первого шага мы всё-таки будем отвечать обычным result-ом (понгом, то бишь) N.B. Каждый пинг комнаты происходит в отдельной goroutne-ке, так что заходить в огромное количеств комнат (>1k) не рекомендуется xep-0199 XMPP Ping ------------------------------------------------------------------------------------------------------------------------ Cуществует несколько видов пинга: * Server-To-Client Pings * Client-To-Server Pings * Server-To-Server Pings * Client-to-Client Pings * Component-to-Client Pings Явным образом я реализовываю с2s. Плюс частично Component-to-Client в рамках N.B. по xep-0410. Ротация статусов ------------------------------------------------------------------------------------------------------------------------ Ротирование статуса реализовано через заддержки time.sleep, На каждый чат таким образом порождается по горутине. Если чатов много, это может вызвать проблемы. Причина бана ------------------------------------------------------------------------------------------------------------------------ Причину бана можно только включить или выключить в конфиге на per-chat основе. Фразу настроить невозможно. (не хотелось реализовывать парсинг темплейтов, как минимум даты-времени) Бан за фразы ------------------------------------------------------------------------------------------------------------------------ Бот не читает историю, когда присоединяется к чатам, поэтому если его какое-то время не было в комнате и кто-то произнёс непотребную фразу, ретроспективного бана не будет. Проблема реконнекта ------------------------------------------------------------------------------------------------------------------------ На текущий момент решена не совсем чисто. Скорее всего, при реконнекте утекают ресурсы, связанные с jabber-соединением. Проблема в том, что приходится пересоздавать основной "объект" со всеми его полями. Кроме того, sig handler фактичеки не завершается, потому что в него не приходит ни одного сигнала и формально остаётся висеть на channel-е навечно. А ещё есть пингеры каналов и пингеры сервера. Их бы тоже завершать явным образом.