Убогость сетевого протокола в Ил-2 ЗС ПХ

[crocodile]

Мастера флуда на общие темы, слушай суды, берем Ethereal (модемы ищут спец. библиотеку) или там сетевой монитор дампим именно UDP (а то тут некоторые говоря про убогость протокола всуе TCP поминают ) и смотрим. У меня при скорости 56кб данных в пакетах более чем на 300 БАЙТ не было, а есть и по 15 - 20 (что хреново MTU не настроишь). Возможно что это поток, передаваемый дискретно (частота дискретизации зависит от выставленной в настройках скорости связи-это и ежу понятно), возможно что с ACK (черт знает, смотреть надо, а времени нет) Но тогда на сервак ложится задача выравнивать скорости и усекать "лишние" данные из толстых "потоков" в "тонкие" Вот чудится мне там поток сообщений... и возможно такой:
1, ID пилота или объекта (не по никам же вас разводить в потоке )
2. X - точность их можно косвенно определить по логу и они похоже флоаты, точность до сотых милиметра гы!
3. Y
4. z
5. Крен
6. Тангаж - из 2-6 и растет стрельба по пингу

И больше там вроде нафиг ничего не надо (вроде бы), если учитывать тот факт что все остальное считается на клиенте, НО это относительно объекта. А исчо не забывайте что надо бы установить соединение, т.е. передать начальное состояние окр. среды. Это кокраз и происходит при заходе на сервак (вот тут-то серваку и плохеет ибо это надо раздать всем) Тоже просто. Но еще надо организовать мониторинг состояния окружающей среды - получаем служебные сообщения, которые сначала уходят от клиента (принасекоившего, ну к примеру Пака - очень редкий тип сообщения ), а с сервака всем (кроме клиента, про split horison девелоперы должны были что-то слышать) Формат служебного сообщения может быть такой:
1. ID объекта - кто
2. ID объекта - связанный объект (к примеру, вирпил помнял самоль, о чем всем надо рассказать)
3. Состояние - если пришло такое сообщение, то состояние поменялось - мне рисуется что то типа EventLog - номер события и его параметры

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

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

ЗЫ. Реализовывать на серваке 64 массива, а потом их пустые гонять по всему интернету - зря вы так плохо думаете о МГ, я в это почему-то не верю
ЗЗЫ при таком решении очень обидно осознавать, что зена оторвавшая тебе полморды живет на твоей же машине, а не на каком ни будь мифическом сервере.

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

ЗЗЗЗЫ Паку: Истинный азимут передавать - излишества, достаточно хранить Х и У из предыдущего пакета

[pakman]

ЗЗЗЗЫ Паку: Истинный азимут передавать - излишества, достаточно хранить Х и У из предыдущего пакета

Извини, не могу пройти мимо

Крок, ты в игре педалями пользуешься? Может ну их, эти педали, а?

[RW_Daddario]

Извини, не могу пройти мимо

Крок, ты в игре педалями пользуешься? Может ну их, эти педали, а?

из -за педалей лагает сильно

[crocodile]

Честно говоря не понял логики в таких выводах. Если есть фрагментация на уровне IP - то будут переть пакеты размером с MTU

Я конечно имел в вду фрагментацию самодеятельную, а не IP, сие от Мг не зависит.

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

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

Для таких фортелей существуют шейперы. Не надо никаких прог писать, надо написать три команды на роутере

О точно! Токмо в нашем случае не поможет... жаль... жаль...

Фи, да вы батенька читер

Я не читер, это Пакман - читер

Крок, ты в игре педалями пользуешься? Может ну их, эти педали, а?

Паку: Уел! хадюка Снимаю шляпу, солю, перчу, ем

[AlexD]

Я конечно имел в вду фрагментацию самодеятельную, а не IP, сие от Мг не зависит.

Все-таки зависит. Если бы Ил-2 слал через чур большие дейтаграммы, то фрагментация на уровне IP будет.

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

Можно не только ACK'ами, можно генерить запросы на повторную передачу. Т.е. в протокол жестко забивается, что допустим каждый десятый пакет - обновление критических состояний, и если он не получен до таймаута, то уже требовать переповтора конкретного пакета, чтобы не перепосылать полное состояние. Вариантов-то уйма. А то чем мы тут занимаемся - гадание на кофейной гуще

[Maximus_G]

протокол сделан так что при инициализации сервера на 64 пользователя сразу инициализируются массивы данных с размерностью 64*ххх.
Для свободных для подсоединения мест ячейки массивов заполняются нулями и их успешно сжимает модемный протокол передачи данных.

При отключении сжатия соединения с софтверным модемом, стабильность связи на Г1 _повышается_.

[Kyzmich]

При отключении сжатия соединения с софтверным модемом, стабильность связи на Г1 _повышается_.

Это совет или вопрос?

...Всю неделю пролетал на G1 -ни одного фриза и кика ?
При этом число участников от20 до 50!? Соедениние 56к в ИЛ-е,в конфиге 4400?Прям странно?Может что поправили?

[Maximus_G]

Это совет или вопрос?

Не совет и не вопрос, личное наблюдение и комментарий к версии =FPS=Plumb.
Если вместо отсутствующих игроков идут нули, то они сжимаются еще раньше, чем доходят до модема.

...Всю неделю пролетал на G1 -ни одного фриза и кика ?
При этом число участников от20 до 50!? Соедениние 56к в ИЛ-е,в конфиге 4400?Прям странно?Может что поправили?

Сорри, не понял этого потока мыслей

[crocodile]

При всей убогости протокола он не пролезает в мопед Но гаспада АДСЛщики выставляют в Иле скорость соединения 28800 и имея пинг 50 дают такого гопака, что не у всякого модемщика получится Хм и вот еще что. Я тут умные слова было начал писать, про ICMP но посмотрев дамп трафика ни фига ни разу не увидел ICMP request/repay т.е. цифирь по букве Сэ считается исходя из UDP, интересно это как так? Хотя в районе закрытия соединения всетаки водятся несколько destination unreachable`ов

Интересно,а эта прелесть тоже обсчитывается серваком?

Ага, у Геннадича 4 х Третьих Спарка в кластере Или 8 Оптеронов перевязанных

[AlexD]

Хм и вот еще что. Я тут умные слова было начал писать, про ICMP но посмотрев дамп трафика ни фига ни разу не увидел ICMP request/repay т.е. цифирь по букве Сэ считается исходя из UDP, интересно это как так?

А какие проблемы посчитать Round-Trip Time по времени прохождения UDP ? Оно даже честнее будет И какой смысл гонять лишний траффик в ICMP только для вычисления RTT.

Хотя в районе закрытия соединения всетаки водятся несколько destination unreachable`ов

Ну это естественно. Port unreacheable небось. Кто-нибудь сокет закрывает слишком шустро.

P.S. А вообще, вся эта тема весьма странная. Люди понятия не имеют как именно формируются данные для передачи по сети, что именно передается клиенту, как полнота передаваемых данных влияет на состояние модели у клиентов, что можно отфильтровать, а что поставит модель раком и всяко далее. Вобщем, сочуствую сотрудникам ОМ, надеюсь что у них есть здоровое чуство юмора, чтобы читать всю эту пургу

[grun]

Вобщем, сочуствую сотрудникам ОМ, надеюсь что у них есть здоровое чуство юмора, чтобы читать всю эту пургу

они не читают, и правильно делают

[crocodile]

А какие проблемы посчитать Round-Trip Time по времени прохождения UDP ? Оно даже честнее будет И какой смысл гонять лишний траффик в ICMP только для вычисления RTT.

RTT подразумевает ответ на четко посавленный вопрос, через когда пришел replay на четко поставленный request (ну и штамп соответственно) т.е. пакеты нуна нумеровть, и т.д. и т.п. повторное изобретение велосипеда. Но с другой стороны понятно зачем это, жаль... мысль о том, что UDP пакетцы можно подержать пару-тройку секунд (ну чтоб крепче были ) без вреда для пынга придется оставить.

Ну это естественно. Port unreacheable небось. Кто-нибудь сокет закрывает слишком шустро.

P.S. А вообще, вся эта тема весьма странная. Люди понятия не имеют как именно формируются данные для передачи по сети, что именно передается клиенту, как полнота передаваемых данных влияет на состояние модели у клиентов, что можно отфильтровать, а что поставит модель раком и всяко далее. Вобщем, сочуствую сотрудникам ОМ, надеюсь что у них есть здоровое чуство юмора, чтобы читать всю эту пургу

Ну пока нет патча надо же очем-то подфлудеть, и мозг поточить Не про патч же :p Хотя понять что там передается и как фильтруется не так уж и сложно, сложно формат дейтаграммы узнать, и способ шифрования

Давайте луше про шары не флудеть, а подумаем вот над чем, фрагментятся ли Иловские датаграммы при передаче или нет? Скорее всего нет, но некоторые приколы сетевые можно было бы объяснить этим, как мне кажется

[RR_Vespertinus]

Млин Шпециалисты!!!
Кто-нить имеет опыт разработки проектов такого размера?

я бы не стал оспаривать квалификацию программеров, работающих в МГ.

Если тут собрались настолько крутые программисты, что, не зная реализации, оценивают порядок работ. Говорят о каких-то массивах. И вообще оказывается представляют как работает модель передачи данных в Иле. Ну, так почитайте специализированные ресурсы, а потом пишите письмо в МГ с кратким описанием алгоритма.

[crocodile]

И вообще оказывается представляют как работает модель передачи данных в Иле. Ну, так почитайте специализированные ресурсы, а потом пишите письмо в МГ с кратким описанием алгоритма.

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


Я думаю что у МГ вся эта битва в песочнице даже умиленной улыбки не вызывает. Даже хорошо зная все открытые протоколы ни фига не разберешься в закрытом (да еще ко всему прочему, возможно, шифрованному) Лично меня не интересует его (де)оптимизация шарами (и без них фризит и лагает), а то как этот протокол устроен вовнутрях.

[AlexD]

RTT подразумевает ответ на четко посавленный вопрос, через когда пришел replay на четко поставленный request (ну и штамп соответственно) т.е. пакеты нуна нумеровть, и т.д. и т.п. повторное изобретение велосипеда. Но с другой стороны понятно зачем это, жаль...

Практически на 100% уверен что пакеты и так пронумерованы и имеют timestamp. Это же UDP. Иначе как бороться с потерей и изменением порядка пакетов и синхронизировать задержки?

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

А смысл? Пинг стал самоцелью? Для комфортной игры имеют значение только задержки при передаче самих данных.

а подумаем вот над чем, фрагментятся ли Иловские датаграммы при передаче или нет? Скорее всего нет, но некоторые приколы сетевые можно было бы объяснить этим, как мне кажется

А что тут думать, сниффер в зубы и смотреть соответствующие поля в пакетах. Хотя я надеюсь что в Ил-2 все-таки дейтаграммы, время доставки которых критично, имеют разумный размер и не фрагментируются в большинстве случаев. Иначе действительно растут потери и задержки.

[crocodile]

Практически на 100% уверен что пакеты и так пронумерованы и имеют timestamp. Это же UDP. Иначе как бороться с потерей и изменением порядка пакетов и синхронизировать задержки?


А смысл? Пинг стал самоцелью? Для комфортной игры имеют значение только задержки при передаче самих данных.

Ну пинг, то он пингом, цифирь и цифирь себе. А вот если бы пинг шел по ICMP, а Иловский трафик по UDP никто не запретил бы мне написать прогу (когда научуся ) придерживающую на выход от клиента UDP, но не задерживающую на вход (и совсем никак не затрагивающую ICMP ), и вот тогда никакой ПУХ или БАРАН никогда в жизни в меня не попадет

Всетаки ты, наверно, прав, нумеруются все дейтаграммы и, скорее всего, штамп тоже ко всем прикручен, для борьбы с особо хитрыми и для отброса пакетов "из прошлого" (ежели данные шли по разным маршрутам с разными скоростями) Хотя камешков тут всяких подводных тоже изрядно, к примеру, если ждать только пакеты с номером больше крайнего полученного, то может случится что проскочит один-два по быстрому маршруту и переставят счетчики, а толпа тормозных может подойти попозже и получить отлуп (по Мерфи после поворота событий от плохого к худшему цикл повторяется, и эта ситуация может развиваться и развиваться) Попробовать бы потрейсить в моменты особого лагания... может есть закономерность...

А что тут думать, сниффер в зубы и смотреть соответствующие поля в пакетах. Хотя я надеюсь что в Ил-2 все-таки дейтаграммы, время доставки которых критично, имеют разумный размер и не фрагментируются в большинстве случаев. Иначе действительно растут потери и задержки.

Больше 300 байт (именно данных) не видел (56кб) , отсюда и подозрения насчет фрагментации, хотя и в 300 байт можно много чего напихать...

[AlexD]

Ну пинг, то он пингом, цифирь и цифирь себе. А вот если бы пинг шел по ICMP, а Иловский трафик по UDP

Практически не встречал игр, которые бы пользовали ICMP. Исключение с которым я сталкивался это NFS:U, да и тот по-моему только проверяет пингами живость хостов.

никто не запретил бы мне написать прогу (когда научуся ) придерживающую на выход от клиента UDP, но не задерживающую на вход (и совсем никак не затрагивающую ICMP ),

Для таких фортелей существуют шейперы. Не надо никаких прог писать, надо написать три команды на роутере

и вот тогда никакой ПУХ или БАРАН никогда в жизни в меня не попадет

Фи, да вы батенька читер

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

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

Больше 300 байт (именно данных) не видел (56кб) , отсюда и подозрения насчет фрагментации, хотя и в 300 байт можно много чего напихать...

Честно говоря не понял логики в таких выводах. Если есть фрагментация на уровне IP - то будут переть пакеты размером с MTU (1500 байт по умолчанию) и хвосты дейтаграм переменного размера. Если пакеты идут по 300 байт, то фрагментации нет, если конечно MTU не 300 байт Если речь идет о самодеятельной фрагментации внутри самого Ил-2 - то тут уже ничего увидеть без разбора протокола нельзя. Ну разве что закономерности какие-то, например постоянно идут 5 пакетов по 300 байт и за ними 100 байт. Можно предположить что пересылается какая-то структура размером 1600 байт порезаная ручками программиста. Тут уже мало чего можно сказать. Можно сделать тупо - постоянно гонять полные состояния, пусть даже порезанные ручками на маленькие пакеты, а можно по уму - передавать только изменения состояния, причем более важные чаще, менее важные реже. Последним способом можно спокойно добиться обновления всех объектов на карте и сэкономить траффик без грубого отрезания путем применения яркой и новой идеи сфер. Как именно сделано в Ил-2 - судить с опрометчивостью, подобной начинателю топика, не возьмусь.

[grun]

2 =FPS=Plumb: по памяти вопросов нет. А алгоритм не пишется априори "я отказываюсь от" - в алгоритме д.б. все объекты + радиус +фильтры на типы объектов. Я имел в виду не память а быстродействие.

[=FPS=Plumb]

2 =FPS=Plumb: по памяти вопросов нет. А алгоритм не пишется априори "я отказываюсь от" - в алгоритме д.б. все объекты + радиус +фильтры на типы объектов. Я имел в виду не память а быстродействие.

Ну хорошо: :-)

отлючаем обсчет наземки посылая команду серверу с консоли игрока:
> ground = false

при инициализации таблицы:
Расстояние = 1000

при проверке расстояний до объектов
если (ground =false и СледОбъект.Ground = True)
тогда Расстояние = 1000
иначе Расстояние = ФункцРассчитатьРасстояние(МойОбъект,СледОбъект)

Надеюсь что объекты как-то поделены на типы :-)
аеропланы наземка бомбы и пр.

------------------------------

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

[grun]

2 =FPS=Plumb: ну хорошо , навскидку


player - это только player
объект - это всё включая player


массив_1:
объект_1, тип, Point_ху,h
...
объект_мах, тип, Point_ху,h



массив_2: (C - расстояние от объекта1 до объекта2 т.е. в каждой ячейке С=((h1-h2)^2+(x1-x2)^2+(y1-y2)^2)^1/2
-------- объект_1.....объект_мах
player_1, С11, .... С1max
...
player_max, Cmax1, .... Cmaxmax



массив_3 (признак видимости да/нет исходя из текущих настроек игроков)
-------- радиус объект_1.....объект_мах
player_1, ххх, (да/нет), ....
...
player_max ....


это не учитывая фильтра по типам, а также текущие "особенности реализации"

[timsz]

А откуда инфа, что идея сферы не реализована?

Другой вопрос, какой процент объектов при нормальной догфайтовой карте и нормальном мочилове окажется вне сферы?

[=FPS=Plumb]

А откуда инфа, что идея сферы не реализована?

Другой вопрос, какой процент объектов при нормальной догфайтовой карте и нормальном мочилове окажется вне сферы?

Из практики известно что до 20 игроков на сервере G1 обслуживаются отлично.
За 30 игроков - начинаются проблемы.
Убитый на другом конце - фиксируется в лог файле
Сброс парашютистов звеном Ли-2 вообще у всех все блокирует.

И чел использующий сферу отсечения не должен лезть в места где заведомо известно(через ТС) что имеется большое скопление самолетов.

Такие ограничения отлично подходят для проектов типа G1 и АДВ :
толпа полетела штурмовать филд/город на основном направлении.
А "калеки" с модемами заранее блокировали аэродромы на удалении 20-50 км от основной цели.
Охота опять же в районе вражеских АФ. Перехват одиночных бомберов и пр.

[grun]

массив1 скорее всего есть, массив2 думаю вряд ли..

отсечение на догфайтной маленькой карте получится имхо небольшое, хотя если даже треть то тоже ничего

[timsz]

Так ты предлагаешь всю он-лайн идеологию поменять? А игроков спросил? Тут уже не только техническая реализация и убогость. Дело политицское!

[=FPS=Plumb]

Ну вот: специалистов по России хватает (не только в ОМ грамотные люди).

Но надеюсь никто не будет оспаривать то что с 20 игроками на сервере модем клиента справляется без проблем а с 40 нет ?

Допустим что сетевой протокол в Ил-2 - "чудо инженерной мысли" и что его оптимизировать больше нельзя.

Отсюда простой логический вывод - сам протокол не трогаем , а кол-во передаваемых данных сокращаем за счет "лишних" с точки зрения конкретного игрока объектов/игроков.
Ну зачем в докфайте знать что в 50-100 км кому-то что-то отстрелили?

Именно тупое присутствие у каждого клиента всех игроков сервера и вызывает изумление.

Ведь ясный перец что инфы о 40 игроках больше (может быть нелинейно но больше) чем о 20!
Легко проверить - полетать на Г1 записав лог. Потом посмотреть лог с внешними видами и попереключатся на другие самоли - получится посмотреть на все .

Раз специалисты в ОМ до предоставления возможности отсечения заведомо неиспользуемой информации передаваемой по сети юзеру не дошли, то "что-то неладно в Датском королевстве".

А конкретно принятие постулата о том что "онлайн на модеме" умер и как следствие незачем голову греть