LINUX.ORG.RU

Сервис обмена данными

 


0

1

Есть ли в сети сервис, позволяющий реализовать общение клиент-сервер, что-то на подобии клиент->серверF<-серверS?

Т.е. клиент посылает данные на серверF, серверS опрашивает серверF на предмет наличия чего-то новенького.

Дело в том, что нужно часто пересылать небольшие объемы информации (до 1КБ) от клиента на серверS, у которого нет белого IP.

Пока реализовал это через Телеграмм, т.е. информация с помощью TelegramAPI в тупую идёт сообщениями через телегу, с одной стороны как клиент - сервер залогиненный под обычного пользователя, а серверS сидит под ботом на веб-хуке. Но мне кажется, я изобрел велосипед с верёвкой вместо цепи.

Потрясно. Как думаешь, сама телега как это делает? О_о ты наколхозил api к api

Как мысль: напиши бота в телеге для обмена сообщениями, будет бомба.

Anoxemian ★★★★★
()

Если уж используешь телегу, зачем такие сложности? Там есть канал «Избранное». Кидай файлы и сообщения туда, оно станет доступно на всех клиентах, залогиненных под этим же пользователем.

Но проще, имхо, общаться по мылу. SMTP/IMAP-клиента реализовать легче, парсить сообщения проще и тут уже не обязательно самому себе слать, а сделать для сервера отдельный ящик на любом бесплатном мейлере. Если не доверяешь чужой почте, сообщения можно шифровать с помощью gpg.

shell-script ★★★★★
()

Если серверF - не твой, то у тебя выбор лишь из того, кому (какой организации) ты доверишься как посреднику. Всё остальное детали реализации, мало на что влияющие. Какого-то единого главного стандарта, разумеется, нет.

firkax ★★★★★
()
Ответ на: комментарий от shell-script

Но проще, имхо, общаться по мылу. SMTP/IMAP-клиента реализовать легче, парсить сообщения проще и тут уже не обязательно самому себе слать, а сделать для сервера отдельный ящик на любом бесплатном мейлере. Если не доверяешь чужой почте, сообщения можно шифровать с помощью gpg.

Либо свой почтовик поднять в качестве «центрального» сервера. Удваиваю этот вариант.

Zhbert ★★★★★
()

Если тебе надо организовать общение двух устройств, каждое из которых за NATом - смотри в сторону overlay networks, например, Tailscale нынче популярна.

si0 ★★★
()

Большое всем спасибо за предложения Действительно использование почты и MQTT выглядит очень интересным, по крайней мере это будет лучше чем Telegram

Но тут товарищ @si0 подсказал такую вещь, мне кажется буду дальше копать в эту сторону, поскольку это предоставляет больше возможностей при меньших усилиях

Architector
() автор топика
13 октября 2022 г.

К меня тут есть ветка где твоя схема реализована, но проблема возникла когда серверов Ф много.

Если Ф один, то складывай сообщения от клиентов в постгрес, там же настрой публикацию нужной тебе таблицы, а на С настрой подписку и пострес С будет сам из-за ната удерживать соединение с Ф и обновлять свою таблицу

fMad ★★
()
Последнее исправление: fMad (всего исправлений: 2)