ну во первых multiplexing.. мы не ждём синхронно пока получим ответ на запрос А, а посылаем запрос Б и получаем возможно даже ответ на Б ранее А это не синхронная коммуникация

зачем?! не хотим ждать - используем канал с буфером. но, вообще-то, на то и горутины, чтобы отправить запрос и подоздать ответа, ну или ошибки

чувак из Авито делает

зачем?! не хотим ждать - используем канал с буфером. но, вообще-то, на то и горутины, чтобы отправить запрос и подоздать ответа, ну или ошибки

так если клиент не на go

при чем тут клиент?!

клиент пусть как хочет работает

при чем тут клиент?!

"asynchronous messaging" подразумевает что есть клиент

зачем?! не хотим ждать - используем канал с буфером. но, вообще-то, на то и горутины, чтобы отправить запрос и подоздать ответа, ну или ошибки

ты не понял.. имеется введу мултиплекс по вебсокету

так если клиент не на go

и на Go и на JS

https://github.com/centrifugal/centrifugo

прошёлся по highlights и честно говоря мало чего понял... это для чатов чтоли?

request-reply я тут не вижу совсем, это одна из главных фич нашей либы кстати

"аутентификация" какая-то есть, но конкретно про "сессии" ничего не написано

"каналы" типа chatroom'ы и у нас можно реализовать с помощью namespace'ов

понял

бинарный ли протокол - тоже не пояснено, у нас бинарный и очень компактный

там protobuf

да, это скорее похоже на чаты короче

а у нас скорее похоже на HTTP2 в обе стороны с ещё кучей плюх

а у нас скорее похоже на HTTP2 в обе стороны с ещё кучей плюх

есть ли шардирование из коробки?

ты не понял.. имеется введу мултиплекс по вебсокету

я не понял, потому и спрашиваю

со стороны go там синхронный интерфейс?

если да - не понятно, зачем дамба, она сама получится

со стороны go там синхронный интерфейс?

да client.Request, client.TimedRequest и client.RestoreSession блокируют до получения ответа от сервера, ошибки или таймаута, единственно client.Signal не блокирует

если да - не понятно, зачем дамба, она сама получится

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

ведь их может быть неопределённое множество

и сервер неизвестно вернётся ли

дамба для этого не нужна

получили запрос из канала, попробовали отправить

если ошибка - поспали милисекунду, снова попробовали

получили запрос из канала, попробовали отправить

попробовали, сервера нет, что делать?

и так, пока таймаут не истечет

как истек - вернули ошибку

тут, кстати, и канал не нужен, в принципе

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

если ошибка - поспали милисекунду, снова попробовали

заспамит сервер, дамба оптимизирует данную ситуацию: спит->просыпается->пробует->спит/ура! в данном случав выполняет только 1 горутина, все остальные встают в очередь и ждут её

тогда эта горутина может быть одна ровно

и принимать запросы через канал

и все встанут в очередь на записи в этот канал

ладно, короче долго объяснять, у тебя нет полного контекста ситуации

но дамба тут нужна

нет

не нужна

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

да

это делается так

вместе с запросом ты отправляешь канал, по которому тебе придет ответ

и встаешь на чтении этого канала

вместе с запросом ты отправляешь канал, по которому тебе придет ответ

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

для каждого запроса два канала - для ответа и для ошибки

но разве это плохо?

но разве это плохо?

зачем, если можно один для всех?)

так

а как ошибку-то вернуть ровно туда, откуда запрос пришел?

там сейчас регистр reqid -> {fail(), fulfill()} т.е. колбаки

и что, это хорошо, колбеки?

лучше, чем пара каналов?

а разве плохо?)

плохо

очень

и при отладке плохо, и при чтении кода

https://github.com/qbeon/webwire-go/blob/master/client/sendRequest.go#L16 вот тут создаётся новый request object а это собственно класс регистра: https://github.com/qbeon/webwire-go/blob/master/requestManager/requestManager.go

погоди

у тебя там уже есть канал для ответов

почему, собственно, не заблокироваться на его чтении?

зачем колбек?

ERROR: S client not available

где конкретно?

там, где ты запрос создал и отправил

короче sendRequest создаёт новый объект запроса, который откладывает в мап (reqid -> reqobj) requestManager'а. когда reader goroutine читающая из сокета парсит входящее сообщение и оно типа reply, тогда ищет по id данный запрос и либо фейлит его либо fulfill'ит в зависимости от овета, выполняя либо .fail() либо .fulfill() колбаки

это ок

reqobj да, есть канал типа reply с либо ошибкой либо данными

ну

ладно, остальное завтра

у объекта запроса есть AwaitReply

блокирующий метод

он то и читает из канала

так-что да, уже всё через каналы

дамба нужна не в этом место а в методе tryAutoconnect

ладно, реализую - покажу кому интересно

собственно получилось https://github.com/qbeon/webwire-go

У вас подтверждения доставки есть?

И зачем поверх вебсокетов весь этот велосипед?

У вас подтверждения доставки есть?

подтверждение доставки чего? сообщений? это гарантирует сам вебсокет запросов? они так или иначе возвращают ответ сигнал? доставка гарантируется, обработка - нет

И зачем поверх вебсокетов весь этот велосипед?

duplex messaging HTTP не обладает обратной связью, long polling - не решение, HTTP2 server-side push - не о том webwire позволяет работать с сервером через 1 единое соединение - асинхронно мультиплексить запросы и сигналы в обе стороны - бинарный протокол, очень компактный и легковесный - поддерживает по умолчанию UTF8 и UTF16 кодировки - гарантирует соединение, самовосстанавливается - сессии и аутентификация встроены.. ну и многое другое

впрочем тут всё описано: https://github.com/qbeon/webwire-go

WebWire provides a compact set of useful features that are not available and/or cumbersome to implement on raw WebSockets such as Request-Reply, Sessions, Thread-safety etc.

ну эт конечно лол

впрочем, если есть время пилить всякое такое, вай нот

Нужна помощь в написании отдельного Смарта под airdrop. Есть у кого опыт? Или знакомые? Заранее спасибо

подтверждение доставки чего? сообщений? это гарантирует сам вебсокет запросов? они так или иначе возвращают ответ сигнал? доставка гарантируется, обработка - нет

Да, сообщений.

duplex messaging HTTP не обладает обратной связью, long polling - не решение, HTTP2 server-side push - не о том webwire позволяет работать с сервером через 1 единое соединение - асинхронно мультиплексить запросы и сигналы в обе стороны - бинарный протокол, очень компактный и легковесный - поддерживает по умолчанию UTF8 и UTF16 кодировки - гарантирует соединение, самовосстанавливается - сессии и аутентификация встроены.. ну и многое другое

Почему просто не взять tcp и какой-либо фрейминг?

tcp это слишком низкоуровнево

Есть кто применяет JSON-RPC или нечто подобное?

В чате на 1500 человек точно хоть один да применяет. Спрашивай вопрос

Интересно кто с чем его применяет (http, websocket, protobuf) и было ли хорошим решение использовать RPC-style API

я применял поверх http и поверх udp

И как "впечатления", если так можно сказать?

jsonrpc 2.0 - норм