TS
Я тебе говорю, что то что ты предлагаешь только так можно реализовать, либо ты с сокетами давно не работал
Конечно, давай пихать везде unordered_map, когда можно выбрать более дружелюбную и правильную структуру
Size: a a a
2020 February 15
IZ
Конечно, давай пихать везде unordered_map, когда можно выбрать более дружелюбную и правильную структуру
не ну если ему надо искать по ключу?
RM
Конечно, давай пихать везде unordered_map, когда можно выбрать более дружелюбную и правильную структуру
Еще раз, смотри, у тебя есть приложение, представим что это Proxy сервер, на нем есть Client и Server, первый обрабатывает соединения между Proxy Server <—> Local Servers (master, db, game и т.д.) и Server обрабатывает соединения с клиентами
RM
Как ты собрался хранить соединения с клиентами или с локальными серверами в массиве - понятия не имею
TS
не ну если ему надо искать по ключу?
Я пока не увидел проблему, особенно когда у него не более 256 элементов
RM
Каждый массив индексируется по возрастанию, но при этом ID сокетов не факт что будут по возрастанию - это первое
RM
Второе, когда одно из соединений будет разорвано, а его индекс лежит в середине массиве. то что делать в таком случае?
RM
Тупо обнулить элемент по этому индексу? Тогда тебе сервер зафлудят и будет уязвимость с утечкой озу
TS
Ключ в мапе это у тебя что?
RM
Ключ в мапе это у тебя что?
ID соединения
RM
Сокет грубо говоря
TS
ID соединения
Их может быть не больше 25?
TS
Именно их?
IZ
Их может быть не больше 25?
нет, но да :)
RM
Их может быть не больше 25?
А как разница, даже если их 3
RM
Как ты определишь кто к тебе сейчас подключился?)
RM
И что делать когда один сервер слег и он переподключился вновь после восстановления
RM
То что ты предлагаешь - говно архитектуры
TS
Как ты определишь кто к тебе сейчас подключился?)
Каждому серверу выдавать идентификатор
RM
Каждому серверу выдавать идентификатор
Ага, а потом как определять, какой клиент к какому серверу конкретно подключен?)