ВНИМАНИЕ!
Наша конференция посвящена космической тематике и компьютерным играм.
Политические вопросы и происходящие в мире события в данный момент на нашем сайте не обсуждаются!
|
| » Идея: Сеть Независимых Секторов (X) | страница 4 |
|
|
|
|
Канал Игры Мечты: «Идея: Сеть Независимых Секторов (X)» |
|
| Идея стоит детального рассмотрения? |
| Да |
|
83% |
[ 5 ] |
| Нет |
|
16% |
[ 1 ] |
|
| Всего проголосовало : 6 |
|
|
|
Minx
 1011 EGP
       
Рейтинг канала: 6(332)
Репутация: 139
Сообщения: 10548
Откуда: Gomel, Belarus
Зарегистрирован: 19.11.2005
  |
|
| Warstone : |
|
Давайте навернем на 12 байт данных (Id, X, Y) еще 40 байт ненужной инфы. (<MOVE ID="1234567890" X="1234567890" Y="1234567890" />)
|
Их ещё кто-то парсить должен (;
Но, с другой стороны, преждевременная оптимизация ... (с) Энтони Хоар
_________________
μηδείς αγεωμέτρητος εισίτω |
|
|
|
Варсик
 545 EGP
  
Рейтинг канала: 4(81)
Репутация: 117
Сообщения: 4041
Откуда: Москва
Зарегистрирован: 22.12.2002
 |
|
| Minx : |
|
Но, с другой стороны, преждевременная оптимизация ...
|
Или здравый смысл, если есть откуда срисовывать. Можно сказать что все придумано до нас, надо только найти. А тут даже не найти, а просто с пола подобрать.
| Minx : |
|
Их ещё кто-то парсить должен (;
|
Давайте не будем о DOM парсерах, ну пожалуйста.
_________________
WARNING: By reading this post you accept that this post is genius. |
|
|
|
Jerry Rezet
 581 EGP
Рейтинг канала: 5(113)
Репутация: 86
Сообщения: 3365
Откуда: Санкт-Петербург.
Зарегистрирован: 01.04.2005
|
|
| ZZZ : |
На нормальном же языке, можно взять, например, ICE. Быстр, удобен, функционален и общается через бинарный протокол, а не какой-нить дико избыточный xml или не многим лучший json.
И я думаю, что это не единственное ограничение.
|
Йпт.. Дык! Блин.. Об чом и речь! Похрену на чом, лишь бы работало - в конце концов "нам ехать, а не шашечки", arrrgh! 
_________________
- Вы не представляете, как вам повезло, что я здесь. Вы об этом еще пожалеете. [c] |
|
|
|
Sh.Tac.
151 EGP
Рейтинг канала: 5(108)
Репутация: 14
Сообщения: 1426
Зарегистрирован: 27.07.2005
|
|
| ZZZ : |
|
Уж точно не вижу смысла в написании своей библиотеки RPC, тем более, что задача отнюдь не тривиальна.
|
заявление ненамного грамотнее, чем делать всё ядро сервера на СУБД 
особенность RPC в том, что это _синхронный_ запрос
наподобие SQL запроса в СУБД
т.е. процесс/тред блокируется до тех пор пока не придёт ответ
рилтаймовый боевой сервер себе такого позволить не может
все запросы в нём глубоко асинхронны, т.е. отправил и забыл, ну или забросил контекст запроса в память, чтобы понять о чём была "речь", когда ответ таки придёт
бинарный протокол... ну мне например пришлось изготовить один простенький, собсно за пару дней, это не так сложно как кажется, - главное подход
вообще в идеале сервер должен лишь обрабатывать сообщения и представлять собой по сути реализацию протокола, возможно в виде стейт-машины умноженной на N клиентов
_________________
This is what you get ...
(c) Radiohead |
|
|
|
ZZZ
70 EGP
Рейтинг канала: 2(22)
Репутация: 13
Сообщения: 225
Откуда: Краснодарский край
Зарегистрирован: 20.03.2009
|
|
Кажется я начинаю понимать Павла, когда он говорил о неадекватности... Ну ладно, пока продолжу...
| Sh.Tac. : |
|
особенность RPC в том, что это _синхронный_ запрос
|
Знаешь, я могу ошибаться с терминологией, но я сам, лично, писал асинхронный протокол удалённого вызова процедур. При этом можно было отдельными потоками пересылать довольно большие объёмы данных и, в том числе, итераторы (даже вложенные!). Ну требовалась там такая круть. Работало довольно быстро при десяти-двадцати процентах избыточности -- т.е. лучше, чем xmpp, например. Как сериализатор я использовал питоновский pickle, но в общем-то можно было написать и свой.
Кстати, это она из редких вещей, которой я могу гордится, ибо получилось хорошо!
| Sh.Tac. : |
|
рилтаймовый боевой сервер себе такого позволить не может
|
Того, что предложил Warstone (<MOVE ID="1234567890" X="1234567890" Y="1234567890" />), конечно не может. Это ясно.
Вот только надо немного подумать головой и можно хорошо минимизировать передаваемые данные.
Как пример. Сравнение, может, не совсем корректное, но очень хорошо отражает разницу подходов. Вот есть растровая графика, а есть векторная. Все знают разницу? Надеюсь, что все. Зачем постоянно передавать местонахождение, попустим корабля, координатами, где он находится, когда можно просто указать вектор движения: "объект такой-то движется от сюда туда-то на такой-то скорости (или "с таким-то ускорением")". И клиент его спокойно будет отрисовывать. при изменении траектории, можно просто передать новые данные. Элементарно!
Ясно, что для кваки оно не подойдёт. Но я не про такую игру думаю. Вон, посмотрите на SW. Чем он там с сервером общается? Json? И ничего, играбельно даже с моими секундными пингами и потерей каждого десятого пакета...
Просто надо включить мозги и думать, а не заниматься кофеваркостроением.
| Sh.Tac. : |
|
вообще в идеале сервер должен лишь обрабатывать сообщения и представлять собой по сути реализацию протокола, возможно в виде стейт-машины умноженной на N клиентов
|
Интересная мысль... Но я плохо представляю, кто это реализует.
| Warstone : |
|
В этих системах для тебя все сделал дяденька которому много платили.
|
Угу, а бедные флешеры работают за чашку риса...
| Warstone : |
|
Тогда все просто. Любой принимаемый и обрабатываемый поток данных - априори RPC, так? На той стороне этот поток приняли. А значит вызвана была процедура.
|
У меня просто нет слов... Не буду с тобой спорить, потому что ты плохо представляешь, о чём говоришь.
| Warstone : |
|
HTTP - это RPC, FTP - RPC
|
Да.
| Warstone : |
|
TCP - тоже RPC (не RPC он если его обработка зашита в железе. Как, например в nVidia чипах), IP - RPC
|
Нет.
А теперь, если хочешь что-то сказать, сначала найди почему оно именно так, как я сказал. Сам найди, я помогать не буду. И объяснять тоже. Я сюда отдыхать прихожу.
P.S. Почитал, Warstone, что ты мне написал... Знаешь, моя вторая жена могла вывести меня из себя только одним способом -- переврать смысл сказанного. Притом обычно она выбирала самый простой способ, а именно вырывание фразы из контекста. Ты прямо повторил её подвиг! Очень не приятно.
_________________
It's good to be bad... |
|
|
|
KUT
120 EGP
Рейтинг канала: 1(9)
Репутация: 8
Сообщения: 360
Откуда: тока не выгоняли
Зарегистрирован: 17.07.2005
|
|
Warstone
Какие сплайны те нравятся?
(йа например кубические Безье использую..)
|
|
|
|
ZZZ
70 EGP
Рейтинг канала: 2(22)
Репутация: 13
Сообщения: 225
Откуда: Краснодарский край
Зарегистрирован: 20.03.2009
|
|
Да, Warstone, может я и не плохой программист, но я пока никакой игростроитель. Вот ты показал, что требуется асинхронность протокола связи. И я с тобой согласен. Просто не задумывался пока об этом. Значит, чистый xmlrpc и jsonrpc уже точно не подходят.
Т.е. если ты будешь нормально пояснять свою мысль, то диалог вполне может получиться.
_________________
It's good to be bad... |
|
|
|
KUT
120 EGP
Рейтинг канала: 1(9)
Репутация: 8
Сообщения: 360
Откуда: тока не выгоняли
Зарегистрирован: 17.07.2005
|
|
ZZZ
А какой сериализатор нынче популярен?
тоесть конечно XML но мнебы чтото компактнее и универсальнее как например пхпшный...
|
|
|
|
Варсик
545 EGP
Рейтинг канала: 4(81)
Репутация: 117
Сообщения: 4041
Откуда: Москва
Зарегистрирован: 22.12.2002
|
|
Как это так? Когда приходит TCP пакет - вызывается программа, в ядре, но... Причем TCP - это подсчет сумм, проверка валидности... Там все далеко не тривиально! Как это нет!
| KUT : |
|
Какие сплайны те нравятся?
|
Честно говоря не сильно вникал. Нашел статью "как это делается в HL2", потом еще какую-то, отвязанную от игрушки. Реализовал на Флеше. Получилось. Так что тут я не до конца проработал тему. Каюсь. Какие использовал - не скажу.
| ZZZ : |
|
Т.е. если ты будешь нормально пояснять свою мысль, то диалог вполне может получиться.
|
Хорошо, давай попробуем. Буду стараться перед ответом считать до 10, в качестве упражнения для тренировка памяти. 17 секунд ИМХО достаточно.
| KUT : |
А какой сериализатор нынче популярен?
тоесть конечно XML но мнебы чтото компактнее и универсальнее как например пхпшный...
|
Можно для особо одаренных (меня) что есть сериализатор? Вроде-же это такая функция, когда объект в бинарный код запаковывают.
_________________
WARNING: By reading this post you accept that this post is genius.
Последний раз редактировалось: Варсик (07:56 22-07-2009), всего редактировалось 1 раз |
|
|
|
KUT
120 EGP
Рейтинг канала: 1(9)
Репутация: 8
Сообщения: 360
Откуда: тока не выгоняли
Зарегистрирован: 17.07.2005
|
|
| Warstone : |
|
в бинарный код запаковывают
|
Да такой алгоритм.. пакует обычно всё, переменные, массивы, обьекты... Кстати во флеше тоже есть свой встроеный)
|
|
|
|
Shirson
1605 EGP
 
Рейтинг канала: 7(626)
Репутация: 219
Сообщения: 16511
Откуда: 79°W 44°N
Зарегистрирован: 29.01.2002
|
|
| Warstone : |
|
Можно для особо одаренных (меня) что есть сериализатор?
|
Это то, что осуществляет сериализацию - запись структуры данных в поток.
_________________
У меня бисера не доxеpа.
Последний раз редактировалось: Shirson (10:10 22-07-2009), всего редактировалось 1 раз |
|
|
|
Guest
2075 EGP
       
Рейтинг канала: 5(167)
Репутация: 376
Сообщения: 27975
Откуда: Моск.
Зарегистрирован: 12.10.2004
|
|
| ZZZ : |
|
Как пример. Сравнение, может, не совсем корректное, но очень хорошо отражает разницу подходов. Вот есть растровая графика, а есть векторная. Все знают разницу? Надеюсь, что все. Зачем постоянно передавать местонахождение, попустим корабля, координатами, где он находится, когда можно просто указать вектор движения: "объект такой-то движется от сюда туда-то на такой-то скорости (или "с таким-то ускорением")". И клиент его спокойно будет отрисовывать. при изменении траектории, можно просто передать новые данные. Элементарно!
|
Извините, что вмешаюсь, но тут позарез потребуется обеспечить гарантированную доставку пакета, иначе объект так и "полетит" по прямой, а потом начнутся либо рывки, либо расхождение. Неудачный вариант для среды передачи с многочисленными глюками и негарантированной доставкой...
ИМХО, интерполяция между пришедшими пакетам координат (скажем, 5-6 кадров - число чисто умозрительно, не пробовал, может быть ватно будет) таки будет намного вменяемее, особенно по хреновому (а где вы видели хорошие?) каналу...
Можно ещё извратиться с более весёлыми методами, как-то пересылать кривизну траектории (раз уж векторную графику упомянули) и/или пересылать данные при предполагаемом расхождении траекторий выше некоторого порога...
Но это всё же частности алгоритма
_________________
Трещит земля как пустой орех
Как щепка трещит броня |
|
|
|
ZZZ
70 EGP
Рейтинг канала: 2(22)
Репутация: 13
Сообщения: 225
Откуда: Краснодарский край
Зарегистрирован: 20.03.2009
|
|
| Warstone : |
|
Как это так? Когда приходит TCP пакет - вызывается программа, в ядре, но... Причем TCP - это подсчет сумм, проверка валидности... Там все далеко не тривиально! Как это нет!
|
Оно есть так, как я сказал. Поищи ответ самостоятельно.
| KUT : |
|
А какой сериализатор нынче популярен?
|
XML... Не люблю его.
Когда нужна читаемость сериализуемых данных, например при отладке, я беру YAML и радуюсь. А когда скорость обработки и минимальный обём -- pickle с небольшими ограничениями "от меня", чтобы нельзя было отправить (а главное прочитать!) что-нить из нестандартных типов.
| Guest : |
|
Извините, что вмешаюсь, но тут позарез потребуется обеспечить гарантированную доставку пакета, иначе объект так и "полетит" по прямой, а потом начнутся либо рывки, либо расхождение. Неудачный вариант для среды передачи с многочисленными глюками и негарантированной доставкой...
|
Рывки будут. Я думал об этом. Можно минимизировать путём минимального расхождения. Т.е. если пакетик потерялся (допустим, две секунды нет подтверждения), то можно повторить. При приходе опоздавшего пакета, клиент может плавно его (объект) передвинуть.
На практике же... Ребят, как часто у вас пакеты теряются? Сколько ещё идиотов с такой связью, как у меня? А сколько из них хотят поиграть? ИМХО, сегодня это уже не актуально.
А закидывать юзера UDP-пакетами... Это как-то не комильфо...
Но если уж очень хочется, то можно открыть два канала (два порта, или подумать, как в один объеденить, а потом разделить). Один управляющий -- для него пойдёт любая синхронная rpc, а второй однонаправленный с кучей потоковых данных об изменениях местоположения объектов. Но это так, мысли. Мне кажется, что для такого рода игры, большего, чем я предложил не надо.
| Guest : |
|
Но это всё же частности алгоритма
|
Да. Я просто предложил идею.
А вообще, меня плющит от того, в какую дребедень мы скатились -- обсуждаем гайки новой машины, тогда, когда нет ни двигателя, ни колёс... Сколько раз я уже ловился на это! Всё-таки надо более планомерно.
Кстати, общую схему двигателя я дал, а никто ни одного вопроса не задал. Одно из двух: либо все всё поняли, либо никому не интересно.
_________________
It's good to be bad...
Последний раз редактировалось: ZZZ (12:30 22-07-2009), всего редактировалось 1 раз |
|
|
|
Zachesa
 151 EGP
Рейтинг канала: 4(95)
Репутация: 13
Сообщения: 1420
Откуда: Хабаровск
Зарегистрирован: 12.11.2007
|
|
Ты уж извини, мне интересно конечно, но скорее в познавательном плане. Все мои задумки сконцентрированны немного в другом.
добавлено спустя 4 минуты:
Хотя думаю стоит всё же совместить tcp для более критичных данных, udp для всякой мишуры. Инфу дублировать в том плане, что передовать одновременно и изменение вектора движения и с определённой переодичностью координаты и ориентацию объекта с привязкой во времени (желательно с опереженим), а в клиенте сделать алгоритм сглаживания картинки при рассинхронизации данных.
добавлено спустя 1 минуту:
А так общая идея не сильно отличается от моей разве, что я ворота органически не перевариваю и хочу масштабности побольше.
_________________
Язык Образов, для ситуационного моделирования, программирования и как язык мысли, думающей машины.
Последний раз редактировалось: Zachesa (12:48 22-07-2009), всего редактировалось 2 раз(а) |
|
|
|
ZZZ
70 EGP
Рейтинг канала: 2(22)
Репутация: 13
Сообщения: 225
Откуда: Краснодарский край
Зарегистрирован: 20.03.2009
|
|
Блин! Сел уже работать и тут до меня дошёл весь комизм ситуации... Спорим, блин...
TCP я вляется протоколом с подтверждением. Т.е. в нём априори не может ничего потеряться и это не надо проверять. Т.е. если железо не пропустило IP-пакет, то TCP ничего не даст пользователю, пока этот пакет всё-таки не придёт.
Так что действительно, либо отказываться от TCP в пользу UDP (что, в идеале, правильно), или положить на задержки, которые являются достаточно редким явлением.
И, кстати, всё можно свалить на плохие погодные условия в туманности Конская голова, через которую проходит канал связи...
добавлено спустя 15 минут:
| Zachesa : |
|
Хотя думаю стоит всё же совместить tcp для более критичных данных, udp для всякой мишуры. Инфу дублировать в том плане, что передовать одновременно и изменение вектора движения и с определённой переодичностью координаты и ориентацию объекта с привязкой во времени (желательно с опереженим), а в клиенте сделать алгоритм сглаживания картинки при рассинхронизации данных.
|
Возможно. Но это уже частности. Пока к ним слишком рано подходить. Не раньше, чем не хватит простых средств.
| Zachesa : |
|
желательно с опереженим
|
Телепатией пока пользуются только самые крутые сервера Пентагона, а вы хотите, чтобы обычный хост будущее предсказывал? Приблизительное опережение может рассчитать и клиент.
| Zachesa : |
|
А так общая идея не сильно отличается от моей разве, что я ворота органически не перевариваю и хочу масштабности побольше.
|
Поверьте, моя очень сильно отличается от вашей. В первую очередь тем, что она сегодня реализуема.
_________________
It's good to be bad...
Последний раз редактировалось: ZZZ (13:05 22-07-2009), всего редактировалось 1 раз |
|
|
|
Zachesa
151 EGP
Рейтинг канала: 4(95)
Репутация: 13
Сообщения: 1420
Откуда: Хабаровск
Зарегистрирован: 12.11.2007
|
|
Как данные хочешь хранить, на какое количество клиентов расчитываешь?
_________________
Язык Образов, для ситуационного моделирования, программирования и как язык мысли, думающей машины. |
|
|
|
бухой джедай
183 EGP
Рейтинг канала: 2(19)
Репутация: 70
Сообщения: 7906 Предупреждений: 1
Откуда: Одесса:)
Зарегистрирован: 08.09.2007
|
|
| ZZZ : |
|
или положить на задержки, которые являются достаточно редким явлением.
|
твоибы слова да кое кому в уши
_________________
Так Добрый вечер...Превед с большого Бодуна...
Магистр Непросыхаемость...
Злобный Рецедивист... |
|
|
|
Варсик
545 EGP
Рейтинг канала: 4(81)
Репутация: 117
Сообщения: 4041
Откуда: Москва
Зарегистрирован: 22.12.2002
|
|
| ZZZ : |
|
Телепатией пока пользуются только самые крутые сервера Пентагона
|
А так-же все тот-же сервер HL2 который занимается предсказанием ввода, предсказанием движения и предсказанием лага. Кубические сплайны, о которых я тут распинался - частный случай этого предсказания.
| Zachesa : |
|
Хотя думаю стоит всё же совместить tcp для более критичных данных, udp для всякой мишуры. Инфу дублировать в том плане, что передовать одновременно и изменение вектора движения и с определённой переодичностью координаты и ориентацию объекта с привязкой во времени (желательно с опереженим), а в клиенте сделать алгоритм сглаживания картинки при рассинхронизации данных.
|
Вот веришь или нет, но в еще Counter-Strike (1-й который), то бишь в сервере HL для каждого клиента изначально использовалось 2 подключения: TCP для проверки живости клиента и UDP для данных. Правда потом от TCP отказались.
_________________
WARNING: By reading this post you accept that this post is genius. |
|
|
|
Zachesa
151 EGP
Рейтинг канала: 4(95)
Репутация: 13
Сообщения: 1420
Откуда: Хабаровск
Зарегистрирован: 12.11.2007
|
|
Да можно вообще от tcp отказаться и ввести проверку критичных данных аппаратно, или вообще ввести избыточность типа того же кода Хемминга, пересылать данные только в бинарном виде, чтоб уменьшить трафик. Вообщем это всё достаточно тривиально, как и то что это всё гайки, а двигатель с трансмиссией всё ещё не вырисовывается
_________________
Язык Образов, для ситуационного моделирования, программирования и как язык мысли, думающей машины. |
|
|
|
Варсик
545 EGP
Рейтинг канала: 4(81)
Репутация: 117
Сообщения: 4041
Откуда: Москва
Зарегистрирован: 22.12.2002
|
|
| Zachesa : |
|
ввести проверку критичных данных аппаратно
|
Что ты куришь? Я-ж сколько раз говорил, что под тебяникто железки выпускать не будет!
| Zachesa : |
|
или вообще ввести избыточность типа того же кода Хемминга
|
Соврал. Я говорил не о Хемминге а о Хаффмане. Вобщем это алгоритм архивации при малых объемах данных. Если грубо, он предлагает заменять байты на битовое их представления, основываясь на том, что некоторых байтов в протоколе будет больше, чем других (в частности 0).
| Zachesa : |
|
Вообщем это всё достаточно тривиально, как и то что это всё гайки, а двигатель с трансмиссией всё ещё не вырисовывается
|
Мда-а-а... Это и есть трансмиссия ибо http://www.multitran.ru/c/m.exe?CL=1&l1=1&s=transmission
добавлено спустя 2 минуты:
А Хемминга при TCP вводить вообще не имеет смысла, так как это протокол с проверкой передаваемых данных и гарантирующий их доставку на другой конец. Все-таки головой думать надо.
добавлено спустя 4 минуты:
| Guest : |
Извините, что вмешаюсь, но тут позарез потребуется обеспечить гарантированную доставку пакета, иначе объект так и "полетит" по прямой, а потом начнутся либо рывки, либо расхождение. Неудачный вариант для среды передачи с многочисленными глюками и негарантированной доставкой...
ИМХО, интерполяция между пришедшими пакетам координат (скажем, 5-6 кадров - число чисто умозрительно, не пробовал, может быть ватно будет) таки будет намного вменяемее, особенно по хреновому (а где вы видели хорошие?) каналу...
Можно ещё извратиться с более весёлыми методами, как-то пересылать кривизну траектории (раз уж векторную графику упомянули) и/или пересылать данные при предполагаемом расхождении траекторий выше некоторого порога...
|
Линейные сплайны учитывают 1 кадр(предсказание линейного движения),
квадратные - 2 кадра (предсказание поворота)
кубически - 3 кадра (предсказание разгона, торможения)
собственно именно по этому, если уж использовать сплайны, то кубические.
добавлено спустя 7 минут:
| ZZZ : |
|
Так что действительно, либо отказываться от TCP в пользу UDP (что, в идеале, правильно), или положить на задержки, которые являются достаточно редким явлением.
|
А вот тут из-за особенностей UDP его роутеры могут и не пустить. То есть если нехватает у роутера вычислительного ресурса - первое что режет UDP (тупо приоритет обработки ниже ибо программист должен закладываться на то что UDP не доелтит). Если-же делать проверку хоть какую, то в TCP сделано почти оптимально. Они с точностью до бита запаковывали хедер (отсылка на флаги). Так что гм... UDP это для повторяющихся данных. грубо говоря если человек бежит (CS), и ему приходят пакеты со скоростью 20 в секунду (1000 / пинг), то если вдруг один из них потеряется, за счет сплайнов и предсказания эту потерю можно "скрасить", он тогда должны кидаться пакетом ВСЕ данные. В CS в одном UDP пакете передается все положения (X, Y, Z, углы, нажатые кнопки(!)) всех игроков. Именно поэтому в CS нет понятия полета пули (в HL есть ракетки и летают они кривовато).
добавлено спустя 7 минут:
| Zachesa : |
|
Как данные хочешь хранить, на какое количество клиентов расчитываешь?
|
А вот это глупые вопросы. Вернее не глупые, а несвоевременные. Механизм секторов позволяет при переходе в другой сектор (там все-равно обычно грузят чего-нить и процесс долгий ну или заметный) переподключить клиента в другой сектор. Поэтому 2-й вопрос надо перефразировать как "Сколько клиентов на одном сервере или логическом игровом поле" (так как в той-же УО одна непрерывная карта расчитывалась на 5-6 серверах. Как достигалась синхронизация целей с одного сервера на другой - не знаю. Очень хочется покурить их исходники по этому поводу.).
Насчет где хранить - опять-таки не самый мудрый вопрос. Ответ зачастую будет "Распределенно". Так как у нас серверов много, то давайте при переходе из сектора в сектор передавать и данные. Тогда одновременно на одном сервере будут хранится только те игроки, которые сейчас в онлайне. При выходе в Оффлаин - данные об игроке будут скидываться с базу оффлаин игроков, которую можно отпартицировать и разбить на несколько серверов ибо процесс логина - тоже долгий и данные успеют подняться с медленного SQL в быструю память. На контрольном сервере только имеет смысл держать ограниченную информацию о тех кто в на каком сервере.
_________________
WARNING: By reading this post you accept that this post is genius.
Последний раз редактировалось: Варсик (17:22 22-07-2009), всего редактировалось 9 раз(а) |
|
|
|
|
|
|
|
|
Канал Игры Мечты: «Идея: Сеть Независимых Секторов (X)» |
|
|
| К списку каналов | Наверх страницы |
Цитата не в тему: Они - тупые свиньи. Это я тебе как спец по тупым свиньям говорю... (NoxVerner)
|
| » Идея: Сеть Независимых Секторов (X) | страница 4 |
|
