Войти
ПрограммированиеФорумСеть

UDP протокол для Интернета? (проблемы NAT) (4 стр)

Страницы: 13 4 5 619 Следующая »
#45
20:27, 22 фев. 2010

@!!ex
> Народ. НИКТО не делает мультиплеер на TCP.
> Серьезно. TCP используют для установки соединения, для чата, но вся динамика -
> UDP и только.
ложь, пиз*** и провокация!


#46
20:28, 22 фев. 2010

@!!ex
> Личный опыт + общение с коллегами из 1С и еще нескольких контор.
> + описание мультиплеера Source:
> http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:ru
> +всякая инфа которая попадалась по мере вникания в особенности создания МО
а ты не думал, что есть еще ММО? и это далеко не тоже самое, что сетевой шутер.

#47
20:31, 22 фев. 2010

Много форумов читал, и сделал для себя вывод: UDP для частых и мелких пакетов. TCP для редких (не чаще 1 раза в сек) и больших объемов.
А дальше уже по специфике проекта.
Damp
Ок. Отпишусь.

#48
20:33, 22 фев. 2010

Kloun
> ложь, пиз*** и провокация!
Аргументируйте.

Kloun
> а ты не думал, что есть еще ММО? и это далеко не тоже самое, что сетевой шутер.
В рамках этой дискуссии мы говорим о сетевом шутере, если вы не обратили внимание.
Это первое.
ММО(Во всяком случае крупные отечественные игроки, с которыми довелось общаться) в России делается также на UDP.

UPD: Вероятно шахматы с элементами РПГ вполне можно делать на TCP. Но это не тот тип игр, что мы здесь обсуждаем.
НЕТ НИ ОДНОЙ причины использовать TCP для передачи быстро меняющейся инфы.

#49
20:36, 22 фев. 2010

Pushkoff
> откуда цифра?
> у меня 20 пакетов по 256 байт в секунду...
Я имел ввиду только перемещение у меня. 6 байта заголовок, 3 координаты (по 4 байт) и 3 угла (по 4 байт).
И это все 20 раз в секунду, для каждого игрока.

#50
21:30, 22 фев. 2010

radiantor
у меня
11 байт полный стейт игрока * 2 + 1 байт идентификатора игрока * 2 + 1 байт идентификатор пакета + 2 байта размер = 27 байт
ответ 11 байт полный стейт игрока  + 1 байт идентификатора игрока + 1 байт идентификатор пакета + 2 байта размер = 15 байт
сервер посылает полное состояние мира (в данном случае это 2 игрока), когда количество объектов в мире увеличится, остро станет проблема в делении пакета на части, и контроль доставки частей... если 1 объект = 1 пакет, то увеличится количество посылок данных...
единственное преимущество УДП в моем случае, это широковещательный пакет и скорость доставки... но проблемы уже назревают... предсказание и интерполяцию придется делать все равно, так как уже на 4 клиентах не каждый девайз справляется...

#51
21:42, 22 фев. 2010

Pushkoff
У тебя ФПС на ТСР? Если да, то что с алгоритмом Найгла? Как влияет, или ты его вырубил?

#52
21:44, 22 фев. 2010

@!!ex
> МО(Во всяком случае крупные отечественные игроки, с которыми довелось общаться)
> в России делается также на UDP.
ну ну. вы ни похоже не пробывали что-то сделать....
удп - не надежный протокол. большая часть трафика в ММО - требует надежной доставки.
удп нужен только в случае когда архитекрура предусматривает частоую переодическую отправку данных, потеря которых значения не имеет.
если наши разработчики пишут ММО с использованием удп , либо они гуру, либо они идиоты. судя по тому, что наших 3д мморпг всего одна штука, и та на тсп, то сталобыть последнее утверждение (про идиотов) верно.

в зависимости от задач. например ММО шутер есть большой смысл писать на тсп. пинг в 50-100мс. побеждается на счет раз! и лагов не вызвает. (можно даже и до 200мс дотянуть)@!!ex
> МО(Во всяком случае крупные отечественные игроки, с которыми довелось общаться)
> в России делается также на UDP.
ну ну. вы ни похоже не пробывали что-то сделать....
удп - не надежный протокол. большая часть трафика в ММО - требует надежной доставки.
удп нужен только в случае когда архитекрура предусматривает частоую переодическую отправку данных, потеря которых значения не имеет.
если наши разработчики пишут ММО с использованием удп , либо они гуру, либо они идиоты. судя по тому, что наших 3д мморпг всего одна штука, и та на тсп, то сталобыть последнее утверждение (про идиотов) верно.

в зависимости от задач. например ММО шутер есть большой смысл писать на тсп. пинг в 50-100мс. побеждается на счет раз! и лагов не вызвает. (можно даже и до 200мс дотянуть)

#53
21:51, 22 фев. 2010

Kloun
> ну ну. вы ни похоже не пробывали что-то сделать....
А вы пробовали? Пруфлинк, если не сложно.

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

Я не люблю столь категоричных утверждений не подтвержденных фактами. Посему либо вы объясняете чем TCP лучше UDP и мы продолжаем адекватный спор, либо наша с вами дискуссия закончена.
ИМХО мат и переходы на личности в нормально общении - слегка лишние вещи, так что будьте сдержаннее.

#54
21:53, 22 фев. 2010

radiantor
на УДП...

#55
22:07, 22 фев. 2010

Какие задачи решает TCP?
Это гарантированная доставка и "склеивание" пакетов.
Что из этого актуально для ММО?
Склеивание сразу отметаем, потому что размер пакетов редко превышает 200 байт, а значит пакеты просто не разбиваются на части.
Гарантированность  - актуально для чата и для первоначального коннекта.
Для "кадра"(frame) - не актуальна. Потому что в случае НЕ доставки пакеты он через несколько секунд отправится повторно, но за несколько секунд ситуация в мире изменится и данные как не актуальные будут принимающей стороной отброшены без обработки.

UDP?
Нет гарантированности. Что же делать?
Данные делятся на три типа:
Динамика(обновляется каждый фрейм)
Статика(обновляется редко)
userData(вообще не обновляется, либо обновляется ооочень редко)

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

TCP используется только для чата, логина и действий в меню. В игровом мире только для чата. Все остальные случае удобнее и проще разруливать на уровне UDP.

#56
22:27, 22 фев. 2010

@!!ex
я уже писал... можно реально сэкономить на количестве данных... использовать не тупое сжатие, а знание того что есть на клиенте...
случай...
бот бежит вперед
отправляем направление, и через 10 секунд можем отправить ему смену направления... а все 10 секунд на сервере мы будем эмулировать клиент, и если данные клиента расходятся с текущей ситуацией на сервере - досылаем синхронизацию... в итоге в лучшем случае 2 пакета за 10 секунд, в худшем 10...
у тебя в любом случае 200 (20 синхронизаций * 10 секунд)...

#57
22:31, 22 фев. 2010

Pushkoff
Почему 20?
Никто не заставляет для всех объектов делать фиксированное количество фреймов в секунду.

UPD:
Можешь представить себе ситуацию, когда данные не меняются 10 секунд в экшене?
В РПГ вполне реально, согласен. Но там и погрешность можно существенно большую допустить.

#58
22:31, 22 фев. 2010

Без криков!

Я совсем недавно бился с сетью для танчиков. Игра на 8 игроков. до 4000 динамических объектов на карте. Все двигается быстро и постоянно меняется. Передаются по сети только нажатия клавишь, снимков мира или любых других синхронизаций нет ниразу за весь игровой сеанс.

Сперва пробовал все сделать на UDP. Но Безсильно уперся в проблему отправки ответных UDP пакетов игроку за NAT. Внешний IP есть лишь у каждого 10.

Сейчас все на TCP, но этим я не доволен, т.к. задержки бывают до 2 секунд. При пинге 100-200.

#59
22:40, 22 фев. 2010

Megabyte-Ceercop
> Сперва пробовал все сделать на UDP. Но Безсильно уперся в проблему отправки
> ответных UDP пакетов игроку за NAT. Внешний IP есть лишь у каждого 10.
Что за странные проблемы? NAT прекрасно пробивается... или делается P2P соединение?

Страницы: 13 4 5 619 Следующая »
ПрограммированиеФорумСеть

Тема в архиве.