Как разделить логин и игровую логику при написании серверов?

Я создаю игровой сервер, похожий на покер, я собирался обрабатывать все логины и игровую логику на одном сервере, но из моих исследований в Интернете я узнал, что это не масштабируется, и было бы целесообразно разделить работа в логин и игровые серверы. Но что я не получаю, так это после того, как я обработал аутентификацию на сервере входа в систему и заставил клиента установить новое соединение с игровым сервером, как бы я узнал, какой клиент какой? Разве мне не придется повторно входить в систему и, таким образом, победить цель наличия сервера для входа? Есть ли способ передать соединение между процессами и машинами, о которых я не знаю? Извините, мои небольшие знания о сети.

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

1. Когда пользователь успешно проходит аутентификацию на сервере входа, ему отправляется адрес игрового сервера и токен входа, как указано выше. Однако этот токен состоит из 2 частей: время на сервере входа в систему и хеш этого числа плюс их имя пользователя, их IP-адрес, IP-адрес или идентификатор игрового сервера и секретный ключ, который известен только вам.
2. Клиент пытается войти на предоставленный игровой сервер, отправив этот токен. Сервер формирует тот же хэш, что и раньше, основываясь на информации в токене входа в систему, а также на своем IP-адресе / идентификаторе и секретном ключе. Если этот хэш совпадает с хэшем в токене, вы знаете, что игрок аутентифицирован должным образом. Затем проверьте, не слишком ли старая дата (например, более 1 минуты).

Это работает, потому что:

• Его нельзя скопировать и использовать повторно, так как дата истекает.
• Он не может быть создан без нового логина, не зная секретного ключа.
• Он не может быть легко перехвачен кем-то другим (например, с помощью анализатора пакетов) и использован, потому что для его создания используется исходный IP-адрес.
• Его нельзя использовать для другой учетной записи, поскольку имя пользователя является частью хэша.
• Его нельзя использовать для одновременного входа в систему на разных игровых серверах, поскольку ID / IP-адрес сервера является частью хэша.

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

Как и в случае любого хэширования, ориентированного на безопасность, используйте лучшую хеш-функцию, которую вы можете получить - в данный момент людям, похоже, нравятся bcrypt, PBKDF2 и scrypt, - и убедитесь, что ваш секретный ключ очень длинный, чтобы сделать перебор практически бесполезным.

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

2. Loginserver выбирает игровой сервер. Отправьте токен, имя пользователя и все другие соответствующие данные о пользователе с сервера входа на выбранный сервер.

3. Отправьте токен и имя хоста игрового сервера клиенту. Затем отключите его от логина-сервера.

4. Затем клиент подключается к игровому серверу со своим именем пользователя и токеном.

5. Когда токен от клиента совпадает с токеном, только что сообщенным сервером входа в систему, вы принимаете его.

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