Один день из жизни сервера или "ОДМИН ЛОХАИТ!!"

[Zubastic]

Статусапдейтом грешит и сама птска. От этого никуда не уйти, да.

[Deazer]

Сообщение от Pointer*Rage

Что и когда я у тебя спрашивал? Все, что я спрашивал - ты не давал внятного ответа, отвечал мне в основном всегда айзен (это если говорить про то время, когда ты еще не самовыпилился из моих контактов). Да и я на самом деле сомневаюсь, что ты бы смог на них ответить, т.к. они были довольно таки специфичны (а-ля отлов создания обьектов через JDI) Так, что о чем может идти речь?
Если ты говоришь про мои вопросы адресованные тебе в прошлой теме (извини, ванговать, какие вопросы ты имеешь ввиду - не умею), то ты и так уже 2 раза с ними слился. Ответа уже не надо

P.S. #1: глаза опять в жопе? читаем еще раз статью, там апперансами не пахнет.
P.S. #2: спеллчекер хотя бы включи, а то "payton" и другие вещи, смешно читать.

[KID]

не нужно ничего задерживать, нужно реализовывать так, чтобы СУ приходил тогда, когда надо. к тому же вообще почему именно к нему прицепились, пакет мелкий, меняет он "мало" данных. есть куда более толстые пакеты, которые также шлются на абы отослать. я не знаю какую хронику использует поинтер, но в тех, где появились exuserinfo, expetinfo, exnpcinfo и другие ништяки при должном их использовании можно сделать няшку крепче птски.

не могу представить ситуации, в которой была бы оправдана такая нагрузка. вариант из 200 гремлинов вокруг на которых кинули dot не предлагать

[linliss]

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

Статусапдейтом грешит и сама птска. От этого никуда не уйти, да.

И не только ими.

[Respect]

Сообщение от Pointer*Rage

Хорошая вещь, как и конфигурация отключения отображения трейдеров Очень не плохо бустит работу клиента (если конечно в сервере все держится на кноулистах и многопоточность почти не используется).
На самом деле, как видно на графике, MagicSkillUse имеет более или менее приемлемый рейт.

В китайском оффе есть еще опция отключения Pawn объектов, залетаешь в город и ловишь дикие лаги, включаешь, и не видно никого (кроме чата). Город пуст, лагов нету, можешь торговать, принимать трейд и тд.

В теории такую штуку можно запилить, и не только ее)

[KilRoy]

Конечно профит с 5(или сколько там паков) на осаде, и при этом дикие лаги, слишком здраво выглядит. Но всеже; может место имеет быть факту, что не стоит на 1ну машину и сервер собирать оверадахера задротов? Откройте 2й, такой-же. Спадет пипл со 2го или первого - объединяем. Зачем вам тру проекты с 1000005000000 онлайна на 1н сервер? Люте же, глупо и люто.
Только не говорите, что это сложно "администрировать", читать сраные логи(пример абусса, с отдельным "типа" лог сервером).
Ну это ИМХА
Все, кончил, слился. Пакедава

[Donatte]

Так, господа. Опишите пожалуйста, если не влом, при каких условиях пакеты из группы "флуд" должны приходить. Заранее благодарен.

Можно и в ПМ, если это ещё пока жуткая тайна.

[Gattsu]

Ну если у Вас в очереди, на запись 20 пакетов, с перекрывающимися данными, зачем отсылать все 20, если можно отослать один. Смысл задержки в накоплении изменений. Отсылать можно с допустимой задержкой, для человека это не заметно. Как много раз Вы реагируете на смену кадра, наблюдаете сигнал синхронизации? В этом нет ничего странного, это известная практика, алгоритм Нейгла тот же, он сделан для других целей, но тот же принцип. Придерживая мы избавляемся от ненужных данных для сети и нагрузки как на стороне пользователя, так и на сервере. Просто придерживать до приделов допустимой дельты, её можно легко рассчитать, по активности входящего и исходящего трафика. Посылая эти 20 пакетов, поток отрисовки пройдет по ним холостым ходом, отобразиться только последние обработанные изменение. А может там вообще при приходе этого пакеты вызывается перерисовка сцены, отсюдова может быть накладные расходы, на стороне клиента.

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

У меня просто нету бесконечного прироста скорости и квантового компьютера. Насколько мне известно при отключенном алгоритме Нейгла, Вы отсылаете данные без задержки, по сути сами формируете кадры. Сам TCP гарантирует доставку каждого пакета MTU. Проверка каждого пакета, на доставку, это накладные расходы, если превысить MTU на 1 байт это уже два пакета, насколько мне известно.

Вот Вам пример:
где:

PHP код:

delay check = time check * (send data size / MTU) 


send data size - размер данных при отправке.
time check - время проверки на доставку
send data size / MTU - количество пакетов (целочисленное деление без остатка)
delay check - задержки на проверку, доставки.


+ еще общая потеря данных при отправке возникнуть может, повторная отправка.

Размер данных можно подставить любой
даже умножить размер пакета в байтах на количество, а если вычесть один, из количества, получите избыточность.

Для однотипных пакетов

PHP код:

send data size = packet size * packet count 


packet size - размер пакета сервера(того же UpdateStatus)
packet count - количество пакетов
packet size * (packet count - 1) избыточность информации, она превышает 90% процентов, это тихий ужас.

send data size <= MTU в пределах допустимой нагрузки канала
send data size > MTU увеличивает нагрузку на канал

можно

PHP код:

send data size = packet size * packet count + сustom data 


custom data - сума размеров остальных пакетов, которые записываются в поток.

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

Это решение задачи в конкретных условиях.

[KID]

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

[Gattsu]

KID, я тоже об этом. Ну не знаю, каждому разработчику свое, на то он и разработчик. Так привык делать, основательно "копать". Когда просто не интересно