Выбор серверного языка. - Страница 2

nns2009 · 26.04.2010, 16:46

Как раз по моему ASP.NET бесплатная вещь: скачал Visual Web Developer Express Edition и создавай сайты с помощью ASP.NET сколько угодно. А хостинг для ASP.NET стоит не намного дороже, а вот для Java хостинга вовсе нет.
Что касается PHP - серьёзный вариант, но опять же вопрос: могу ли я запрограммировать взаимодействие пользователей не через записывание и считывание данных из базы данных, а через оперативную память.
И вопрос по быстродействию: что быстрее и во сколько раз.

Bgg · 26.04.2010, 16:52

Цитата:

Сообщение от nns2009

а вот для Java хостинга вовсе нет.

Есть - brim.ru, GAE

mikhailk · 26.04.2010, 17:01

Цитата:

Сообщение от nns2009

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

Memcahe

Единственно, игр "вообще" не существует.
Взаимодействие пользователей на уровне онлайнового шутера в духе CS на PHP еще вроде никому реализовать не удалось. Взаимодействие на уровне "заглянул в огород соседу, пока его нет, и напакостил там как-нибудь" - можно и на PHP.

Aloran · 26.04.2010, 17:48

Юзай java. Особенно просто и быстро писать сервак на Apache Mina. Но я лично смотрю в сторону Erlang, пусть и для понимания сложен, но думаю он того стоит.

nns2009 · 26.04.2010, 19:32

А на Java можно ли создавать шутеры и тому подобные игры? И как это всё происходит: запускается приложение, которое ловит подключение пользователей, разбивает их по сокетам и 40 раз в секунду обновляет состояние игры в зависимости от нажатий пользователей: так, или как-то по-другому? Возможно ли встраивание кода Java в HTML код страницы, как в PHP и ASP.NET?
А клиентские приложения на Java, которые требуют дополнительной установки, они только для браузера или для компьютера с мобильным телефоном тоже?

Котяра · 27.04.2010, 10:16

Цитата:

Сообщение от nns2009

разбивает их по сокетам и 40 раз в секунду обновляет состояние игры в зависимости от нажатий пользователей: так, или как-то по-другому?

Вы путаете с вариантом ответ/запрос по http.
При использовании сокетов предпочтительнее другая архитектура, хотя многие, даже используя сокеты - шлют пинги, по-привычке, либо потому, что не знают другого способа.
Здесь больше подходит абстракция с событиями и MVC.
Т.е. клиенты послают сообщение о наступлении некоего события(нажатия, либо уже вычисленного на клиенте действия), в момент когда оно наступило ( тафтология, но зато понятнее).
Сервер отсылает свои события заинтересованным клиентам.
Представьте клиенты как некие вьюшки, а сервер как контроллер и модель (база данных).
Подпиской/отпиской событий и рассылкой занимается контроллер сервера. он-же при изменении данных отсылает события об изменении модели, либо напрямую вызывает команды в клиентах (через командные сообщения)

Это моё личное предпочтение архитектуры, можно сделать свыше 9000 других архитектур, например используя дуальную систему RemoteObject ( опять-же это ответ/запрос, но без пинга, а в нужный момент)

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

Crenth · 27.04.2010, 11:03

дельты состояний хороший если вероятность потери пакетов в канале клиент-сервер равна нулю

Котяра, а поделитесь теорией модели "без пингов". В двух словах.
Я так понимаю, что есть 2 способа узнать, жив ли клиент:
а) слать ему пинги и ждать АСК-и (нет АСК-а - клиент умер)
б) следить за состоянием сокета (сокет умер - клиент умер)

или тут речь о беспинговой технике в другом контексте ?

Котяра · 27.04.2010, 16:26

Скорее б) + некий таймер откликов (сокет не всегда отваливается явно - бывают странные глюки сервер<-> браузер <-> флэшплеер)
Про потери пакетов - считаем что на сокете == 0.
Я, по крайней мере, не встречал проблем, ни на сиплюсных, ни на явовских серверах с этим.
На tcp уровне и так существует своя система пингов и проверок, которая ДОЛЖНА вызывать ошибки подключения/отправки, а вот если спускаемся ниже, до UDP (который вроде будет когда-то работать в p2p flash) - там такой гарантии нет.

Для примера, поищите каким образом происходит общение во "взрослых" MMO играх - там тоже всё на сообщениях и чанках.
UPD - для чайников
расширенно ( рекомендую Q8)

Crenth · 27.04.2010, 19:07

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

я немного в теме сокетов. и тоже сталкивался со странными отваливаниями. но как ни странно, что странно

, в таких случаях у меня на ФП смерть сокета сразу выявляется, а не сервере - не всегда.

поэтому я все же юзаю связку пинг+АСК. если АСК не пришел в ожидаемом интервале, я тупо закрываю сокет.

Котяра · 27.04.2010, 21:42

Пинг для проверки коннекта - это одно, а протокол, вернее архитектура общения клиент-сервер,это немножко другое.
Давайте определимся с терминологией...
Я сам может и путаю(сь).
есть 2 типа общения:
1)запрос/ответ - клиент посылает запрос и получает на него ответ
2) сообщения. - и клиент и сервер могут отправить сообщение друг другу в любой момент времени.
1 - поддерживается и http и сокетом
2 - только при установленном полнодуплексном коннекте, т.е. либо сокет, либо http-CONNECT, либо http эмуляция через пинги.
2 - это громадное и основное преимущество сокетов, экономящее трафик, ресурсы и нервы.
пинги - это запрос-ответ с неким интервалом.

Теперь другой аспект: Каким образом может быть организована передача данных?
опять 2 варианта:
1) по состоянию (слепок мира)
2) по событиям ( дельта элементарных состояний, или, можно сказать - изменение данных Модели)

2 вариант - опять же предпочтительнее, и легче всего его реализовать с помощью сокетов, хотя можно и по http c эмуляцией постоянного коннекта через пинги: "есть чо?".

2Crenth
Твой (если позволите

) вопрос состоит скорее - как отловить обрыв сокета и проследить передачу ВСЕХ данных?
Это - другая задача, которая имеет больше решений чем одно (пингами)
С ходу - вариант (нечто подобное использовалось в реале):

1- при отсылке/приёмке запоминаем таймстамп на клиенте и сервере (полезно также для синхронизации по-времени)
2- можно вести счетчик сообщений (отдельно для сервака, отдельно для клиента) для проверки "доходимости" пакетов, хотя это лишнее, сокет либо рвётся - либо нет.
3- отслеживаем обрыв сокета на клиенте и сервере.
4- при обрыве на клиенте пробуем приконнектится по-новой.
5- при превышении лимита таймаута на сервере (определяется по логике игры) сервер посылает пинг :"ау- ты живой" - при отрицательном ответе оканчивает сессию клиента.

Всё это кажется на первый взгляд громоздким, но это десяток строчек кода максимум

Добавлено через 37 часов 35 минут

Цитата:

Сообщение от Crenth

я немного в теме сокетов. и тоже сталкивался со странными отваливаниями. но как ни странно, что странно

, в таких случаях у меня на ФП смерть сокета сразу выявляется, а не сервере - не всегда.

Я поэтому и говорил о сервер<-> браузер <-> флэшплеер, а не сервер<->флэшплеер.
Существует мнение (не моё), что некий остаточный коннект остаётся между сервером и компом.
Кто его держит не понятно, то-ли ось, то-ли браузер, а может и вообще какой маршрутизатор или фаервол.