Как работает асинхронный сервер сокетов?

Question

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

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

Мои вопросы:

Насколько мое понимание?

Требуется ли каждому клиентскому сокету свой собственный поток для прослушивания данных?

Как данные направляются в правильный клиентский сокет? Об этом позаботились кишки TCP / UDP / kernel?

В этой многопоточной среде какие данные обычно используются совместно и каковы причины спора?

Будем весьма благодарны за любые разъяснения и дополнительные пояснения.

EDIT:

Что касается вопроса о том, какими данными обычно обмениваются и где возникают споры, я понимаю, что это скорее деталь реализации, чем вопрос, касающийся общего процесса принятия соединений и отправки / получения данных. Я посмотрел на пару реализаций (SuperSocket и Kayak) и заметил некоторую синхронизацию для таких вещей, как кэш сеансов и пулы буферов многократного использования. Не стесняйтесь игнорировать этот вопрос. Я оценил все ваши отзывы.

Answer 1

Один поток на соединение - плохой дизайн (не масштабируемый, слишком сложный), но, к сожалению, слишком распространенный.

Сервер сокетов работает более или менее так:

• Прослушивающий сокет настроен на прием соединений и добавлен в сокет
• Набор сокетов проверяется на события
• Если прослушивающий сокет имеет ожидающие соединения, новые сокеты создаются путем принятия соединений, а затем добавляются в набор сокетов
• Если у подключенного сокета есть события, соответствующие функции ввода-вывода называются
• Набор сокетов снова проверяется на наличие событий

Это происходит в одном потоке, вы можете легко обрабатывать тысячи подключенных сокетов в одном потоке, и есть несколько веских причин для усложнения этого путем введения потоков.

while running
    select on socketset
    for each socket with events
        if socket is listener
            accept new connected socket
            add new socket to socketset
        else if socket is connection
            if event is readable
                read data
                process data
            else if event is writable
                write queued data
            else if event is closed connection
                remove socket from socketset
            end
        end
    done
done

Стек IP заботится обо всех деталях того, какие пакеты идут в какой «сокет» и в каком порядке. С точки зрения приложений, сокет представляет собой надежный упорядоченный поток байтов (TCP) или ненадежную неупорядоченную последовательность пакетов (UDP)

РЕДАКТИРОВАТЬ: В ответ на обновленный вопрос.

Я не знаю ни одну из упомянутых вами библиотек, но о концепциях, которые вы упоминаете:

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

Answer 2

Как моё понимание?

Довольно далеко.

Требуется ли каждому клиентскому сокету свой собственный поток для прослушивания данных?

Количество

Как данные направляются в правильный клиентский сокет? Об этом позаботились кишки TCP / UDP / kernel?

TCP / IP - это несколько уровней протокола. Там нет "ядра" к нему. Это кусочки, каждый с отдельным API для других кусочков.

IP-адрес обрабатывается на месте.

Порт # обрабатывается в другом месте.

IP-адреса сопоставляются с MAC-адресами для идентификации конкретного хоста. Порт # - это то, что связывает сокет TCP (или UDP) с определенной частью прикладного программного обеспечения.

В этой многопоточной среде какие данные обычно используются совместно и каковы причины спора?

Какая многопоточная среда?

Обмен данными? Что?

Соперничество? Физический канал является предметом спора номер один. (Например, Ethernet зависит от обнаружения коллизий.) После этого каждая часть компьютерной системы является дефицитным ресурсом, совместно используемым несколькими приложениями, и является предметом спора.