Как создать связь между приложениями на golang в реальном времени?
Добрый день,
Есть сервер и к нему должны подключаться клиенты. Нужно сделать канал и в реальном времени уведомлять сервер/клиентов.
Как сделать websocket соединение, но не между сервером/браузером, а двумя программами на golang?
Либо посоветуйте другую технологию, что б можно было по каналу отправлять json данные.
Да- спасибо. Я 2 раза кликнул. Ещё вопрос- А есть в библиотеки функция, что б если обрыв в сети будет- её запустить и реконектится через определённое время?
Ну я думаю на сервере сделать слайс и хранить данные о онлайн клиентах типа {number,Name...,Socket} и когда соккет закрывается(по обрыву либо отключению), то я удаляю его из онлайн таблицы. И когда мне нужно отослать всем либо одному- я беру их/его соккет и отсылаю, что б типа была функция SendToSocket(Socketnumber) или SendToAll() .А когда срабатывает ClientConnected() - я знаю, что нужно добавить в таблицу онлайн - новый соккет. и если срабатывает ClientDisconected(111) - я удаляю сокет 111 из неё. Ну как-то так....
или как-то подписаться на событие ClientConnected(), которое будет возвращать данные, например SocketId:111;ClientId:22;Name:"Иванов Иван";Socket: SocketType, ну либо просто SocketId(атомарно увеличивающийся с каждым подключением) и сам Socket
Владимир Грабко: Посмотрел Ваш файл server.go .Если б в момент закрытия как-то уведомлять омновную программу об этом. Это через каналы делать? или можно как-то подвязываться на события?
Oleg Shevelev: не стоит не чего копировать не подумав ;D. А если всё это добро на разных серверах то довольно шустро работает. net/rpc у меня вообще не взлетело. Более чем уверен из-за того что я плохой повар)
Владимир Грабко: может быть, всё может быть:) Ещё про gorpc хорошо отзываются, но у меня пока не было времени его попробовать:) goprotoboof тоже чуть ли не фаворит в этом деле. В общем выбрать есть из чего.
Стоит ли использовать WebSockets для таких целей? Скорее нет. Потому что поверх вам придётся всё равно писать много логики, а если коннект разорвётся то желательно делать два и более канала между двумя точками, в специализированных протоколах это должно лучше решаться.
ну пока я думал джейсоном пересылать типа {"commadnd":"command1","data":{"param1":1}} . Распарсиватель этого я сделал вручную без rpc (не знаю- на сколько это профессионально, но работает). Пересылку картинок и др. данных пока не планировал, но возможно потом-да. Ещё вопрос- если я ставлю 80 порт? Нужно, что б порт не блокировался брандмауером по умолчанию и 99% что б был открыт по умолчанию- без лишних установок. И если будет http server - то параллельно они будут работать,на сколько я понял, так как там разные протоколы?
Роман Ракзин: каждый сервер == свободный порт. На одном порте оно работать не будет. Ну можно повесить nginx на 80 и проксировать на все остальные сервисы через него. Тогда всё будет на 80.
Владимир Грабко: Что? Протобуф медленее и занимает больше сеть? Вы чем-то не тем пользовались. И типы там не шлются, они определяются в протофайле. При помощи него и идет десериализация. И да, там идёт в двоичном формате сообщения.
Владимир Грабко: protobuf - протокол уже много лет являющийся стандартом внутри Google, при связи между его серверами. он не может быть медленным или глюкавым.
Владимир Грабко:
fasthttp всего лишь уменьшает нагрузку на сервере
и именно по обмену информацией по протоколу http.
однако, если у тебя затык по http, то это закономерно означает, что в остальных местах твоей системы (например, при работе с БД) у тебя будет на порядки больший затык.
и тебе не будут полезны фичи fasthttp до тех пор пока ты живешь на одном единственном-сервере. или пока твой сервер не сопоставим с сервером авторов fasthttp. у них сервер с огромным количество оперативной памяти.
то есть ты еще и не сможешь утилизировать fasthttp в полный рост и уже потеряешь возможность использовать наработки сообщества по net/http.
Владимир Грабко:
> upd будет медленее работать так как нужна обезательная доставка пакетов.
> а анолог tcp я точно делать не хочу.
Не будет.
Никто не мешает слать повторно пакет, не дожидаясь ответа.
Если измерять среднее время доставки пакетов и получения ответов
и посылать страховые пакеты-дубли, скажем, по достижению 80% этого времени.
Владимир Грабко:
fasthttp базируется на основе стандартного неэффективного http, и его задача снизить нагрузку на сервер, а не увеличить скорость доставки.
то есть fasthttp отказывается от net/http гошного.
но вынужден использовать стандартный сетевой протокол http. который текстовый, многословный и неэффективный по скорости.
websocket - это только если нужна совместимость в https.
Если по сети:
gRPC если нужна защита.
Или просто Google Protobuf - это очень быстро.
msgpack - это типа protobuf, но без необходимости описывать протокол, это как бы бинарный json.
Есть еще gotalk
Если все на одном физическом компьютере - то unix sockets.
Только термин "реальное время" означает совсем иное.
websocket априори не может быть в "реальном времени", так как это сетевой протокол.
