[В порядке бреда] Новая концепция работы сервера (а возможно и всего проекта) #185
Replies: 1 comment 1 reply
-
|
Я предлагаю другую концепцию - рой серверов. У нас есть группа серверов, дублирующая данные между собой. Клиент общается только с одним из них. В случае отключения этого сервера клиент просто подключается к другому и продолжает общение. Этот подход позволяет не менять ничего существенно в клиенте и просто обеспечить устойчивость сервера, теперь имеющий больше, чем одну точку отказа. Концепция связи серверовДопустим, мы хотим поднять сервер в качестве части сети других серверов. В конфиге мы указываем либо адрес одного сервера из этого роя(далее - сервер-пчела), либо доменное имя роя(например, morelia.main.org). При указании доменного имени наш сервер связывается с информационным сервером, сидящем на этом домене, и тот возвращает нам список серверов роя. В случае указания адреса сервера-пчелы, мы подключаемся к нему, и уже от него узнаем о других серверах. Наш сервер, при получении сообщения от пользователя сначала перешлёт его другому серверу, и затем запишет в свою бд новые данные, после чего вернёт клиенту ответ. В случае отключения сервера на время, а затем его включения, сервер сверяет свою бд с бд других серверов, и при наличии обновлений - пишет их в свою бд. В случае расхождения данных серверов, всегда выбираются данные, которые имеет у себя большинство из роя. Концепция работы клиентаКлиент общается с одним сервером как и ранее, тут всё без изменений. Для подключения мы выбираем либо доменое имя роя, либо один сервер из него. Затем, клиент сам автоматически выбирает более подходящие и близкорасположенные сервера и общается с ними. Одиночный серверТакже возможен запуск сервера вне сети, в автономном режиме В общем, если обобщить - то надо распилить наш сервер на кучу зеркальных, для обеспечения устойчивости сети Плюсы
Минусы
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Контекст-Вводная
Сегодня интернет невозможно представить без свободного общения между людьми, с возможностью озвучить разные мнения на окружающие нас вещи и события или координировать свою деятельность. Для некоторых представителей организаций/государств такая свобода является раздражителем, им иногда хочется все это хотя бы контролировать, а в особых случаях контролировать "жёсткой рукой" или вообще заблокировать. К сожалению, большая часть работы инфраструктуры (сервера, приложения) очень часто и достаточно сильно зависят от решения его собственника или регулятора (правительства) страны в котором находится собственник. Если процесс блокировки сети интернет отдельной страны (т.н. чебурнетизация) всё-таки сложная процедура, несущая огромные риски для самого регулятора, то процесс блокировки отдельной компании которая предоставляет услугу (например WhatsApp, Facebook, Instagram, Telegram) или процесс блокировки компанией своего пользователя представляет менее рисковую операцию и более результативно. Такое вмешательство разрушает концепцию интернета, и является грубым актом цензуры.
Со временем у пользователей появляется все больше и больше желания избежать самой возможности цензуры. Многие представители IT уже давно работают над инструментами которые смогут в этом помочь, и один из подходов называется децентрализация. С помощью децентрализованных программ и сервисов можно будет избежать цензуры и строить между людьми более надёжные каналы коммуникации. Основная проблема сейчас, это нежелание "массового" пользователя использовать инструменты децентрализации, в связи с их неразвитостью, а так же малой популярностью. По сути, сейчас децентрализованным сервисами пользуются те кто их создаёт, около itшное сообщество и политические активисты.
Что нужно поменять?
Проекту нужна бОльшая децентрализация и бОльшая аудитория.
Для лучшей децентрализации morelia_server должен уметь общаться не только с клиентами (пользователями) но и с другими morelia_server.
Для лучшего охвата аудитории morelia_server должен уметь связывать между собой разные протоколы (MTP, Matrix, telegram и т.п.).
Ещё проекту нужна киллер-фича, отличающая его от других, такой киллер-фичей может стать использование протокола MQTT как для общения людей так и для общения и управления IoT-устройствами.
Таким образом morelia_server может стать центральным элементом связующим между собой IoT устройства и общение между собой людей.
Предложение
Предлагаю обсудить новый вариант работы morelia_server в результате чего:
при этом morelia_server всё так же будет работать через websocket и так же поддерживать родной протокол MTP (и в будущем Matrix) с шифрованием и прочими плюшками.
Подробнее
Идея в следующем: перевести morelia_server на работу по протоколу MQTT (который работает как через TCP, так и через websocket). Таким образом morelia_server превращается в промежуточное (в терминалогии MQTT - брокер) звено между клиентами и, не храня данные, отвечает только за передачу сообщений по принципу "один-ко-многим". При этом MQTT-протокол позволяет внутри передавать JSON-объекты в полном соответствии с протоколом (MTP/Matrix/etc).
MQTT
Что такое MQTT можно почитать здесь. Кратко, в протоколе MQTT есть две сущности:
topic- внутренний адрес (расположение) данных - в виде пути к файлу, например:/workspace/MoreliaTalkpayload- объект данных привязанный к конкретномуtopic, например строка, JSON, bytes и т.п.Все клиенты подписываются на необходимые им
topicчерез брокера и получают/отправляютpayloadтолько в этотtopic. Брокер получивpayloadв определённыйtopicотправляет этотpayloadвсем клиентам которые подписались на этот жеtopic.Функционал morelia_server
Плюсы
Минусы
Beta Was this translation helpful? Give feedback.
All reactions