Пытаюсь написать клиент-сервер.

[Travolta]

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

1. будет поддерживать арены по 2 игрока, т.е., они между собой там разбираются. И таких арен онлайн около 200-500.
Я не могу точно себе представить архитектуру сервера.
Изначально я предполагал сервлеты.
Затем добрые люди на других форумах сказали, что можно обойтись без них.
Но нужно создавать некий цикл, в котором обрабатывать всех этих клиентов.
Как это вообще делается?

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

То есть, пока эти два ключевых вопроса меня сильно беспокоят и нюансы, с ними связанные.
В теме сокетов и сетевых решений у меня большие пробелы, поэтому если у вас есть ссылки на полезную литературу или примеры....

Благодарю за внимание.

[Finch]

Travolta, В клиент-серверных приложениях, сервер как правило сам ничего не посылает. Он только отвечает на запросы клиентов. Если ты будеш сам писать серверную часть, то без сокетов в том или ином виде тебе никак не обойтись. Такова специфика программирования сетевых приложений. Если все таки переложиш в серверной части функции управления сервера на Apache, и оставиш только функции управления логикой на серверной части. То задача у тебя как минимум на половину будет легче.
100 мс не маловат будет квант времени? Есть такая замечательная программа ping. Ради любопытсва попингуй удаленные сервера. Удивишся, что ответ приход иногда с намного большим интервалом. Кстати в Windows минимальный квант времени, с которым можно играться в юзер режиме 18 мс.

[Travolta]

Я проводил тесты для конкретных серверов, выяснял этот вопрос. Сигнал приходит с задержкой от 70мс до 200мс.
Планирую приход сигнала с опозданием, то есть, в нём должна быть дополнительная информация для клиента о том, как экстраполировать данные.
Переложил часть функционала на PHP. Меня интересуют именно моменты, связанные с быстродействием и возможностями кода, поэтому их я вынужден реализовать на яве.

[Sla]

Ты подразумеваешь что сервер сам должен опрашивать клиентов?

На мой взгляд это не совсем правильно.

Клиент отсылает запрос серверу о готовности и ждет ответа.
После прихода ответа - он его обрабатывает, и после обработки посылает след запрос (например, каждые полсекунды пинает сервер)

На сервер можно переложить вычислительную нагрузку. Сервер отдает только вычисленные координаты.
Клиентская сторона принимает координаты и перемещает объект(объекты)

Такая схема позволит отладить или записать ход игры, вплоть до восстановления состояния.


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

[Travolta]

Нет, не опрашивать. Схему работы клиента и сервера я вижу такой.
1. Клиент рассчитывает свои координаты сам, то есть, своего ключевого персонажа или кто он там. Потому что, если он будет ждать ответа от сервера, пройдёт 150мс и возникнут явные "тормоза",  и никакая интерполяция не спасёт от ощущения, что клавиша нажата, а реакция - с задержкой. Поэтому расчёт себя клиент делает сам.
Но  передаёт схему нажатых клавиш на сервер, чтобы тот смог восстановить картину клиента у себя. Это защита от взлома клиента. На клиенте висит сокет со слушателем или с таймером, думаю, неважно.

2.В свою очередь, сервер принимает сигналы от  клиента, восстанавливает картину мира, раздаёт их другому клиенту.
Этот процесс не должен быть спонтанным, он должен быть цикличным.
То есть, раздача картины мира каждому клиенту идёт постоянно, просто клиенты вносят каждый свои коррективы.
Поэтому я вижу тут некий таймер раздач на сервере.
И не знаю, как его реализовать корректно.

И зачем тогда нужны сервлеты, если можно обойтись без них? это немного вопрос скорее не по теме.

[Serg79]

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

Переношу в "Общий" раздел.

[Travolta]

"логика работы обслуживания сервера" скажите своими словами о чём вы? я не совсем понимаю.

[Finch]

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

[Travolta]

можно переложить вычисления на клиенты, но когда их поломают, то весь код будет на руках.это flash и как бы я не обфусцировал - вопрос времени. а показывать весь код мне как-то стрёмно. это мне видиться потенциально "плохо".
поэтому мысль моя всё же сводится к неким хотя бы основным расчётам на сервере.
просто я не знаю какая ещё тут нужна логика. мне скорее неясно как технически реализовать процесс на сервере.
если вы говорите что сервер не должен принудительно отправлять данные через интервал времени клиентам, то можно с клиента отправлять запросы через интервал времени и сервер будет на них отвечать.

[Sel]

Слушай, Travolta, ты клавиатуру почини, чтоб большие буквы и запятые печатала. Я больше твои посты править не буду. Если тебя не поймут с акой писаниой - твои проблемы. Достал.

[Sel]

Offtopic:

Тем, кто читал тему про "Как мы говорим".
Вот еще готовый перл:

Поставлю в угол.

это мне видиться потенциально "плохо".

[Finch]

Travolta, Есть такой фильм, называется "Сержант Билко" В фильме есть момент, организовывается боксерский турнир. Билко подкупает одного из боксеров, чтоб он лёг. Его помошник отдает деньги другому боксеру перед самым боем. Ну ты примерно можеш представить как проходил бой. А теперь вернемся к твоим птичкам. Если будут взломаны сразу два клиента на двух разных компах. То их игра будет напоминать примерно тоже самое, что происходило на этом турнире. Поэтому я и сказал, что сервер выступает как орбитр. Если два разных клиента посылают разные данные обсчета. То и блокировать (банить) от дальнейшей игры читеров.

[Travolta]

читеры меня смущают меньше, чем плагиат кода.

[Serg79]

читеры меня смущают меньше, чем плагиат кода.

Travolta, у тебя еще и рабочего прототипа то нет, а ты уже о плагиате кода думаешь.

[Travolta]

С чего вы взяли что его нет?
Я в общем-то как бы сутки задаю 2 вопроса в разных формах, которые уже свелись к одному:
как корректнее реализовать сокеты на сервере ?
можно их сделать на сервлетах? оптимально ли это?

[Serg79]

C чего вы взяли,  что его нет?

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

А у тебя Travolta в первом посте что? Сплошные: Я не могу точно себе представить архитектуру сервера, Затем добрые люди на других форумах сказали, Но нужно создавать некий цикл и т.д. и т.п. Одним словом каша в голове. О каком прототипе в этом случае может идти речь...

Travolta, ты лучше попытайся с начало объяснить на пальцах, без таких подробностей как микросекунды и т.п., как ты хочешь что бы два клиента общались между собой, как ты хочешь что бы устанавливалась связь между клиентами ну и все в этом роде. Тогда будет понятно что должен будет делать сервер в этой цепочке. Да и обговаривая весь этот верхнеуровневый дизайн, намного быстрее находятся ошибки и не точности в проектировании, что в свою очередь приводит к более быстрому движению к намеченной цели.

[Travolta]

Согласен, попробую описать.
Клиент 1й соединяется с сервером, и постоянно отсылает информацию о своих действиях.(то есть о том какие кнопки нажаты).
Клиент 2й  делает то же самое.
Сервер принимает сигналы, по ним восстанавливает положение игрока каждого клиента в указанный момент времени, рассылает положение 1го игрока 2му и наоборот.
Каждый клиент предсказывает действия своего и другого игрока на определённый интервал времени вперёд, рассчитывает возможность общего взаимодействия (в частности столкновения). Если взаимодействие возможно, отправляет сигнал на сервер. Сервер взаимодействие проверяет, рассчитывает и передаёт его результаты клиентам. Сервер так же передаёт результат взамимодействия на определённое время вперёд. На клиентах всё это разворачивается.

Это можно считать взаимодействием между клиентами?

[Finch]

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

[Travolta]

Чем плохо что их много? Общение напрямую, где реализованы такие подходы?
Давайте представим, что алгоритм общения клиент-сервер, который описан мною выше пока что единственный подходящий в моём случае и перейдём к более , так сказать, существенным вопросам - как его реализовать, например на сокетах?

[Serg79]

Travolta, тебе что в сокетах не понятно? Если тебя интересует API сокетов, то для этого существует соответствующая документация.

[Travolta]

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

[Finch]

Ну если Ява, то скорее всего уже все привязано к классам. Не нужно с голыми сокетами работать.

[Finch]

Хотя сервлеты могут обслуживать любые запросы, они обычно используются для расширения веб-серверов. Для таких приложений технология Java Servlet определяет HTTP-специфичные сервлет классы.

Т.е. нафига тебе заморачиваться на сокетах. На стороне сервера этим будет заниматься HTTP сервер. На стороне клиента, скорее всего в Ява есть класс, который работает с HTTP сервером.

[Travolta]

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

[Finch]

Travolta, HTTP версии 1.1 позволяет некоторое время держать соединение и делать несколько запросов.

[VY]

Я сомневаюсь, что стоит использовать протокол HTTP. Если вы планируете 100-байтные пакеты, то только за счет протокола они увеличатся примерно вдвое.  Плюс еще служебная информация TCP -- получите значительное увеличение объемов передаваемых данных без всякой пользы.

Теперь собственно о клиент-сервере. То, что вы пытаетесь реализовать, очень похоже на систему реального времени с непосредственным распространением информации. Сразу скажу, что есть технические пределы -- используя один серверный компьютер вы сможете "держать" около 200-300 клиентов, не более -- при очень хорошей сети.

Код, реализующий такую схему -- есть (под Windows), но очевидно требует адаптации для ваших целей. Если интересно - напишите на victory@iss.org.ua.