По итогам игротехники на прошедшей игре (была основана на основе чатов в телеграме) возник вопрос: как обеспечить в режиме «на минималках» следующую задачу:
1. текстовые чаты между пользователями как индивидуальные, так и групповые
2. возможность работы как в локальной сети, так и при подключении к интернету (т.е. доступ к чатам удалённызх пользователей).
*. возможность работы в mesh-сети между клиентскими устройствами будет плюсом.
3. нетребовательность к трафику (в идеале — укладываться в полосу 2400 бит/сек, в реальной ситуации показометр скорости на телефоне прыгал в интервале 0.3-3кб/сек).
4. устойчивость работы в случае нестабильного низкоскоростного коннекта — гарантированность доставки сообщений (автоматическая перепосылка их при обрыве соединения, не получении подтверждения о получении и т.п.).
5. наличие API для написания ботов.
6. Клиенты под Android, iOS.
*. наличие десктопных клиентов будет плюсом.
7. Юзерфрендли для обычного пользователя.
8. Нетребовательность к ресурсам: возможность развернуть серверную часть (если она есть) на *Pi или ПК прошлого/позапрошлого поколения (10-15 летней давности).
Matrix — не годится. Требует наличия доступа в интернет.
При взгляде на XMPP — всё кажется подходящим, кроме п.4 (и, возможно, п.3). При нестабильной связи теряются сообщения по словам знакомых, что плотно им пользовались.
Пока лучшим решением выглядит DeltaChat (мессенджер, транспортом для которого работает email). Но ввиду особенностей транспорта он небыстр, хотя в локалке может и будет достаточно шустр.
@cats-shadow как выглядел бы мир, если бы существовал протокол подходящий под все эти требования
Но некогда. Сейчас почти все протоколы очень тяжёлые. Живут нормально только при наличии ШПД.
@cats-shadow @termonoid а как же протокол Gemini ? Ну чем вам не легковес?
@cats-shadow может быть, но сама идея минимализма на новом. А веб-чат, а IRC? может что-то как-то допилить под новые реалии?
@cats-shadow
Костыли с сохранением чата при пропадании связи нужно пилить
IRC... Это релей. Как оно будет вести себя при пропадающем коннекте?
Вот что в RFC1459 написано
8.3 Message delivery
It is common to find network links saturated or hosts to which you
are sending data unable to send data. Although Unix typically
handles this through the TCP window and internal buffers, the server
often has large amounts of data to send (especially when a new
server-server link forms) and the small buffers provided in the
kernel are not enough for the outgoing queue. To alleviate this
problem, a "send queue" is used as a FIFO queue for data to be sent.
A typical "send queue" may grow to 200 Kbytes on a large IRC network
with a slow network connection when a new server connects.
When polling its connections, a server will first read and parse all
incoming data, queuing any data to be sent out. When all available
input is processed, the queued data is sent. This reduces the number
of write() system calls and helps TCP make bigger packets.
Но надо подумать и потестить.
И я к тому же. Буферизация какая-то должна быть так или иначе.
IRC... Это релей. Как оно будет вести себя при пропадающем коннекте?