Неблокирующие сокеты против BeginXXX против SocketAsyncEventArgs - PullRequest
Новая
       28

Неблокирующие сокеты против BeginXXX против SocketAsyncEventArgs

8 голосов
/ 27 февраля 2012

Может ли кто-нибудь рассказать мне о современных технологиях сокетов .NET?

  1. Неблокирующие розетки

    Если я установлю Socket.Blocking = false и использую асинхронные операции - что произойдет?

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

  2. BeginXXX и SocketAsyncEventArgs

    Они работают над блокировкой сокетов под капотом и просто скрывают создание потока?

    Будет ли ручное создание потоков равным использованию методов BeginXXX?

    Есть ли другие плюсы в использовании SocketAsyncEventArgs, кроме тех, которые позволяют создавать пул сокетов и все, что с ними связано?

И последний вопрос: если приложение работает как некий сильно загруженный двоичный прокси-сервер с большей частью логики, выполняемой в одном потоке, - что обеспечивает лучшую масштабируемость: неблокирующий подход или асинхронные операции?

1 Ответ

2 голосов
/ 27 февраля 2012

1: Socket.Select следует сделать это, хотя я не склонен использовать этот подход лично;в частности, эти IList становятся раздражающими при больших объемах

2: нет, наоборот;операции блокировки по существу используют неблокирование в фоновом режиме, но с воротами.Нет, они не создают потоков под капотом - если только вы не посчитаете обратный вызов, когда что-то будет входящим.У меня есть пример, который обслуживает 12k соединений с использованием SocketAsyncEventArgs - количество потоков примерно равно 20. Среди намерений SocketAsyncEventArgs есть следующее:

  • гораздо проще эффективно объединять,не имея большого количества объектов, созданных / собранных для каждой операции
  • , вы можете очень эффективно обрабатывать сценарий «данные доступны сейчас» без необходимости обратного вызова вообще (если метод возвращает false, вы должны немедленно обработать данные- обратного вызова не будет)

Для масштабируемости: async

...