Игровой чат в mmorpg (реализация)

← →
Luarvic (2011-03-18 12:24) [0]

Вот поспорили с другом, как правильней реализовывать обмен текстовыми сообщениями в играх.
Мой вариант: сервер накапливает все строки чата, и отмечает у клиентов какие именно им нужно отправить, а когда клиент присылает запрос, то ему уже отправляются все отмеченные строки. Соответственно запрос присылается каждые 1-5с
Не мой вариант: на сервер приходит текстовое сообщение, сервер тут же отправляет его всем клиентам которым оно адресовано.

Вопрос: какой из двух выше вариантов более правильный (и почему?)
Заранее спасибо.

← →
OW © (2011-03-18 14:15) [1]

> на сервер приходит текстовое сообщение, сервер тут же отправляет
> его всем клиентам которым оно адресовано.

пришел - ушел.
Выстрелил и забыл, зачем копить что-то..

← →
asail © (2011-03-18 14:22) [2]

> OW © (18.03.11 14:15) [1]

А если клиент-адресат ушел в несознанку на 5 минут (потеря связи)?

← →
Luarvic (2011-03-18 14:24) [3]

Уточнение: используется протокол TCP

← →
Медвежонок Пятачок © (2011-03-18 15:11) [4]

православный сервер должен обслуживать запросы клиентов.

← →
Luarvic (2011-03-18 15:31) [5]

> православный сервер должен обслуживать запросы клиентов.

почему?

← →
OW © (2011-03-18 15:57) [6]

> А если клиент-адресат ушел в несознанку на 5 минут (потеря
> связи)?

он это может сделать и в момент рассылки

← →
Медвежонок Пятачок © (2011-03-18 16:04) [7]

почему?

Просто потому что он сервер. Обслуживатель.

А еще потому, что в обратном случае :
1. Ты рано или поздно запутаешься в протоколе обмена.
2. Все клиенты должны содержать в себе свои мини-сервера.

← →
KSergey © (2011-03-18 16:52) [8]

Не понятно зачем в первом варианте инициирование приема сообщений должен делать клиент.
Пришло на сервер сообщение - склал в очередь - отдельно разослал, что удалось; что не удалось - повторяем (при условии наличия клиентского коннекта).

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

← →
OW © (2011-03-18 17:00) [9]

только так, имхо
> Пришло на сервер сообщение -
>отослал, не удалось - повторяем

← →
Luarvic (2011-03-18 17:14) [10]

Итого 2 человека за второй вариант и 1 за первый... Чтоже выбрать всетаки?

> OW © (18.03.11 17:00) [9]

Не.
Удобнее, когда разбито на модули/потоки:
- прием сообщений от клиентов и складывание в очередь принятых
- перекладывание из очереди принятых в очередь для отправки, если надо нескольким - дублируем для каждого получателя экземпляр в этой очереди
- рассылаем сообщения клиентам из очереди отправки.

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

Основная задача здесь - сделать не слишком много потоков. Когда клиентов 5-10-30 - не страшно хоть на каждого потоков наплодить. Хоть по два. Когда 500-1000 - нехорошо.

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

А зачем "просыпаться" ? Асинхронная очередь не должна засыпать.

> Основная задача здесь - сделать не слишком много потоков.

CreateOnConnect - это такая юниксовая отсталость. Пулы потоков - нормальный шаблон, чем не нравится?

Игровой чат в mmorpg (реализация) Найти похожие ветки