Ну не такое уж и древнее придание. Я, например, очень хорошо помню примевал, на котором я играл под ником TheSleepyOne, и твой вопрос, когда ты узнал что это я: "Почему без тэга? Из эры выгнали?". Помню я и нашу с ДеСПом реакцию =))
БТВ, ты и сейчас в онсе появляешься, пока ждёшь ассаулта.
2 Гудвин:
А чё там открывать? Старый знакомый, некогда известный как PG.BackBreaker.
это не "х.з что" -- а мега значОк -- который заменяет любой необходимый знак препинания)))) (однако может быть вставлен и просто так -- для отделения одной мысли (возможно скрытой:D) от другой)
короче как хочу так и пишу,писал и буду писать)))))))))
да уж расфлудили где модеры интересно)))))Кстати никто не подскажет когда играть бум на мегакрасивых картах а не только на стандартных?и мутаторы бы добавили!балистик например или деазболл поиграть!а то пару серверов да при этом с лимитом на людей что вечером в очередь встаешь)))
У меня имеется стойкое ощущение, что на PG:7877 появились задержки с реакцией на действия, т.е. по смыслу - увеличение пинга, но при этом, судя по приборам, с ним всё нормально
Эффект отлавливается на шоке и существенном лаге при ведении AVRiL'а по правой кнопке
Может кто-нибудь подтвердить/опровергнуть/исправить ?
Это лаги, господа, и ни что иное.
Навскидку вспоминается ещё один термин - «invisible packetloss» - невидимый пакетлосс, когда "по приборам" все ОК, но пакетлосс, в натуре, заипал.
"Благодарим" за всё Quake4 - именно после выхода последнего испортились буквально все серваки, которые я знаю - железо-то не п*зды не тянет, а жаба-то жадная у прова и она его душит...
ппц окуел совсем чтоли? по ку4 на пг щас вообще ОДИН серв! вместо того, что раньше их было 3 + 1 приватный ут! а в данный момент и тот 28004 в дауне
ты на ку не гони, умняша епт нашелся >8[ на свой онскрап смотрите плять
канеш,пришли ведь нупы из других игр в ут ради режима онс,расшевелили тихое болото "элиты" анрила,ведь так здорово было-три калеки-две чумы играют себе спокойно упиваясь своей крутизной при пинге 8-12,а щас что? ай я умираю и попасть ни магу-у миня лаги при пинге 30-50,а фсе вы со своими машинками:) а эпики ваще чудаки на букву М-нах они режим придумали такой ?,вся европа играет онс-нупы,что с них взять...лезет на единственный ас-онс сервак народ-вот ведь нигадяи-играть не дают нормально
Z-SYN-ACK
Хороший вопрос. Эта проблема схожая с той, что по ADSL и по LAN в клубе примерно одинаковый пинг, однако разница на лицо. Чисто моя версия:
Все знают что анрил работает на UDP протоколе. Так же известно что при передаче данных в ротоколе UT идёт разбивка на каналы. Каждый канал несёт в себе те или иные данные. Однако размер одних данных в канале может превышать размер других данных. Чисто ради примера возмём 32 байта и 8 байт. По любому интернет-каналу пройдёт быстрее 8 байт, а не 32. Кроме того, аппаратная часть интернет канала (например ДСЛ модема) предусматривает корректировку ошибок за щёт контрольной суммы. Сл-но данне по какой то причине могут задержаться в буфере передатчика, по причине неполучения их приёмником. Данные будут запрошены из за несовпадения контрольной суммы, и переданы сново. Любой интернет канал подразумевает аппаратный контроль данных (контроль оборудованием) а так же програмный контроль - пример TCP/ip протокол. Всегда вероятность потери большего колличества данных больше, чем вероятность потери меньшего. Сл-но, если ориентироваться на моём примере, задержка 32 байт по всевозможным причинам составляет большую вероятность , чем у 8 байт. Компьютер выполняет алгоритм так же как и протокол передачи данных, поэтому в любом случае данные, большие по величине, будут проходить по каналу дольше. Итак, в UT протоколе идёт разбивка по каналам связи, распределение ресурсов линии (ширина канала, выхода в интернет) между каналами управляется алгоритмом. UT так же контролирует величину минимального колличества данных контрольной суммой, в случае если данные не дошли целиком, то идёт перезапрос , и данные посылаются ещо раз. В случае перезапроса данных сервер и подсчитывает PL. Но это ещо не всё. Так как ресурсы распредиляются между каналами связи UT сокетов однородно, то сл-но те же 32 байта по одному каналу A пройдут быстрее, чем 8 байт по каналу B. Предположим, что 32 байта (A) - это информация о выстреле (хотя на самом деле эта информация гораздо более меньшая) а 8 байт (B) - это эхо пинга к серверу.
A->1 байт ->B-1 байт->A->1 байт B->1 байтA->1 байт ->B-1 байт->A->1 байт B->1 байт .....
уже из вышепреведённой строки видно, что 8 байт (B) пинга передались, а 32 байта (A) ещо будут передаваться ...
Казалось бы, что пинг и игровая информация должны уменьшаться или нарастать пропорционально (в зависимости от пинга на канале), но это не так по той простой причине, что есть ещо такой фактор как ширина канала а так же процент аппаратных потерь на несколько единиц. Допустим на канале 1 и на канале 2 одинаковый пинг на 32 байта. Но канал 2 шире в два раза первого. В этом случае по каналу 2 за 1 такт с тем же пингом можно передать в два раза больше данных, и в случае если набор данных, которые нужно передать за такт не превышают максимально возможную передачу данных за такт на канале - информации о пинге, показанной в UT можно доверять. В ином случае вы будите получать ложную информацию о пинге, то есть эхо пинга пройдёт гораздо быстрее, чем информация о выстриле на сервер.
Ну вот впринципе и всё, это именно то что касается вопроса почему там так, а вон там иначе.
Вывод прост - чем шире канал, тем стабильнее и чётче будут давать показания приборы, а так же не стоит забывать про аппаратную задержку данных.
Есть соображение, что packet loss детектируется как то, что пакеты имеют внутренний идентефикатор, и, если ожидался пакет с номером 12345, т.к. до него был 12344, а пришел 12348, то значит два пакета - того - проипались
Разница между LAN и ADSL может быть из-за неравномерности пинга на ADSL
В итоге получилась не версия, а сумбурный набор не совсем верных познаний в области телекоммуникаций
Как выглядела нехватка канала - всем известно - на AS-JunkYard у всех подскакивал пинг до 200 и был страшный пакетлосс
Такого не сейчас происходит - значит с каналом всё ок (УРА !)
Значит информация о событиях доходит за то самое время, которое показывают приборы (ping)
Лаг же происходит на обработке игровых событий, что не может быть оценено при помощи ping'а или p/l'а
Вывод - чё-то туда еще водрузили ресурсожрущее
p.s. интересно, есть ли инструменты для обеспечения QOS на уровне CPU, HDD ? ;)
Z-SYN-ACK
Насчёт распознавания PL я согласен, но не так что пакет с номером 12345, а то что у пакета была контрольная сумма, но она на совпала при расшифровке. Тем более, что скорее все перезапросы есть, просто не N колличество раз , а в зависимости от того как это там сделали разрабы (это можно увидеть на конкретном примере)
//Разница между LAN и ADSL может быть из-за неравномерности пинга на ADSL//
Да пинг то равномерный, а вот разница в технологии их различает. Чем больше физика у DSL тем больше можно уложить данных за то же время, и сл-но тем круче играется.
А вот касательно ПГ - так там может быть несколько вариантов, и замечу что нагрузка на CPU не самый распространённый. Хотя списокпроблем ==
0->Что то жрёт CPU
1->Сузили канал
2->Изменился ротинг до сервера не в лучшую сторону
"да уж расфлудили где модеры интересно)))))Кстати никто не подскажет когда играть бум на мегакрасивых картах а не только на стандартных?и мутаторы бы добавили!балистик например или деазболл поиграть!а то пару серверов да при этом с лимитом на людей что вечером в очередь встаешь)))"
Лагать может
1. Железо сервера (не хвататет моши проца или памяти) - весьма вероятная гипотеза особено насчет ОНС - жрет ресурсов много
2. Канал - насчет канала все сложней - может нехватать канала как у сервера (что маловероятно у народ с ПГ все ок всегда да 100мбит хватает для мнгого), так и канала наружу - на нем сидит много чего и есть вероятность, что он лагает.
3.о пинге и трасерте:
3а. когда вы даете команду пинг вы пингуете tcp пакетами, а анирал юзает датаграммы udp:) К этому могу добавить, что зафиксированные случаи когда п/л наблюдался толко для датакграмм udp а тсп все было ок.
3б. когда вы даете команду трасерт или трасероут вам показывает путь туда!!! и только туда! Как идет трафик обратно вам не показывают! (Иллюстирую - у меня до шведского сервера ЕРА пинг 90 хотя до Швеции пинг 40. сделав трасерт с сервера я с удивлением увидел что обратно мой трафик идет через UK)
4. О пакетах - UT юзает передачу пакетами по 64 байта. Данные передаются по нескольким каналам. Пинг проверят надо пакетами по 512 (но в силу 3а это будет пинг и п\л для тсп)
"что зафиксированные случаи когда п/л наблюдался толко для датакграмм udp а тсп все было ок."
>а это уже из за приоритетов у прова, при номральном раскладе такого быть не должно.
"3б. когда вы даете команду трасерт или трасероут вам показывает путь туда!!! и только туда! Как идет трафик обратно вам не показывают!"
>ясное дело что для UDP маршруты "туда" и "сюда" будут отличаться, хотя у TCP когда вы клиент маршрут постоянен.
"Иллюстирую - у меня до шведского сервера ЕРА пинг 90 хотя до Швеции пинг 40. сделав трасерт с сервера я с удивлением увидел что обратно мой трафик идет через UK"
>Ничего удивительного, из Питера в москву дело абстрактно так же обстоит.
1. Зависит от приоритетов на роутерах между клиентом и сервером
2. для тсп таже фигня что и для удп - туда и обратно трафик может идти разными каналами (сильно разными)
3. то что трафик идет разными путями признак экономии на клиенте!
мазай, фигли доипался к q4 ?
ку4 сейчас второй день лежит, до этого неделю валялся, он мож вообще на другой тачке живет, но всё равно зло, угу :D :D
Да и любому ясно, что дуэльник ку4, на который очень редко кто-то заходит (99% народу играют не на пг), жрет гораздо меньше ресурсов, чем твой анрыл с аншлагом в дм, онс-ас да еще тдм в придачу :/
Internet Control Message Protocol (ICMP), documented in RFC 792, is a required protocol tightly integrated with IP. ICMP messages, delivered in IP packets, are used for out-of-band messages related to network operation or mis-operation. Of course, since ICMP uses IP, ICMP packet delivery is unreliable, so hosts can't count on receiving ICMP packets for any network problem. Some of ICMP's functions are to:
* Announce network errors, such as a host or entire portion of the network being unreachable, due to some type of failure. A TCP or UDP packet directed at a port number with no receiver attached is also reported via ICMP.
* Announce network congestion. When a router begins buffering too many packets, due to an inability to transmit them as fast as they are being received, it will generate ICMP Source Quench messages. Directed at the sender, these messages should cause the rate of packet transmission to be slowed. Of course, generating too many Source Quench messages would cause even more network congestion, so they are used sparingly.
* Assist Troubleshooting. ICMP supports an Echo function, which just sends a packet on a round--trip between two hosts. Ping, a common network management tool, is based on this feature. Ping will transmit a series of packets, measuring average round--trip times and computing loss percentages.
* Announce Timeouts. If an IP packet's TTL field drops to zero, the router discarding the packet will often generate an ICMP packet announcing this fact. TraceRoute is a tool which maps network routes by sending packets with small TTL values and watching the ICMP timeout announcements.
Да не, в принципе я уже смирился.
Просто если и раньше в интернете было несладко, то после выхода Ку4 на некоторых серверах вообще играть стало невозможно, например на Джолте-ЦТФ...
Допускаю, что Ку4 и на ПГ может воду мутить.
Ну а т.к. выхода из этого никакого, будем ждать, когда серверов Ку4 будет не один, а несколько, плюс хотя бы парочка УТ2007, плюс несколько КС-Соурс, и все это хозяйство на говняненьком стареньком железе, которое уже сегодня ни п*зды не тянет...
да на пг список серверов вообще внушает некое недоверие...
ну к примеру мож я невовремя смарю, но сириос сэм второй пустует вечно... тим спик - я вооще хз что таоке... тож любопытно посмареть на бюргеров, играющих в мультик ф.и.е.р. ... ту оказывается и ку4 пустует...
ERA|Tomcat
Udp соединения состоит из клиента и сервера у каждого.
А TCP соединение состоит из сервера и клиента.
В лучае NAT Клиент выходит через сервер, и при TCP пакеты идут туда и обратно по одинаковому пути.
А UDP клиент может выходить через NAT, а к вашему UDP серверу будут коннектится через иной NAT-маршрут.
И если подумаете своими мозгами, то поймёте что для пинга существуют низкоуровневые протоколы, ICMP эхо работает через TCP/IP главный протокол, а не через TCP подпротокол.
________________________________________________
Опять базар, но на сервере играется от этого не легче
Остается понять как ICMP работает через TCP/IP, где TCP - самый главный ;)
Ну и, естественно, почему пакеты водят хороводы через "NAT-сервер" равноэквивалентным образом
А заодно нарисовать НИЗКОУРОВНЕВЫЙ пинг
Ну а про то, что для TCP сервера может и не быть я сам узнал не так давно, тем более что актуально только для WinXP SP2 и выше (про *nix не возьмусь судить)
p.s. "NAT-маршрут" - это 5 баллов !
p.s.s. Мои уши окончательно завяли
P/L только на UDP может быть из-за QoS-настроек роутеров посередине, с шибко загруженным каналом, считающих соответственно UDP-траффик менее приоритетным и, пре перегрузке, отбрасывающих его
Z-SYN-ACK
вобщето, что бы ты знал, любой компьютер в сети интернет выходит в этот интернет через NAT. В свою очередь, компьютер, через которого выходит ваш тоже выходит через NAT другого компьютера. Так и получшается маршут по NAT-ам.
А имеете вы IP в интернете, потому что конечная точка в интернете совршит N переходов и достигнет NAT-сервера, который будет смотерть в вашу подсеть.
На самом деле NAT-это просто напросто роутинг, другими словами.
В слушчае, если тебе смешно, то это говорит о незнании работы инета всего мира, и данная вещ не может быть оскорблена флудом, по тому как это не бирюльки.
А насчёт выражений, ну да, есть немного, прокочит иногда, если не понятно - то может и +5, а вот если сечёшь , о чём я, то и нормально.
Z-SYN-ACK
P/L только на UDP может быть из-за QoS-настроек роутеров посередине, с шибко загруженным каналом, считающих соответственно UDP-траффик менее приоритетным и, пре перегрузке, отбрасывающих его
______________________________________________________
я это уже писал, причём полностью согласен с этим.
Остается понять //как ICMP работает через TCP/IP, где TCP - самый главный// ;)
Ну и, естественно, почему пакеты водят //хороводы через "NAT-сервер" равноэквивалентным// образом
А заодно нарисовать НИЗКОУРОВНЕВЫЙ пинг
Ну а про то, //что для TCP сервера может и не быть я сам узнал не так давно//, тем более что актуально только для WinXP SP2 и выше (про *nix не возьмусь судить)
__________________________________________
0->TCP/IP интернет протокол, ICMP,UDP,TCP работают за щот него
1->Ну смотри, когда где то в интернете сервер TCP на 80 порту, то: по роутерам до пунта пройдёт пакет, затем пакет пройдёт обратно по тому же пути, по тому что тут получается как бы пирамида (ээх, не умею я обьяснять!)
Или, в пример - тебе достаточно поставить дома NAT , и поставить 80 машин - все они будут выходить через твой роутер, причём у них существует возможность принять пакет только через NAT. Поэтому, пути когда ты клиент какого то сервера одинаковые.
2->Да , может! вместо TCP сервера сидит хакер и эмулирует сервер, что бы получить данные :D
Ну вот зачем вам все это нужно? Я понимаю еще Тома,компутерщик+аренда-выбор серверов,настройка итд,а вам то нах? Изложите свои соображения Другиту?)-угуг,бубенчики не забудьте нацепить.
Просто кошмар. Народ вы хоть немного сети знаете?
NAT это NAT, а роутер это роутер и это разные вещи и вовсе они не обязаны быть сервером. И вовсе не все компы соеденены через NAT.
TCP/IP это не протокол как таковой. IP и TCP это протоколы разного уровня. И что TCP что UDP и даже ICMP все бегают по протоколу IP.
На TCP не бывает ПЛ по определению, потому как это протокол с гарантированной доставкой пакетов. На нем соединение или есть или его нет. По этому протоколу какраз должно быть подтверждение приема пакета или его перезапрос.
А вот UDP это протокол без гарантии доставки пакетов, и поэтому на нем возможен ПЛ. Попросту говоря сервер выпуливает пакеты в сеть, а дошли они или нет никого не волнует. (ну кроме самого игрока :) При этом пакеты которые задержались и пришли позже тоже считаются потерянными для УТ.
З.Ы. Можно и еще просвящением заняться, но это надолго, читайте литературу.
PG.BumBarash
Ну блин, ты сначала разберись в том, что я писал.
Я писал не о том, что роутер-это нат.
Я писал о том, что интернет построин на NAT и без него он существовать не может.
В сети сетевые карты видят друг друга на прямую, а в инете совсем дургое дело.
Роутер - это устройство, а РОУТИНГ - это приём данных, возможна их обработка и посылка далее.
Роутер , как устройство - может просто контролировать потоки данных от одной сетевой карты к другой, а может служить как NAT (а NAT это в свою очередь уже роутинг).
Вот такое чувство, что после того как все зачитываются книгами начинают всё сравнивать с тем что в книге, понимать буквально, всё там перебирать где что какие неровности.
Сразу какие то книги начинают советовать, хотя представления не имеете сколкьо книг перечитано.
Каждый так же считает своим долгом зайти, и перевернуть сказанное вверх ногами и прокоментировать.
Важно как работает, а не то как протокол называется, хоть он называется вася-пупкин.
PG.BumBarash
//Просто кошмар. Народ вы хоть немного сети знаете?//
NAT это NAT, а роутер это роутер и это разные вещи и вовсе они не обязаны быть сервером. //И вовсе не все компы соеденены через NAT.//
_________________________________________________
Где я написал, что все компы связаны через NAT?
Где было вобще написано что NAT является роутером?
Где написано, что Router это сервер?
С чего ты взял что кто то сдесь думает что все компы связаны через NAT?
Незнаю, но может не все знают что такое NAT ? Или может не так его себе представляют? Это ж надо так посты перековеркать...
"А вот UDP это протокол без гарантии доставки пакетов, и поэтому на нем возможен ПЛ. Попросту говоря сервер выпуливает пакеты в сеть, а дошли они или нет никого не волнует. (ну кроме самого игрока :) При этом пакеты которые задержались и пришли позже тоже считаются потерянными для УТ."
Да это всё элементарно, ни кто не обсуждал вобще как работает UDP
Обсуждалась обработка игрой, а не то что ты расписал.
dvion_
одну книгу тебе точно стоит прочитать-
Психология. Саморегуляция психологического здоровья: Практическое руководство
"Эта книга для всех, кто хочет сохранить и укрепить собственное психическое здоровье. Вы найдете в ней ответы на многие жизненно важные вопросы и овладеете особой технологией, позволяющей: улучшить свое самочувствие, научившись вырабатывать иммунитет против скуки, тревоги, одиночества и других гнетущих состояний; обрести чувство вдохновения, благополучия и оптимизма; преодолеть стрессы, депрессии, кризисы жизни; извлечь пользу из потерь и вовремя освободиться от болезненных переживаний; в любой ситуации получать доступ к состоянию уверенности и спокойствия."
Автор книги Панкратов В.Н.
Издатель Институт Психотерапии
> 1->Ну смотри, когда где то в интернете сервер TCP на 80 порту, то: по роутерам до пунта пройдёт пакет,
> затем пакет пройдёт обратно по тому же пути, по тому что тут получается как бы пирамида (ээх, не умею
> я обьяснять!)
Глупый вопрос можно ?
Откуда имеется железобетонная уверенность, что ответный пакет на подтверждение соединения пойдет по тому же маршруту ?
> 2->Да , может! вместо TCP сервера сидит хакер и эмулирует сервер, что бы получить данные :D
Речь шла о некоторых расширенных возможностях TCP
А вот т.н. "хакеру" для получения данных эмулировать сервер не требуется, если это, конечно не фишинг или атака через подмену DNS
Равно как ему не нужно делать такого для перехвата данных по открытому протоколу типа POP3, ICQ, HTTP
Единственный случай внедрения по середине (Man in the Middle) актуален лишь для протоколов типа SSH или HTTPS, если обмен ключами шифрования не был уже произведен, да и то там наверняка всплывет момент с проверкой сертификатов
Итого:
1) Пытаться блестать отсутствием знаний в области сетевых технологий - неразумно
2) Проблема лагов на PG, как мне кажется, лежит не в области коммуникаций
3) Читайте книжки
else
4) "Хакер"
Z-SYN-ACK
//Пытаться блестать отсутствием знаний в области сетевых технологий - неразумно//
Так что тогда блистаешь?
______________________
Во первых серьёзные люди никогда не читают несерьёзные хакеры и так далее.
Во вторых после прочтения таковых хакерами как правило не становятся.
Пока что то что тобою сказано либо:
a->не относится к этой теме
b->полная лажа
c->верно, но элементарно
d->оскорбление при незнании
___________________________
что касается того обстоятельства, когда ты клиент - то пакеты будут идти по одному пути туда и обратно, по лесенке одного и того же роутинга. если тебе не дано это осилить подумав своими мозгами - то это клиника. тут думать то особо и ненадо.
роутинг будет отличаться в трасерте тобою сервера A от трасерта тебя с сервера A
А когда ты клиент, то ты подключаешься с помощу своего рода N "зеркал" до конечной точки, по этим же зеркалам следует и ответный пакет.
p.s. роутеры сессиями не занимаются. у них вообще говоря памяти-то по сути дела почти что нет
dvion'у долго думать про то, как работает спутниковый интырнет с принемающей тарелкой и модемом для отсылки запросов ;)
>Где я написал, что все компы связаны через NAT?
>С чего ты взял что кто то сдесь думает что все компы связаны через NAT?
----------------------
dvion_
06.06.06 10:20 Z-SYN-ACK
вобщето, что бы ты знал, любой компьютер в сети интернет выходит в этот интернет через NAT. В свою очередь, компьютер, через которого выходит ваш тоже выходит через NAT другого компьютера. Так и получшается маршут по NAT-ам.
----------------------
Вот тут совершенно ясно об этом сказано.
Но когда появился интернет NAT'ов небыло и в помине. NAT был придуман когда стало не хватать реальных адресов. Ты наверное удивишся но есть очень много компов которые подключены к инету на прямую и имеют реальные адреса.
>Где было вобще написано что NAT является роутером?
----------------------
dvion_
06.06.06 10:20
На самом деле NAT-это просто напросто роутинг, другими словами.
----------------------
Роутинг это то что ты расписал, а вот NAT это подмена адресов и ничего больше. Обычно подменяется внутри сетевой адрес на реальный адрес интернета.
>а к вашему UDP серверу будут коннектится через иной NAT-маршрут
А это вобче бред. Есть просто маршрут, и никаких "NAT-маршрут"ов.
Еще нужны цитаты из которых видно что у тебя что-то есть в голове и даже многие вещи правильные, только они перемешаны в кашу.
>В слушчае, если тебе смешно, то это говорит о незнании работы инета всего мира, и данная вещ не может быть оскорблена флудом, по тому как это не бирюльки.
Едет чел в транспорте. Срать хочется. Что делать? Сосед ему говорит:
- А ты внуши себе, что не хочеш.
Едет чел дальше внушает себе:
- Я срать не хочу!
- Я срать не хочу!
- Я срать не хочу!
- Я не обосрался!
А я понял, откуда у него взялся термин "NAT-роутинг"
Он просто за свою жизнь не видел никогда нормального маршрутизатора, типа Cisco, а видел лишь NAT
Отсюда "пирамидки" заменяют таблицы маршрутизации на пару с метриками
p.s. Блин, как же я рад ! Мои AVRiL'ы снова стали смертельно опасны для Мант ;)
PG.BumBarash
всё ясно, ты наверное скажешь что сетевая карта может видеть 255 в четвёртой степени, обрабатывать запросы от каждого адреса, так? ты наверное хотел сказать, что нат был придуман как только 255.0.0.0 С-уровень заполнился. Не знаю, что там было в той книге, которую ты читал, но что то нездоровое вы толкаете. Вас озаботило слово НАТ, якобы это токо для офиса придумано. Ты смотришь к америкосам в одно окошко, а они к тебе через другое...
такие разборки по поводу пинга к серверу, пинга с сервера. А вы не забываете что сервер-то не моментально отвечает? Вот есть у нас сервер который имеет тикрэйт 35, т.е. принимаются сигналы от клиентов, ситуация обрабатывается, инфа о текущей ситуации на сервер отсылается к клиентам, и делается это 35 раз в секунду. А теперь самое интересное: сколько у нас миллисекунд проходит между тиками? 1000/35 = ~28.5. То есть пинг в самой игре будет колебаться от "пинг туда + пинг оттуда" до "пинг туда + пинг оттуда + время между тиками", в зависимости от того, когда был послан сигнла к серверу.
Собсно как поживает он?также лагает как и в старинные времена?не ожидается какихнить серверов под редоркестру фрагопс балистик и прочее?