Привет.

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

Сервер - 4x3.80GhzXeonE5-1620, 65536MBRAMDDR3.

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

Итак вопросы.
1) Какие есть материалы в сети, о том как писать подобные сервера?
2) Кто может помочь с написанием высокостабильного сервера (есть готовый протокол) на любом адекватном языке (c#\qt c++) за деньги или советом.

Если чем-то поможет, могу показать код. Может потыкаете носом в проблемы.

Клиент написан, и меняться ради нашего сервера не будет (ну ведь понятно, что клиент не наш, а вот сервер хотим свой )) )
Поэтому такое требование.

Насчет двух серверов, я не знаю, но вроде до 6 серверов вполне можно. Требование взято с потолка.

кривокод, в зипке:

netivanJustOxlamon,

честно не смотрел весь код, но я так понимаю каждому соединению свой поток?


Т.е. при максимальной загрузке у вас будет 10 000 потоков? Я сомневаюсь, что такое будет работать...

Я тоже сомневаюсь что сработает, поэтому и спрашиваю тут.

Arm79,
Про SSL обсудили, это требование клиентской программы, на которую мы не влияем. Поэтому можно смириться.

Гут, со всем остальным согласен. Например, если бы вам дали такую задачу, сколько времени бы она заняла при бюджете в 90к рублей?

Пакеты такие говенные потому, что они все одинаковые. (хотя я бы сделал один базовый, и кучу от него наследовались, бы, ну и все такое по умному, но... )

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

В общем как я понял, сильно желательно переписать с использованием асинхронных сокетов.

Ладно, куда копать? Где есть живой пример SSL+ Async Socket?

Кто готов взяться за этот кусок, если хочется денег то 90к в принципе ждут.

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

Arm79Вот еще замечания:
1) У вас класс Пакет выполняет сразу несколько функций. И парсинг, и работу с потоком. Нужно разделить его на непосредственно класс Пакет (с бизнес-логикой при необходимости) и класс для работы с потоком.
2) При записи в поток зачем то работа на уровне байтов. Не надо совмещать парсинг и отправку данных, заранее подготовьте пакет и разом пишите его в поток.
3) Побайтное чтение из потока тоже не вдохновляет, в первую очередь своей скоростью. И я не уверен, что вы не напутали с кодировками. У вас и 28591, и utf-8, и неявно Unicode (при добавлении символа в StringBuilder)

(2 и 3 - сделали бы пользовательскую сериализацию своего объекта)

4) Нет очистки sslStream. TcpClient вы закрываете, а его поток - нет
5) Зачем лочить WriteLocker? У вас же один поток на одного клиента. ИМХО лишняя синхронизация

1, 2, 3) Тут весь код набросан по-быстрому, так сказать PoC. Поэтому довольно нелогичный. Пакет заменить на собственно пакет с данными и скажем что-то вроде ParserStream. Кодировка везде должна быть одна Latin-1. Остальное там эксперименты )

4) ну это все туда же )
5) из-за того что сервер из другого потока может что-то сообщать клиенту, например команду на выход присунуть или сообщение.

Arm79JustOxlamonКто готов взяться за этот кусок, если хочется денег то 90к в принципе ждут.
Arm79Но я человек занятой, и фрилансить могу не более 2-3 часов в день :-) Так что примерно месяц

Если устроят растянутые сроки, welcome

Ну или пишите сами, здесь подскажут, как правильно.

Буду думать, месяц действительно много, но сам я точно писать не буду. Так что буду искать. Ну и по-тихому писать основу для ТЗ.

netivanJustOxlamon,

выложите Тз своими словами, чтобы хотя бы понимать приблизительно. Может быть там дело на выходные, а может и месяца мало :).

Звучит примерно так:

Написать TCP - сервер (теперь уже точно на C#) со следующими характеристиками:
1) Поддержка SSL (ну надо, так надо... )
2) Наиболее производительный (в мечтах 10к на одном сервере, но любое адекватное число также устроит)
3) Клиенты должны быть изолированы по возможности друг от друга. Поясню, в итоге это будет сервер где хостится много игр с одним протоколом, каждую игру будут писать разные люди со своими тараканами, поэтому из-за ошибки у одного клиента и в одной игре сервер не должен умирать и не должен убивать других игроков. В потоковом варианте, это в принципе было по умолчанию и меня сильно устраивало такой халявой.
4) Ход работы примерно такой:



1. Запускаем сервер.
2. *Внутренний менеджер загружает игровые DLL инициализирует общие данные, коннектит к бд, подгружает оттуда что надо
3. Запускается tcp-сервер на определенном порту, начинается прием.
4. Коннектится клиент, создается с ним SSL - поток
5. Клиент шлет данные, мы его авторизуем через БД*
6. Клиент выбирает игру, играет, каждый ход фиксируется в БД*
7. Клиент закрывает игру, мы подчищаем за ним.

Программировать нужно ТОЛЬКО работу с сетью (т.е. все то что без * ). Т.е. примерно то что у меня в говнозипке сидит, только это и надо. Только грамотно и с учетом требований. Понятно, что есть много дополнительных хотелок. Но они обсуждаются, фиксируются в начале работы.

Arm79JustOxlamon,

Мало.

1) Как планируется обрабатывать ошибки с клиента? Может, неверный протокол. Нужно ли срубать или ожидать ввода правильных данных?
2) Как планируется защищаться от DDoS?
3) Как внутренний игровой менеджер взаимодействует с транспортным сервером? Если все в одном процессе, то надежность сервера в том числе зависит от этого менеджера. Упадет он - упадет все. Если это разные процессы, то как они будут взаимодействовать, и каков алгоритм действий при падении менеджера?
4) У вас база то выдержит обращения десятков тысяч клиентов (с учетом не одной игры)? Нет никакого кэша?

Любая ошибка клиента - отключение клиента. Клиент отлажен и априори безгрешен (я знаю-знаю, но такова политика)
От ддоса планируем лежать намертво. Это не проблема сервера.
Игровой манагер сейчас это список типов подобного толка: dictionary<string, type> при старте игры ищется игра, и создается, потом контроль передается ей, через интерфейс - OnPacket( Player pl, Paket pk, DataSource ds ); и все что внутри нее, работает как ударит моча в голову разработчика, на текущий момент при ексепшонах, падает коннект и клиент убивается - это правильно. так надо.
база держит гораздо больше, она там расшарена, кешируется, разделена по серверам и т.п. (ну хоть где-то грамотно)

netivanJustOxlamon,

теперь мне не очень понятен суть клиента и сервера. Сервер - это хрень, которая слушает TCP порты и отвечает на них в зависиомсти от клиента (видимо ответ берется из базы), или как? Один клиент - один порт, или один порт- Х клиентов (судя по примеру)... я бы вообще сделал через WCF это надо. Мне кажется в итоге и получится некий велосипед... А задача на самом деле очень интересная и как правильно заметил выше Арм, оч много можно всего накрутить. Вопрос именно в требовании.

Я бы тоже писал на WCF\tcp.net и был бы счастлив т.к. строгая типизация, норм трафик и ваще полная няшка. Но тут на клиент мы не влияем никак. Поэтому протокол уже есть и фиксирован.

Много клиентов, один сервер, слушает один порт.
Самих серверов может быть до 6 штук.

Действительно требуется только примерно вот это:





+/- детали НЕ усложняющие разработку. Которые будут оговорены ВНАЧАЛЕ во время написания совместного ТЗ, возможно по скайпцу. Остальное мы наговнокодим сами )