програмирование покера
 

При принятии решения игроком (увеличении ставки,скинуть,чек) он нажимает на соответствующую кнопку в приложении as3, слушатель события передает информацию на сервер php и сохраняет данные в таблицу MySQL. Как сделать так чтобы он отправлял события другим игрокам ? нашел что можно использовать сокеты, но не представляю как это выглядит(новичок), если кто подскажет буду рад.

Тут уж, как говорится, гугл в помощь. Такую большую тему в двух словах не объяснишь.

Гугл-гуглом, но что гуглить...

На текущий момент мне кажется самым простым решением FlashSocket(клиент) +Node.js(сокет-сервер)+MongoDB(простая и быстрая бд для высоконагруженных приложений). На этой связке даже новичок сможет сделать что-то работающее.

ЗЫ. Про php+MySQL в данном случае забыть (разве что на php написать админку к приложению, php с MongoDB работает нормально).

Если пользователей планируется в количестве пары тысяч, то это всё спокойно потянет прямая связка пых+мускуль.
интересно знать что конкретно вас неустраивает в такой связке и сервере на пыхе?
какой планируется сервер под Монгу? Почему именно она?

Вроде как уже тыщу раз обсуждалось? :)
Сокет-сервера на пыхе писать бессмысленно.
Сокет-сервер надо писать на технологии, которая для этого предназначена.
Или возникает сомнение в необходимости сокет-сервера для покера?

В остальном - все очень просто. Сейчас делаю игровой проект на сокет-сервере и Node.js - реально кульная вещь. Не люблю Javascript, но тут он на месте (хотя, Node.as была бы, конечно, на порядок круче). А когда начинаешь собирать сервер на js, который работает с JSON, то естественным становится и выбор в качестве бд MongoDB, Redis, еще там кое-что есть в семействе noSQL. Мне понравилась MongoDB.

Вопрос про сервер не совсем понял. От приложения зависит. MongoDB шардится естественным образом по мре необходимости. Node.js по мнению разработчиков держит 3-5к пользователей на один процессор сервера. Впрочем, не думаю, что автору требуется такая мощность, так что MongoDB прекрасно уживется на том же сервере, где запущен сокет-сервер.

Вот с прекрасно уживается возникают проблемы, ибо монга настроек памяти не имеет, отжирает весь объем и освобождает лишнее по запросу.
при этом живет более-менее быстро пока данные гарантированно умещаются в память. своп или лог делают её по быстродействию ниже мускуля. при том на наших тестах это было 2 порядка.
а по поводу именно сокет-сервера - совсем не обязательно, хотя, конечно, удобнее)))

Чем он так крут? Можно пример?
Посмотрел сайт, документацию. Особо крутого ничего не вижу
Разве что для не знающих английского проще в освоении. А так, обычный сервер, ничем не лучше других аналогов.

Ну так, в чем проблема? :)

Альтернатива сокет-серверу - лонг-полл. Не будете же долбить в сервер раз в секунду. С использованием лонг-полла с пхп - 3-5 метров памяти на каждого пользователя онлайн. Я, кстати, собирал. Работает удобно и устойчиво, но память... Тоже вилы.


А. Порог вхождения
Сокет-сервер на c++,c#,java новичок собрать не сможет в принципе.
Сокет-сервер на node.js новичок соберет.

В. Скорость разработки
Внесение изменений в код сервера происходит быстрее и проще.

Добавлено через 1 минуту
Занятно.

Добавлено через 5 минут
Все правильно. Она в определенном смысле работает по принципу кей-вэлью хранилищ.
Ксати, я знаю проекты, которые переводились и переводятся сейчас с MySQL на MongoDB, и мне не известны случаи обратного перевода.

Хотя, для какой-нибудь фермы я бы MongoDB брать не стал и более того, собрал бы сервер на старом добром php/MySQL.

еще есть такая штука как XMPP

Ок. Можете приводить пример статистики - на 1 млн записей монга делала сложную выборку около 20 секунд. мускуль справлялся за 1с и 0.4с на повторную выборку. Дальше монгу не поддерживали.
Есть надежда что недавняя последняя версия будет быстрее, ибо сама идея и способы работы с данными в монге мне нравяцца, но пока - увы.

Кстати, я как раз не агитирую за монгу, как могло показаться. :)

Топик стартер хочет создать супер-пупер игру, не представляя себе, как это вообще делается. Т.е., подозреваю, ему все равно, куда идти и что изучать. Я просто предложил вариант с достаточно низким порогом вхождения.

Возможно не в тему, но Node.as кто нибудь пробовал? Если он действительно полный аналог node.js то это реально круто, но так как это штука мало известная, скорее всего там дофига багов и неудобств. Но на досуге надо будет поковырять.

Сокет серверы какие то, для таких вещей как по мне - медиа сервер типа вовзы - есть адекватное решение. Сокет серверы это для игровых автоматов хороши, например.

Что бы штука стала известная и малоглючная ее надо использовать и всячески продвигать.

Интересный вывод )

Можно и на вовзе.
А функционал на java.
Топик-стартер будет полгода мучиться, пока все это запустит, напишет, соберет, отладит...
А на связке FlashSocket-Node.js он запустит простенький серверок за две недели-месяц. Если руки не совсем кривые.

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

Redis – это не совсем БД в том понимании. Или ты не сравнивал mongo vs redis, а просто константировал что тебе понравилось?
А ещё монга это NoSQL. Соответственно, здесь нету плюшек SQL, типа DISTINCT :)
Надо понимать, что где использовать. Schemaless DB хороши для тех мест, где эта самая схема мешает. Она удобна для быстрого прототипирования – нет заморочек с конструкциями таблиц / миграциями при MDD (Model Driven Development) и прочем. Создатели всегда говорили, что монга промежуточное звено, которое стоит до серьезных SQL - баз.
А есть для чего ещё уместны сокет-серверы?

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

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

Да. Не сравнивал.


Я за свою жизнь видел неподъемную кучу баз данных (застал еще ADABAS, не путать с адидасом :), и прочие дореляционные СУБД ). Могу сказать точно, для простых приложений документо-ориентированная база данных - это просто песня. У меня сейчас три коллекции с JSON-объектами (BSON, естественно, но не суть), которые описывают весь основной функционал. В реляционной СУБД у меня уже было бы минимум пятнадцать таблиц и я бы уже во всю джойнил их направо и налево.

Можно немного оффтопа про производительность? количество выборок-вставок, объемы данных и т.д. насколько хорошо держит нагрузку и на каких серверах.
Есть просто мысль попробовать монгу не для статы, а как основную базу, но после предыдущего опыта как-то не хочется снова делать лишнюю работу.

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

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

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

Ок, а для сложных тогда что?

Ну возьми не дистинкт, а джоины. Я про другое.
Ну, я бы не рисковал. В монгу можно записать неправильно, и это порой очень беда. Но вообще, если работаешь на чем-то вроде RoR, т.е. в работе используется ORM (я про MDD, когда работаешь с моделями, а не с какими-то-там-таблицами), то можешь попробовать. В случае чего, полностью переехать на другую СУБД будет делом пары часов.

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

Вот очень простой пример с профилем пользователя в какой-нубудь ферме или ходилке-бродилке:

В реляционной БД тут две очевидные таблицы (есть, конечно, вариант с сериализацией содержимого itemsInBag и записью в текстовое поле, но в большинстве случаев это именно две таблицы). Допустим, по итогам действия перса ему начислилось 30xp и израсходовались 3 айтема из первого слота. Что мы имеем в реляционной БД? Два апдейта, причем, в определенных условиях еще и объединенных транзакцией. А в документарной БД - одна атомарная операция с документом, причем, его не надо таскать из базы целиком, а достаточно просто указать, какие части документа и как изменить. Т.е., даже на таком банальном примере видно, что количество обращений к БД, как минимум, разное. А если профиль собран, скажем, не из двух, а из пяти таблиц? Например, у пользователя еще есть подарки, производства, скиллы, ученики-последователи, привилегии и пр.?

Совершенно очевидно, что если проектировать документарную БД по правилам реляционной (1 таблица = 1 коллекция), то это будет алес капут и эффективно работать не сможет. Поэтому для документарных баз, например, принципиален сознательный отказ от 100%-ой нормализации (что, конечно, плохо ложится в голову после работы с реляционными БД). Есть еще некоторое количество отличий, все описано в той книге, которую я выше указал.

Сорри за оффтоп. :)

Согласен. Я что-то с головой ушел в веб и подзабыл, что речь может идти и про игрули )

Многопоточные Медиа серверы .
Нет нет, я ни в коем случае не говорю, что сокеты это плохо, или с ними нельзя жить. Можно и в пеинте монализу рисовать, это понятно. Но как то сложилось так, что для серьезных проектов - выбирают серьезные технологии аля JAVA и т.п. - уж для сервера точно. имхо

А они по нуль-пространственному телепатическому коридору работают..
Ага.

Вот тут у меня просто случился когнитивный диссонанс..

Может я сейчас открою вселенскую тайну, но у меня есть собственный сервер на Java, который работает через сокеты :D И до этого сколько раз сталкивался, большинство работало через сокеты. И Wowza, да да WOVZA - это тоже сокет сервер, написанный на джаве :D

Ну сокет это как бы разъём. То есть IP адрес и порт. Дырка через которую два процесса могшут взаимодействовать. Вовза на некоем уровне является сокет-сервером, но для работы с ней используются транспортные протоколы более высокого уровня. То есть не уверен что она отзовётся если ты минуя эти протоколы начнёшь ей шпулять пакеты

Куда она денется. Естественно она не ответит ничем разумным, если данные не будут соответствовать ее протоколу, но пакеты она будет принимать в любом случае.
К слову, транспортные протоколы - это одно, а сокет - это другое. Они друг друга не заменяют, а дополняют. В моем сокет сервере в качестве транспортного протокола используется google protobuf, но сервер построен на сокетах.

Как я люблю, когда ты начинаешь рубить правду матку )
Если бы ты сдавал экзамен, то:
Минус полбалла. Сокет – это поток, который можно цеплять хоть через файл.
Верно. Обычный I/OStream.
Полное непонимание что такое транспортный протокол. Минус два балла.
Если тебе интересно, можешь почитать про OSI. А транспортный протокол в стеке лежит там, где ты программируя о нём и не подозреваешь.
И вновь минус. Как ты будешь отсылать пакеты? Почтой России? Тебе нужно завернуть свои данные в пакет в TCP (про UPD вообще умолчу), который нужно завернуть в пакет IP и только потом отправить. Но благодаря высокоуровневым языкам тебе и об этом знать не нужно.

Приходите на пересдачу.

Немного непонятно: какой критерий "серьезности" проекта? DAU в 100 000 -серьезно, или ещё нет?
а покер серьезно?
а если игра развлекательная? это серьезный проект или как?
почему-то всегда казалось что в деле выбора сервера основную роль должна играть целесообразность, а не "серьезность"

Если говорить про игровые проекты, то как мне кажется сейчас - нет.

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

ЗЫ. Я этот подход не слишком одобряю, но это объективные реалии. Сейчас большинство игр честно запускается с открытым бетатестированием. У разработчиков нет ни времени, ни желания для полноценного тестирования собственными силами.

Собственными силами обычно делается альфа тестирование. А бета тестирование как раз и предполагает привлечение добровольцев из числа обычных пользователей

Хорошо, перефразирую.

Большинство игр выпускается в бета-тестирование вообще без предварительного тестирования как такового. Если еще точнее - функционал условно тестируется программерами в момент разработки/сборки/подключения и еще в момент ввода контента и настройки баланса контент-менеджерами/геймдизами.

Впрочем, это мое мнение и отстаивать его во что бы то ни стало смысла не вижу.

Т.е. никто не рассчитывает на вариант "выстрелит"? ибо если такое случится на сервере "как получилось", можно умучиться "расширять горизонты"

Чего там "умучиваться"? Месяц нанятого программиста - 2000$. Еще один сервер в стойке - 1000$. Вывод?