Свой собственный FD_SET для TCP сокета

Приветствую. Я пишу приложение на TCP сокетах и мне не совсем хватает возможностей для учета подключенных клиентов.
В общем, нужно как то реализовать хранение каких либо дополнительных данных для каждого подключенного клиента.
Представим, что имеется сервер, на который могут приходить сотни подключений в секунду. Мне нужно отключить клиента через 5 секунд, если он не отправил никаких запросов ко мне на сервер, по этому нужно хранить время подключения каждого клиента, но где мне это сделать, если FD_SET рассчитан лишь на хранение сокета подключившегося клиента?
Мне пришла только идея, создать массив структур, которые будут хранить активный в данный момент сокет клиента и данные о времени подключения клиента.
Естественно придется все время перебирать данный массив структур и тратить на это время (в принципе как и FD_* макросы). Хотелось бы избежать любых дорогостоящих операций, потому что далее их при поступлении запроса их и так будет предостаточно.
Хотел сделать в FD_SET примерно такую структуру:
Но в таком случае, мне нельзя использовать select, потому что он ожидает массив SOCKET.
В таком случае, мне вероятно пришлось бы написать свою версию функции select.

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

Мне кажется что я иду неправильным путем и начинаю изобретать велосипед.
Есть ли какие то нормальные методы решения моей проблемы?

0

Сообщение от Skymotion В общем, нужно как то реализовать хранение каких либо дополнительных данных для каждого подключенного клиента.

Почему не использовать два массива? Только не забывать их поддерживать в консистентном состоянии.

1

Croessmah, не совсем понял вашу идею

0

А у вас выбора нет.
Если вам надо быстро и качественно — придётся читать из портов завершения ввода‐вывода или io_uring на линексе.
Если вам надо медленно и кроссплатформенно — придётся использовать устаревший select.

1

Сообщение от Замабувараев придётся использовать устаревший select.

Есть еще poll/WSAPoll, например.

Сообщение от Skymotion не совсем понял вашу идею

Посмотрите что-то подобное:
https://gist.github.com/Alexey... ver-c-L279

1

0

Сообщение от Замабувараев придётся использовать устаревший select.

Хорошо, я понял. А я могу НЕ использовать select и при этом обеспечить корректную работу своего сервера?

Добавлено через 9 минут
Croessmah, все равно мне придется перебирать циклом этот массив, что будет занимать время, но все же это более разумное решение.

0

Сообщение от Skymotion А я могу НЕ использовать select

Если вы можете не использовать select, то лучше сразу использовать IOCP.

0

Замабувараев, если все же поступать таким образом, мне придется использовать ОС Windows, ибо в принципе с самим linux я не особо знаком, тем более с его специфичными возможностями в API.

0

Сообщение от Skymotion они сильно сломают кроссплатформенность.

Свой http-сервер менее чем в 40 строк кода на libevent и C++11

Сообщение от Skymotion что будет занимать время

Сообщение от Skymotion Представим, что имеется сервер, на который могут приходить сотни подключений в секунду.

Это много для человека, а для сервера - пыщ и уже всё обработано.
Решайте проблемы с производительностью тогда, когда наступят эти проблемы, а то вы рискуете так ничего и не сделать в погоде за супер-скоростью, которая может даже и не потребуется.

0

*в погоне.
Совсем старый стал.

0