Почитал и получается что я получаю доступ к соединению, находясь только внури хендлера.

А если я нахожусь вне хендлера, то как мне получить экземпляр соединения и отправить ему сообщение?

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

каналы?

Не, зачем усложнять так.

мне кажется, что это ты усложняешь

Просто думал эти вещи реализованы из коробки в этой библе, раз его так рекомендуют.

мне кажется, что это ты усложняешь

Хорошо что только кажется.

мне кажется, что это ты усложняешь

Ну хорошо. Давайте ваше мнение послушаем. Как получить список подключенных к сокету клиентов в горилле? И еще, как я могу усложнять, если еще оригинальный код примера не поменял?

список надо держать самому, в мапе, к примеру

список надо держать самому, в мапе, к примеру

Эххх, жаль, расстроил горилла.

Охренеть. Я еще на сокеты iris жаловался. )))))

А что не так-то?

А что не так-то?

Всё норм. Просто я горилла вебсокет с фреймворком вебсокетов попутал. В горилле в WS из коробки мало что есть, что помогло бы ускорить разработку.

именно для вебсокета я в горилле мало смысла вижу, да. юзаю golang.org/x/net/websocket

Сейчас попробую.

он не лучше, просто не тащит за собой гориллу

именно для вебсокета я в горилле мало смысла вижу, да. юзаю golang.org/x/net/websocket

А чем вам горила не нравится? Судя по описанию они умеет компрессию и ssl

И еще много всяких плюшек, которые не умеет стандартная реализация

Я например создаю глобальную мапу с юидами клиентов и ссылкой на них, а в структуре клиента уже храню вебсокет

А чем вам горила не нравится? Судя по описанию они умеет компрессию и ssl

ssl плохо умеет сам golang (примерно вдвое медленнее, чем openssl) а компрессия обычно не нужна - данных очень мало

ssl плохо умеет сам golang (примерно вдвое медленнее, чем openssl) а компрессия обычно не нужна - данных очень мало

Вдвое медленнее что? Создание соединения или замедляет его в два раза?

ssl плохо умеет сам golang (примерно вдвое медленнее, чем openssl) а компрессия обычно не нужна - данных очень мало

У кого данных мало? В вашей задаче может быть - да, а у других?

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

Вдвое медленнее что? Создание соединения или замедляет его в два раза?

создание соединения, конечно.

https://github.com/mholt/caddy

создание соединения, конечно.

Так мб создание соединения не так кретично для сокет соединения, вы не думали об этом?

У кого данных мало? В вашей задаче может быть - да, а у других?

у кого много - возьмет гориллу

Всё норм. Просто я горилла вебсокет с фреймворком вебсокетов попутал. В горилле в WS из коробки мало что есть, что помогло бы ускорить разработку.

я не в курсе задачи, но посмотрите на https://github.com/gobwas/ws на этом работают вебсокеты в почте mail.ru, статья https://habrahabr.ru/company/mailru/blog/331784/ вдруг под задачу лучше подойдёт

Так мб создание соединения не так кретично для сокет соединения, вы не думали об этом?

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

создание соединения, конечно.

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

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

А сфера, в которой так критично шифрование и еще и скорость открытия соединений?

я не в курсе задачи, но посмотрите на https://github.com/gobwas/ws на этом работают вебсокеты в почте mail.ru, статья https://habrahabr.ru/company/mailru/blog/331784/ вдруг под задачу лучше подойдёт

Задача - простота работы с веб сокетами без заморочек как в iris/websocket, но чтобы умел работать со стандартным http.ResponseWriter и http.Request

А сфера, в которой так критично шифрование и еще и скорость открытия соединений?

у нас были миллионы клиентов, и рестарт сервера вызывал массовый реконнект. чтобы обеспечить этот реконнект в приемлемых временных рамках возможностей go ssl не хватало. openssl, впрочем, тоже :)

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

А распределить клиентов по нескольким серверам, чтобы рестарт затрагивал лишь часть?

А распределить клиентов по нескольким серверам, чтобы рестарт затрагивал лишь часть?

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

у нас были миллионы клиентов, и рестарт сервера вызывал массовый реконнект. чтобы обеспечить этот реконнект в приемлемых временных рамках возможностей go ssl не хватало. openssl, впрочем, тоже :)

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

а! тогда понятно. вообще, ответ существует, и он "криптография эллиптических кривых"

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

Тут по скольки распределять, надо конкретно от задачи плясать, сколько критично, сколько нет и тд

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

на RSA приемлемой скорости добиться не удастся. go - где-то 250 соединений в секунду на ядро, openssl - где-то 512

Задача - простота работы с веб сокетами без заморочек как в iris/websocket, но чтобы умел работать со стандартным http.ResponseWriter и http.Request

Ну я гориллу взял, в принципе меня пока устраивает

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

не думаю, что у вас речь идет о миллионах клиентов. на бирже, все, же, торгуют десятки тысяч. ну и биржа приносит обычно достаточно денег, чтоб хоть на 1000 машин кластер поднять...

в мире го так же, как и везде, собственно. http.Get(), http.Post(), имхо, примерно то, что вам подойдет. В тело пишется набор байт, т.е. некоторый []byte, опять же как и везде. А дальше уже насколько вам фантазии хватит. Надо JSON, json.Marshall(), например...

Спасибо за развернутый ответ.

на RSA приемлемой скорости добиться не удастся. go - где-то 250 соединений в секунду на ядро, openssl - где-то 512

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

так а что делает прослойка, если бек ребутнулся и соединения оборвал?

так а что делает прослойка, если бек ребутнулся и соединения оборвал?

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

А те в свою очередь отдают клиентам, те просто такой ретранслятор, да мы получаем небольшой оверхед во времени доставки данных ~6-10нс, но зато мы экономим на пересоздании подключений и когда упадем в следствии одновременного коннекта к нам тонны клиентов

у вас в одну сторону данные текут? просто маркетдата? тогда вебсокет вам не нужен, а нужен Server-sent events

он сильно попроще, как протокол

нет, есть еще запросы на дату

и вот если соединение с бекендом переустановилось - как это обрабатывается?

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

если не секрет как авторизовываете клиентов по WS ?

так там же все с get начинается. хочешь - basic, хочешь - на куках

если не секрет как авторизовываете клиентов по WS ?

Куки, отданные от сессий.

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

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

если не секрет как авторизовываете клиентов по WS ?

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

так там же все с get начинается. хочешь - basic, хочешь - на куках

basic же подразумевает что просто в Headers передаешь строку? просто особо не вижу отличий от авторизации по куке

basic же подразумевает что просто в Headers передаешь строку? просто особо не вижу отличий от авторизации по куке

аха, ток в бэйзе передается логин/пасс в открытом виде, а в куке хранится только ключ, как правило

а чем плоха такая схема авторизации?: 1 .Устанавливается соединение по WS с любым клиентом 2. Внутри ws соединения клиент должен передать в json логин и пароль 3. Если данные коректные то запоминаем websocket.Conn

Можно и так, все зависит от задачи

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

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

Чем не удобна?

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

а! тогда понятно. вообще, ответ существует, и он "криптография эллиптических кривых"

гошный crypto/elliptic использовали или свое?

ERROR: S client not available

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

А какие ограничения на колл-во соединений?

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

Не, вы не поняли

у вас по факту уже есть вебсокет соединение

которое уже что-то весит

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

попробуйте, помучаетесь и потом придумаете что - нибудь другое)

ну или оставите все как есть

у вас не пошло из-за того что были нагрузки?

интересен опыт просто

интересен опыт просто

Так же реализованно, поднято туча вебсокетов. При переподключении чекаются куки, если куки норм то разрешается подключиться в противном случае на старницу авторизации

гошный crypto/elliptic использовали или свое?

не использовали - не успели

https://monades.roperzh.com/concurrency-is-different-than-parallelism/

Concurrency - по-русски переводят?

нет

хм... сoncurrency лучше

Что-то юмора такого не понимаю. Создал базу, структуру к ней написал, всё отлично работает. Как только закидываю на сервер получаю sql: Scan error on column index 3: converting driver.Value type <nil> ("<nil>") to a int64: invalid syntax Я знаю как лечится ошибка, но как такое может быть?

что конкретно?

Почему эта ошибка не выскакивает на домашнем компутере, почему она выскакивает на сервере?

хрустальный шар подсказывает - разный код

тысячи причин

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

в поле null записано

в проде в базе

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

Какая разница, прод, не прод? И там, и там Убунта.

его нельзя напрямую в инт записать напрямую

искать в ггуле handling null values go database/sql

Какая разница, прод, не прод? И там, и там Убунта.

ты ошибку ты реши, тогда узнаешь какая разница

ось конечно не влияет

его нельзя напрямую в инт записать напрямую

Я знаю, я этот код тестирую локально и всё работает.

Я знаю, я этот код тестирую локально и всё работает.

не на всех вариантах тестируешь