Сказка навсегда остановлена.
Мы безмерно благодарны каждому из вас за время, которое вы подарили нашей игре, истории, которые вы создали, поддержку, которую оказывали друг другу и нам.
Надеемся, Сказка останется светлым и добрым воспоминанием в вашей жизни, и вы будете вспоминать наши приключения с улыбкой.
Это были замечательные тринадцать лет. Спасибо вам за них.
С любовью, команда Сказки.
|
CrazyNiger
|
|
[DRAGO]
Магистр
могущество: 9737
длань судьбы
мужчина
Злобный Дракон
261 уровня
|
Hamstermayorovp
Это резко снизит читаемость ответа. А если плевать на читаемость - то надо переходить на бинарный протокол сразу, без промежуточного json с однобуквенными ключами.
Так читать-то его никому и не надо.
Ну да, можно и на бинарный. И гзипом его.
Ответы от веб-сервера API и так жмуться гзипом (ну я на это надеюсь =)). Если это не так, то Тиендилу всего-то нужно добавить сжатие ответа и добавить соответствующий заголовок в ответ.
|
|
Hamster
|
|
без гильдии
могущество: 5163
длань судьбы
гоблин
Джеаки
102 уровня
|
Response Headers:
<...>
Content-Encoding: gzip Да, действительно. Я не посмотрел, на самом деле размер ответа - 4-5 кб.
|
|
Tiendil
|
|
[НБ]
Магистр
могущество: 14696
разработчик
дварф
Халлр
106 уровня
|
CrazyNigerНет, второй вариант - вобще не вариант. Как же REST и все такое =)
REST и всё такое обычно страдают, когда начинаются оптимизации. По поводу выноса названий и всего остального «статического» в отдельный метод уже есть такая задача. Будет делаться. Так как это не только «лишняя» информация в запросе, но и может понадобиться отдельно. Если возвращать только запрошенные клиентом блоки данных, то нужен механизм сигнализации о том, что они изменились (По полю-версии на каждый блок?). Причём, будет проблема с задержкой их обновления. Например, в журнале уже написано о новом квесте, а сама информация о квесте ещё не получена. По этой же причине мне не нравится идея разбиения на несколько запросов, в этом случае ещё и пиковая нагрузка на сервер может вырасти раза в 2. Поэтому я пока склоняюсь всё-таки к возвращению дельты информации, возможно, укрупнённой как раз до блоков. Если квесты не менялись, квесты не возвращаем. Это хорошо тем, что разработчику клиента не надо будет делать никаких волшебных проверок и оптимизаций. И не надо будет следить за появлением новых блоков. Отправил 1-ый запрос на полные данные, потом шлёшь запросы на дельты. И всю важную информацию получаешь одновременно.
|
|
Hask
|
|
без гильдии
могущество: 2897
орк
Каргрел
110 уровня
|
Поддержу вариант с дельтой, на мой взгляд в плане использования на стороне клиента он самый простой, если я верно представляю возможную реализацию.
|
|
CrazyNiger
|
|
[DRAGO]
Магистр
могущество: 9737
длань судьбы
мужчина
Злобный Дракон
261 уровня
|
В таком варианте есть много проблем, которые будут иметь плавающий характер.
Как север будут определять что он отправил клиенту, а что нет? Ну допустим тут можно информацию об этом хранить в сессии. А что если что-то не дошло до клиента, а сервер думает что отправил? тогда последующие данные, которые опираются на то, что знает сервер, будут не полными для клиента.
|
|
mayorovp
|
|
без гильдии
могущество: 95
эльфийка
Shebang
47 уровня
|
CrazyNigerВ таком варианте есть много проблем, которые будут иметь плавающий характер.
Как север будут определять что он отправил клиенту, а что нет? Ну допустим тут можно информацию об этом хранить в сессии. А что если что-то не дошло до клиента, а сервер думает что отправил? тогда последующие данные, которые опираются на то, что знает сервер, будут не полными для клиента.
Клиент в запросе на обновление передаст отметку времени, которую ему в прошлый раз отдал сервер.
Сообщение изменено
|
|
Hask
|
|
без гильдии
могущество: 2897
орк
Каргрел
110 уровня
|
CrazyNigerА что если что-то не дошло до клиента, а сервер думает что отправил? тогда последующие данные, которые опираются на то, что знает сервер, будут не полными для клиента.
Решается параметром в запросе. Как пример, это может быть значение data.turn.number из последних полученных данных, информирующее сервер о том, что "на указанный ход у меня вся информация есть, нужно всё что изменилось позже". Если совпадает с тем, что последнее отправлял сервер, то дельта передаётся клиенту, если нет - клиенту в качестве дельты отправляется полная версия ответа. Это даст гарантию, что изменения применяются к тем данным, для которых предназначены. Со стороны клиента эта схема прозрачна и не требует обработки частных случаев. upd Слишком долго я пишу, уже ответили)
Сообщение изменено
|
|
Hamster
|
|
без гильдии
могущество: 5163
длань судьбы
гоблин
Джеаки
102 уровня
|
Что-то не могу найти нигде. Как узнать имя хранителя по id аккаунта? Неужели никак? В /api/info/ возвращается только свой аккаунт.
Если на данный момент никак, то неплохо бы добавить этот параметр в /game/api/info/ в data.account.
|
|
Hask
|
|
без гильдии
могущество: 2897
орк
Каргрел
110 уровня
|
адрес: /api/info/
"account_name": <строка>|null // имя пользователя, если он вошёл в игру, иначе null
|
|
Hamster
|
|
без гильдии
могущество: 5163
длань судьбы
гоблин
Джеаки
102 уровня
|
Haskадрес: /api/info/
"account_name": <строка>|null // имя пользователя, если он вошёл в игру, иначе null
Большое спасибо. HamsterКак узнать имя хранителя по id аккаунта? Неужели никак? В /api/info/ возвращается только свой аккаунт.
|
|
Hask
|
|
без гильдии
могущество: 2897
орк
Каргрел
110 уровня
|
Вот это я лажанул. Стыдно, сорри)
|
|
Tiendil
|
|
[НБ]
Магистр
могущество: 14696
разработчик
дварф
Халлр
106 уровня
|
Hamster
А зачем тебе имена всех пользователей?
|
|
Hamster
|
|
без гильдии
могущество: 5163
длань судьбы
гоблин
Джеаки
102 уровня
|
Мне не нужны имена всех пользователей (хотя это я тоже могу сделать), мне нужно имя пользователя, о котором я получаю информацию.
|
|
Tiendil
|
|
[НБ]
Магистр
могущество: 14696
разработчик
дварф
Халлр
106 уровня
|
ок, добавлю имя
|
|
Hamster
|
|
без гильдии
могущество: 5163
длань судьбы
гоблин
Джеаки
102 уровня
|
О, спасибо)
|
Чат
