А зачем более интенсивный трафик то ? Ежли только там нужно пердавать большее количество данных. Да и Квака тоже пакеты в независимости от FPS шлет Думаю не больше 10 в секунду. Промежуточные координаты вычисляет на основе скорости и направления движения. Может кто скажет используются ли потоки в WB сервере или все делается в одном потоке ? Даже интересно стало
У меня был точно такой-же эффект и не раз, т.к. я модемщик. И это ничего не объясняет... Доподленно может быть известно только когда есть мониторинг пакетов.
Не зачем, а почему.... в кваке каждый чих идёт на сервер - будь-то движение, смена оружия, и стрельба. Там довольно навороченная система лаг-компенсации, и сервер корректирует положение игрока. Соответственно и трафик. А вообще я затевал этот топик, потомучто мне тоже интересно как WB сделан... но мне по большому счёту пофиг до транспорта и потоков... мне интересен "логический" протокол верхнего уровня - как организован обмен, кто его инициирует в зависимости от событий. Толи сервер безусловно шлёт пакеты, то ли это делается по инициативе клиента....
На мой взгляд шлет запросы клиент а отвечет ему сервер. Клиент посылает данные об игроке сервер шлет данные обо всех участниках игры.
2 PressLuftHammer. И еще про threads. Убился, но нигде не смог найти упоминание о цифре 18.2 переключений / сек = MAX для винды.... Ты уверен, что так и есть ? Первый раз слышу...
Именно с этой частотой работает виндовый таймер. Именно с такой периодичностью переключаются контексты. Можно конечно поглядеть поподробней вот только доберусь до книжек соответсвующих
18.2 раза в сек таймер часиков тикают, которые время считают. А процессорный таймер что задачи делит тикает намного сложнее.
Для случая с TCP в этом случае нужно тогда два порта. Для UDP сервер просто может непонять кому он должен и чего посылать. Насколько помню там адрес и порт отправителя узнается только при получении пакета функция recfrom. Хотя конечно можно извратится и запомнить адреса клиентов при подключении а далее просто рассылать по ним данные. Но при этом клиент должен все время ждать пакеты. И кстати я говорил вовсе не о подтверждениях. Например можно так 1.Клиент шлет свои координаты серверу. 2.Сервер получает координаты клиента изменяет их в своих данных и отсылает данные по всем участникам игры клиенту. Это возможно как по TCP так и по UDP только во встором случае без гарантии получения пакета.
Кстати вот есче вспомнил можно в одном потоке обслуживать несколько сокетов используя функцию select.
С какого перепугу? БТВ, птички, вроде, одним обходятся. Мы же о птичках говорим? Там только TCP. Ты говорил о запросах и ответах Так вот их и нет (в большинстве случаев, как минимум). А на деле так (афаик): Клиент шлет свои координаты на сервер, независимо от того, получает он что-то от сервера или нет. Сервер рассылает всем координаты остальных игроков (и пр. инфу), независимо от того, шлют ему что-то клиентские машины или нет.
Для TCP это не приемлимо. Представь себе когда клиент послал свои данные send а сервер шлет ему навстречу. TCP протокол с гарантированой доставкой данных. Т.е пока пакет неотправлен а следовательно не принят другой стороной выполнение приостанавливается до подтверждения приема данных другой стороной или ошибки. Т.е посылая друг другу данные одновременно обе стороны будут ждать бесконечно подтверждения от друг друга или истечения таймаутов.
Не выполнение приостанавливается, а передача. И то не всегда, после таймаута будут повторно послан пакет. И может быть послано сразу несколько пакетов без ожидания подтверждения.
Я не настолько хорошо разбираюсь в реализации TCP на нижнем уровне, чтобы уверенно говорить о том, что и как там происходит. Тем не менее: 1) Одновременных событий не бывает. 2) Если невозможно принимать и передавать в данные в одно и то же время, значит начало передачи с одной стороны блокирует передачу с другой. То, что во время передачи клиент сам не может ничего принимать, никому не мешает. 3) Запросы и подтверждения есть, но на нижнем уровне реализации протокола. Если тебе интересно, как это все происходит "внизу" - поищи в интернете статью "Протокол TCP" Семенов Ю.А. (ГНЦ ИТЭФ), например. К сожалению, адрес сайта я посеял
повторы и посылка без подтверждения это все на нижнем уровне. Обычно же в играх алгоритм передачи nagle отключается опцией NO_DELAY чтобы пакет отправлялся немедленно а не ждал заполнения буфера. Приостановка же идет именно в программе.
Обычные сокеты явлются блокирующими вызовами то есть до завершения отправки пакета выполнение программы приостанавливается и она переходит в состояние ожидания. Это совсем не нижний уровень. Т.е после send программа либо отправила пакет и он получен другой стороной либо неполучен и возвращен код ошибки. Именно по этому обычно открывают такие сокеты на сервере в отдельных потоках чтобы блокировка одного не вызывала блокировки другого.
Эээ... Ты, извиняюсь, из какого болота вылез??? Сокет может быть блокирующим, а может асинхронным (т.е. неблокирующим). В любом случае, это тоже не имеет никакого отношения к тому, один порт требуется или два. Ты бы все-таки РТФМ, прежде чем спорить-то, а?
Это ввинде есть неблокирующие сокеты работающие на сообщениях расширение WSA. Изначально же были только блокирующие сокеты.
