Как создать связь между приложениями на golang в реальном времени?

Question

[Роман Ракзин]

Добрый день,
Есть сервер и к нему должны подключаться клиенты. Нужно сделать канал и в реальном времени уведомлять сервер/клиентов.
Как сделать websocket соединение, но не между сервером/браузером, а двумя программами на golang?
Либо посоветуйте другую технологию, что б можно было по каналу отправлять json данные.

Спасибо

Comments

[Владимир Грабко]

Я вас не понимаю. Пометили ответом и убрали.

[Роман Ракзин]

Да- спасибо. Я 2 раза кликнул. Ещё вопрос- А есть в библиотеки функция, что б если обрыв в сети будет- её запустить и реконектится через определённое время?

[Владимир Грабко]

Роман Ракзин: сделаю.

[Роман Ракзин]

Владимир Грабко: Спасибо большое. И например ещё для сервера функции ClientConnected / ClientDisconected, что б отслеживать подключенных клиентов

[Владимир Грабко]

Роман Ракзин: для сервера уже сегодня будут. А для клиента на днях.

[Владимир Грабко]

Роман Ракзин: а что вы хотите получать в функциях ClientConnected ClientDisconected ?

[Роман Ракзин]

Ну я думаю на сервере сделать слайс и хранить данные о онлайн клиентах типа {number,Name...,Socket} и когда соккет закрывается(по обрыву либо отключению), то я удаляю его из онлайн таблицы. И когда мне нужно отослать всем либо одному- я беру их/его соккет и отсылаю, что б типа была функция SendToSocket(Socketnumber) или SendToAll() .А когда срабатывает ClientConnected() - я знаю, что нужно добавить в таблицу онлайн - новый соккет. и если срабатывает ClientDisconected(111) - я удаляю сокет 111 из неё. Ну как-то так....

[Роман Ракзин]

или как-то подписаться на событие ClientConnected(), которое будет возвращать данные, например SocketId:111;ClientId:22;Name:"Иванов Иван";Socket: SocketType, ну либо просто SocketId(атомарно увеличивающийся с каждым подключением) и сам Socket

[Роман Ракзин]

Владимир Грабко: Посмотрел Ваш файл server.go .Если б в момент закрытия как-то уведомлять омновную программу об этом. Это через каналы делать? или можно как-то подвязываться на события?

[Владимир Грабко]

Роман Ракзин: я вечером или завтра утром залью обновление сервера.

[spotifi]

msgpack, protobuf, grpc

[spotifi]

TCP/IP, unix sockets

[Владимир Грабко]

Роман Ракзин: всё. Залил. Используйте на здоровье)

[Владимир Грабко]

spotifi: TCP/IP, unix sockets... вы ссылку смотрели которую мы обсуждаем то?

[spotifi]

Владимир Грабко: ага

[spotifi]

Не понравилось.
Сыро.

[Владимир Грабко]

spotifi: если можно подробней.

[spotifi]

Владимир Грабко:
Поподробнее см. msgpack, protobuf, grpc.

[spotifi]

Владимир Грабко: но как проект для тренировки - очень хорошо. так-то ты молодец. продвигаешь. дока есть вменяемая.

Answer 1

[Владимир Грабко]

https://github.com/v-grabko/Core/wiki/TcpClientServer

В любом случае вы будете делать тоже самое. Я просто уже сделал абстракцию.

Comments

[Oleg Shevelev]

Посмотрите net/rpc и если приложения на одном физическом сервере то unix.socket в качестве адреса. Бездумно копировать решение Владимира не стоит:)

[Владимир Грабко]

Oleg Shevelev: не стоит не чего копировать не подумав ;D. А если всё это добро на разных серверах то довольно шустро работает. net/rpc у меня вообще не взлетело. Более чем уверен из-за того что я плохой повар)

[Oleg Shevelev]

Владимир Грабко: может быть, всё может быть:) Ещё про gorpc хорошо отзываются, но у меня пока не было времени его попробовать:) goprotoboof тоже чуть ли не фаворит в этом деле. В общем выбрать есть из чего.

Стоит ли использовать WebSockets для таких целей? Скорее нет. Потому что поверх вам придётся всё равно писать много логики, а если коннект разорвётся то желательно делать два и более канала между двумя точками, в специализированных протоколах это должно лучше решаться.

[Владимир Грабко]

Oleg Shevelev: там не WS а TCP сокет

[Владимир Грабко]

Oleg Shevelev: goprotoboof я тестил. Медленее чуть ли не в два раза.

[Владимир Грабко]

Oleg Shevelev: по сути человек хотел гонять json. Мое решение подходит под вопрос. Там не было не чего о рпц и прототипном буфере. Верно?)

[Oleg Shevelev]

Владимир Грабко: про websockets это уже топикпастер спрашивал.

Почему медленнее (goprotoboof)? Выяснил причину?

[Oleg Shevelev]

Владимир Грабко: сегодня он хочет отправить json, а завтра картинку, а после завтра... блокчейн:)

[Владимир Грабко]

Oleg Shevelev: я предполагаю из-за того что данных по сети больше ходит.

[Владимир Грабко]

Oleg Shevelev: там же для каждой строки тип слался и т.д. + парсинг точно медленее чем у json

[Oleg Shevelev]

Владимир Грабко: что лишнее передаётся? В теории оно же в бинарный узко-специализированный формат компилируется...

[Владимир Грабко]

Oleg Shevelev: типы у меня точно передавались (возможно это можно отключить. Хз)

[Роман Ракзин]

ну пока я думал джейсоном пересылать типа {"commadnd":"command1","data":{"param1":1}} . Распарсиватель этого я сделал вручную без rpc (не знаю- на сколько это профессионально, но работает). Пересылку картинок и др. данных пока не планировал, но возможно потом-да. Ещё вопрос- если я ставлю 80 порт? Нужно, что б порт не блокировался брандмауером по умолчанию и 99% что б был открыт по умолчанию- без лишних установок. И если будет http server - то параллельно они будут работать,на сколько я понял, так как там разные протоколы?

[Владимир Грабко]

Роман Ракзин: каждый сервер == свободный порт. На одном порте оно работать не будет. Ну можно повесить nginx на 80 и проксировать на все остальные сервисы через него. Тогда всё будет на 80.

[Владимир Грабко]

Роман Ракзин: и вместо обычного http юзай fasthttp он быстрее

[Илья]

Владимир Грабко: Что? Протобуф медленее и занимает больше сеть? Вы чем-то не тем пользовались. И типы там не шлются, они определяются в протофайле. При помощи него и идет десериализация. И да, там идёт в двоичном формате сообщения.

[Владимир Грабко]

FireGM: я юзал какую то библиотеку с гита. Возможно она корявая была.

[Gizmothron]

Владимир Грабко: нужно юзать не версию 2, которая "релиз", а версию 3, которая типа "бета". она бета уже несколько лет - ее весь мир спокойно юзает.

[Gizmothron]

Владимир Грабко: fasthttp - имеет смысл только при бешенных нагрузках на сервере.

она разгружает сервер, но не добавляет скорости к каналу связи между сервером и клиентом - там же все равно остается текст и http

[Gizmothron]

Владимир Грабко: protobuf - протокол уже много лет являющийся стандартом внутри Google, при связи между его серверами. он не может быть медленным или глюкавым.

[Владимир Грабко]

Gizmothron: а что мешает сразу писать на fasthttp? Он же даёт почти всё

[Gizmothron]

Владимир Грабко: несовместимость со стандартным стеком net/http. Значит, ты будешь лишен кучи полезных библиотек.

[Gizmothron]

Владимир Грабко:
скорость связи он не дает. сеть между компьютерами не зависит от двух программ на Go на обоих концах канала связи.

к тому же, если речь идет о голых сокетах - они существенно быстрее любого http, будь он хоть трижды fast.

[Gizmothron]

Владимир Грабко: я бы и на TCP не полагался, если речь идет о максимизации скорости. только UDP.

[Владимир Грабко]

Gizmothron: upd будет медленее работать так как нужна обезательная доставка пакетов.

[Владимир Грабко]

Gizmothron: а анолог tcp я точно делать не хочу.

[Владимир Грабко]

*аналог

[Gizmothron]

Владимир Грабко:
fasthttp всего лишь уменьшает нагрузку на сервере
и именно по обмену информацией по протоколу http.

однако, если у тебя затык по http, то это закономерно означает, что в остальных местах твоей системы (например, при работе с БД) у тебя будет на порядки больший затык.

и тебе не будут полезны фичи fasthttp до тех пор пока ты живешь на одном единственном-сервере. или пока твой сервер не сопоставим с сервером авторов fasthttp. у них сервер с огромным количество оперативной памяти.

то есть ты еще и не сможешь утилизировать fasthttp в полный рост и уже потеряешь возможность использовать наработки сообщества по net/http.

[Gizmothron]

Владимир Грабко: Ну есть QUIC. Есть даже его реализация на Go.
Это как бы http на стероидах на базе UDP.

Думаю, что должны быть подобные вещи и без какой либо привязки к http.

[Gizmothron]

Владимир Грабко:
> upd будет медленее работать так как нужна обезательная доставка пакетов.
> а анолог tcp я точно делать не хочу.

Не будет.
Никто не мешает слать повторно пакет, не дожидаясь ответа.
Если измерять среднее время доставки пакетов и получения ответов
и посылать страховые пакеты-дубли, скажем, по достижению 80% этого времени.

[Владимир Грабко]

Gizmothron: я нуб в этом. Простите.

[Gizmothron]

Владимир Грабко:
fasthttp базируется на основе стандартного неэффективного http, и его задача снизить нагрузку на сервер, а не увеличить скорость доставки.

[Gizmothron]

то есть fasthttp отказывается от net/http гошного.
но вынужден использовать стандартный сетевой протокол http. который текстовый, многословный и неэффективный по скорости.

Answer 2

[Gizmothron]

websocket - это только если нужна совместимость в https.

Если по сети:

gRPC если нужна защита.
Или просто Google Protobuf - это очень быстро.
msgpack - это типа protobuf, но без необходимости описывать протокол, это как бы бинарный json.

Есть еще gotalk

Если все на одном физическом компьютере - то unix sockets.

Только термин "реальное время" означает совсем иное.
websocket априори не может быть в "реальном времени", так как это сетевой протокол.