> первое упоминание AsyncSelect...


первое упоминание было в [0], но чуть детальнее в:

> Очень Злой   (27.10.11 11:26) [23]


Ну не привел я с самого начала весь код, ибо меня больше интересовала методика прием данных с сокетов  (с точки зрения транспортного уровня) и обработка пакетов (с точки зрения протокола прикладного уровня). Т.е. оптимальная организация такого процесса...

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

Но, если мне нужно создавать несколько соединений с сервером, то я должен создавать столько же объектов - экземпляров этого класса.
На мой взгляд это расточительно с точки зрения использования ресурсов. Кроме того есть другие причины, по которым желательно было бы чтобы данный класс поддерживал не 1 соединение с сервером а несколько.
Пока возникла проблема такого рода:
Кроме дескриптора сокета, имеются другие данные привязанные к этому сокету (ключи шифрования, буфер для временного хранения неполных пакетов, и т.д.).
Но при использовании WSAAsyncSelect оконная функция получает сообщение, в котором указывается дескриптор сокета и прочие данные, а вот как мне при этом передать и получить ссылку на остальные данные, привязанные к сокету?

У тебя один-единственный поток обслуживает туеву хучу сокетов ?

> Сергей М. ©   (02.11.11 19:29) [62]
>
> У тебя один-единственный поток обслуживает туеву хучу сокетов
> ?


Да. Ну не то чтобы туеву хучу, но сокетов 10-15

> сокетов 10-15

Смешная же цифирь)..

И чего ж там такого "расточительного" ?

> Смешная же цифирь)..


Ну в принципе да.

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

imho, ради десятка-другого коннектов нет резона всерьез задумываться над оптимальностью.

Пройтись в цикле по списку структур, ассоциированных с коннектами, в поисках нужного коннекта - это займет смехотворное время.

Даже в TServerSocket над этим Борланд не задумывалась (хотя это вовсе и не показатель оптимальности) - в неблок.режиме там для каждого сокета, включая слушающий, создается отдельное окно (читай - выделяется немалый общесистемный ресурс). Таким образом в ущерб объему занимаемых ресурсов там упрощается диспетчеризация асинхронных сокетных событий, хотя можно было бы обойтись всего одним окном и беготней по списку Connections[].