надо ещё написать что сообщения в ws называются фреймами и об их ограничениях, потому что посылая сообщение можно получить 1 и более фреймов и это всплывает на принимающей стороне, особенно в стандартном пакете go net/http
vetsmen: тогда ещё проще: хранишь ключ-значение. Ключ-логин пользователя, значение-объект хранящий флаг авторизации и кол-во сокетных соединений. При дисконнекте: уменьшаешь кол-во на 1, если кол-во сокетных соединений 0, то убираешь пользователя из словаря, если нет, то выставляешь флаг в актуальное значение. При каждой операции проверяешь словарь и флаг авторизации для пользователя.
vetsmen: тебе нужно хранить словарь, где ключ - это логин, а значения - это список указателей на открытые сокеты, как только один из сокетов инициирует логаут, ты пробегаешь по списку и логаутишь все соединения.
Владимир Грабко: ты начни в БД писать асинхронно и нагрузка спадёт, асинхронно в данном случае означает, что в течение 2-3 секунд копишь сообщения в кэше, далее сбрасываешь в БД. При обращении клиента, если он находит диалог в кэше в базу лезть не нужно
Rou1997: есть одна важная особенность, сокетное соединение оборвавшееся на другом конце без пинга и ближайшего посыла сообщения с первого конца будет считать открытым, где стабильность? я к тому, что пинговать всё равно придётся, но выделять на это целый поток - в корне неправильно, переключение операционкой между потоками будет одним из узких мест
так же по независящим от клиента/сервера причинам соединения могут обрываться достаточно часто (всё же мы в интернете, и пакеты ходят через NAT которые сконфигурены по-разному)
по потоку на соединение - слишком оптимистичная оценка возможностей машины и реальности
Rou1997:
1) чистые потоки тяжелы (они ведь будут однородную работу выполнять), поток на юзера - это одна из ошибок новичков, поэтому глянь примеры конкурентных моделей (как устроены пулы соединений, всякие менеджеры соединений), в некоторых случаях будет достаточно на гитхабе код посмотреть
2) www.cse.unsw.edu.au/~cs9242/07/lectures/10-threads.pdf
