Что такое хороший шаблон для использования AsyncSockets в .net35 при инициализации нескольких клиентских подключений

Question

Я перестраиваю шлюз IM и надеюсь воспользоваться новыми функциями производительности в AsyncSockets для .net35.

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

В настоящее время я должен взаимодействовать с IasyncResult, и, как вы знаете, он не очень красив или масштабируем.

Моя путаница заключается в следующем:

1) при использовании новых Begin / End и SocketAsyncEventArgs в 3.5 нам все еще нужно создавать по одному SocketAsyncEventArgs на сокет?

2) получаем ли мы что-либо, предварительно инициализируя, скажем, 20000 клиентских подключений, поскольку мы знаем, что ожидаемое max_connections на сервер составляет 20000

3) нам все еще нужно использовать LOH (кучу больших объектов), выделенный байт [] для обработки полученных данных, как показано в примере SocketServers на MSDN, мы не собираем сервер, скажем, но все еще обрабатываем независимый прием для каждого подключенного сокета.

4) может быть, есть лучший образец для того, что я пытаюсь достичь?

Заранее спасибо.

Чарльз.

Answer 1

1) IAsyncResult / Begin / End - система, совершенно отличная от методов "xAsync", которые используют SocketAsyncEventArgs. Вам лучше использовать SocketAsyncEventArgs и полностью удалить Begin / End.

2) Не совсем. Инициализируйте меньшее число (50? 100?) И используйте промежуточный класс (т. Е. / "Пул ресурсов") для управления ими. Когда поступает больше запросов, увеличьте пул, например, еще на 50 или 100. Сложная задача заключается в эффективном «уменьшении» количества объединенных объектов при снижении требований к ресурсам. Большое количество сокетов / буферов / и т. Д. Будет занимать большой объем памяти, поэтому лучше выделять его только партиями, когда этого требует сервер.

3) Не нужно его использовать, но это все еще хорошая идея. Буфер по-прежнему будет «закреплен» во время каждого вызова.