Разработка «Масштабируемого многопоточного сервера с сокетами» в .Net - PullRequest
2 голосов
/ 11 января 2011

Мы находимся в начале разработки масштабируемого многопоточного сервера Socket Push в .Net, который первоначально будет обрабатывать 10 000 клиентов на узел. Поскольку разработка этого может быть очень сложной, мне действительно помогло бы, если бы вы все эксперты могли предоставить какие-либо рекомендации, ресурсы, лучшие практики и т. Д.

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

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

[Для вашей информации мы планируем использовать .Net 4.0 для этого сервера]

Я читал много информации об Async Socket и его Связанной с пиннингом проблеме . Эта проблема все еще существует в .Net 4.0?

Спасибо заранее ...

Ответы [ 3 ]

5 голосов
/ 11 января 2011

10k одновременных подключений с использованием .Net на разумном оборудовании не должно быть такой большой проблемой, но, как всегда, это будет зависеть от того, что вы на самом деле делаете на своем сервере, и от того, насколько изолированы каждое соединение друг от друга. В конце концов, говорить «обрабатывать 10 тыс. Клиентов на узел» довольно бессмысленно, если вы не определяете требования к оборудованию для каждого узла, объем данных, которые будут поступать в каждое соединение и выходить из него, а также объем ЦП для каждого соединения. нужно сделать свою работу. Я говорю об этих смутных, волнующих вопросы о масштабируемости здесь: http://www.serverframework.com/asynchronousevents/2010/12/one-million-tcp-connections.html

Однако:

Сначала вы должны взглянуть на API асинхронных сокетов и в значительной степени игнорировать проблему многопоточности. Асинхронные сокеты .Net позаботятся о потоке для вас и будут использовать порты завершения ввода / вывода (очень масштабируемый объект ядра) для управления вашими потоками.

Кроме того, имейте в виду, что если вы используете асинхронные отправки, то их завершение может занять много времени, если сработает управление потоком TCP, см. здесь .

и ...

Во-вторых, вы должны проверить свою масштабируемость со дня 0 и продолжать тестировать ее на протяжении всего процесса разработки - я пишу о причинах здесь: http://www.serverframework.com/asynchronousevents/2010/10/how-to-support-10000-or-more-concurrent-tcp-connections---part-2---perf-tests-from-day-0.html

0 голосов
/ 11 января 2011

Поскольку масштабируемость является одним из ваших главных приоритетов, и я также собираюсь предположить стабильность, я обнаружил, что Erlang хорошо подходит. Он отказоустойчив и отлично масштабируется. Если у вас есть время для изучения различных вариантов, я бы посоветовал хотя бы изучить это.

0 голосов
/ 11 января 2011

Некоторые люди могут сказать, что «масштабируемые» и «многопоточные» взаимно противоречивы. Вам нужно изучить пространство дизайна , прежде чем принять такие решения. Если вам нужна масштабируемость, может быть возможно использовать только один поток, но это зависит от того, что вы обслуживаете.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...