иметься несколько клиентов, передающие через сокет данные серверу в "реальном " времени, необходимо собирать все эти данные в одну какую-то структуру и изменять её при необходимости. база данных сразу отметается, по причине низкой скорости, файлы соответственно тоже. Можно ли как-нибудь организовать работу с памятью сервера?? интуитивно понимаю что можно, но вот как это практически сделать не знаю У кого есть какие соображения по этому поводу??
фигасе. это ж по какому каналу/интерфейсу клиенты общаются с сервером, что скорости работы базы данных и файлов не хватает?
скорости работы хватает, но перед работой нужно совершить подключение, что не простительно долго а с файлами ещё и проблема одновременного доступа появляется мне нужно принимать от каждого клиента трёхмерные координаты игрока, а передавать подобные координаты но для всех игроков, предварительно их обработать с учётом принятых, и всё это нужно делать как минимум 30 раз в секунду
persistent connect поможет Берите за основу phpDaemon фреймворк и обслуживайте всех клиетов в одном процессе. Если нужно сохранять данные переодически - можно агрегировать и плеваться в какой-нить другой демон, который будет в базу сбрасывать.
вообще можно разработчикам quake live написать, спросить - "чуваки, вы где данные храните, а то в базе и в файлах для меня долго".
это понятно, но к сожалению я с++ не знаю Уважаемый iliavlad, есть замечательная поговорка:"Если не чего сказать, помолчи, может за умного сойдёшь"
а я бы сказал, что это будет wsdl с кэшированием интерфейса. в одну сторону пакет с данными, назад пакет с ответом. должно очень быстро по идее работать
с пакетами всё понятно, но их нужно обрабатывать на сервере как то. представьте есть карта битвы по ней перемещаються игроки, чтобы отслеживать все перемещения нужно на сервере создать какуюто единую структуру, которая бы обрабатывала и хранила данные
wsdl - это очень грубо есть RPC, т.е. вызов удаленных процедур. если интерфейс закэширован клиентом, то он только отправляет пакет на сервере (для него это выглядит так, как если бы он вызывал метод класса), на стороне сервера всё выполняется (вычисляются координаты других участников или выборка из базы, я не знаю, что у вас там), сервер отправляет ответ, а у клиента он выглядит как будто метод вернул результат выполнения. никаких преобразований. всё придельно быстро
Если там действительно realtime, то XML будет слишком накладно. Исключительно свой бинарный протокол.
обработка к хранению в данном случае не имеет прямого отношения.... на счёт хранения, я бы сказал, что это будет key-value db. например, Redis
вот это уже ближе к тому что мне надо, а можно поподробнее, где про это почитать, как с ним работать и т.д. как же их (данные) можно обрабатывать, если они не где не храняться, они по любому где то должны быть, хоть в базе, хоть в памяти, но должны где-то находиться, в этом то и вопрос, где их лучше разместить
я тут и нахожусь неужеле вы родились с этими знаниями, навярняка где-то прочитали, помогите теперь другим научиться
Пофилосовствую. Помогать интересно людям, которые готовы воспринимать информацию, использовать ее как отправную точку и идти дальше. Т.е. показать дверь... а входить уже человек сам должен. Если же у вас вызывает затруденение по названию redis найти по нему документацию... Нет, ну есть волонтеры, которые кормят инвалидов с ложечки... ну вы же не инвалид?! Вы собираетесь взяться за сложнейшую задачу, высший пилотаж веб-программирования - realtime игру с огромным объемом информации, математикой, кучей подводных камней в производительности. Как вы будете это все решать? Создавать вопросы на форуме? А как вы думаете, те, кто по вашему мнению должен вас учить - они тоже учились раньше выключив гугл и задавая все вопросы на форумах?
А вы думаете в гугле кроме рекламы и форумов можно что то найти??? И потом я не просил меня учить, документация это конечно хорошо, но есть такая вещь как практическое применение, может быть книжку какую нибудь посоветовали бы путную или ещё что-нибудь
kelod, в отношении Redis я бы посоветовал читать именно официальную документацию. если хочется чего-то менее строгого и приближенного к практике - смотрите хабру. там были хорошие статьи по Redis
А самое главное, что нельзя ему редис в главном процессе. Ему вообще ничего нельзя кроме плевания данных в сокет или иных асинхронных операций. Любой лок, который произошел в синхронной библиотеке, будь то мускуль или редис на диске заблокировался - это провал в онлайн производительности. Это один из приветственных подводных камней. Т.е. как минимум два демона, один из которых обеспечивает коммуникацию между клиентами и скидывает данные на хранение во второй, который уже работает с хранилищем, и в принципе не страшно если заблокируется случайно где-то - потом выйдет из ступора и скушает пришедшее.
я теперь соовсем запутался я же спрашивал в самом начале про производительность??? может всё таки с памятью работать тогда и без демонов обойтись??
Ух. В общем смотри. Нынче присутствует две схемы обработки соединений. Первая - на каждый коннект - новый процесс. Это очень накладная схема при большом числе клиентов. Играет 100 человек - запущено 100 процессов PHP. Между кроме того, между собой им придется как-то обмениваться данными. Разделяемая память всем хороша, но не персистентна (т.е. не хранит данные при отрубании сервера), ну и не масштабируется по серверам, а это для такого принципа работы принципиально. Потом возникнут проблемы в том, как оповестить другие процессы, что что-то изменилось - они могут постоянно проверять состояние других игроков, конечно, но это накладно... хотя в случае разделяемой памяти можно, да. Как только начнем использовать другие решения типа мемкеша для распределения по серверам - усе, или чтение все забъет или лаги. Скидывать состояние при такой схеме можно в любую базу, в принципе, ибо максимум чем черевата блокировка - это один из игроков лагнет. Есть у такой схемы и еще один недостаток... опишу его позже. Вторая схема используется для обработки многих тысяч соединений в одном процессе. Называется мультиплексирование. С помощью операционной системы этот один процесс слушает тысячи сокетов, просыпается как только в один из сокетов что-то приходит, математика, плюется ответ в другие сокеты, снова спим. Этот процесс висит в памяти постоянно, т.е. он демон. Затыка у такой схемы два. Во-первых, очень большой поток данных, что математика не будет успевать. Решается переписыванием с ПХП на С, например, т.е. ускоряем вычисления. Но в итоге все-равно получится много больше соединений на сервер по сравнению с первым вариантом. Второй - это блокировки. Например, хочет этот один процесс записать что-то на диск - а у диска, увы, нынче огромные проблемы с асинхронностью, диск сейчас чем-то другим занят, и процесс ждет, пока диск освободится, что бы записать или считать нужные тебе данные. Пока он ждет - делать ничего не может (ибо не асинхронное), т.е. любые сигналы, что на сокеты пришли данные не отрабатываются, у всех лаг. С mysql например можно наладить асинхронное общение, но встроенная в php библиотека это не умеет, т.е. опять лаги. Тут выход простой - нужно наладить асинхронный коннект с неким вторым демоном, который не страшно и заблокировать. Еще о плюсах мультиплексирования. Если посмотришь онлайн игры - большинство используют UDP вместо TCP. В чем минусы TCP? Это гарантированный протокол, т.е. все, что отправлено - будет получено. И это его минус для игр - если вдруг какой-то пакет потерялся, будет лаг, пока TCP поймет, что он потерялся (не получит подтверждения) и вышлет его повторно. Т.е. пока TCP стек этим занимается, новые пакеты сидят в очереди. Неприятный лаг получается. C UDP все иначе - передающая сторона плюнула и забыла. Приемная сторона - приняла или нет. Она сама должна понять, что что-то потерялось и как-то компенсировать. Но скорее всего потерянные данные будут просто экстраполированы, т.е. никаких накладных расходов на его повтор. Вообще тут много можно написать.. даже учитывая, что это еще только базисы работы с высокими нагрузками и реалтайм данными, а не собственно что-то касательно онлайн игр, с которыми у меня опыта нет.
ну вот, а говорил не знаю, не могу за инфой по деманам конечно же в гугл отправите, меня интересует как один процесс на сервере может слушать кучу сокетов??
Ну и опять же, я не говорил, что не знаю, я говорил, что не хочу за ручку вести. Хотя даже то, что я написал, можно было нагуглить без проблем. Чуточку дольше, ага. А в самом начале я дал название, куда стоит пойти - phpDaemon - это фреймворк для построения мультиплексирующих демонов на PHP. А если интересна подноготная, как он работает, то начинать с этого http://ru.php.net/manual/en/ref.sockets.php в частности socket_select. Ну им же и заканчивать.