Видимо такое может быть если допустим один из клиентов молчал некоторое время, нат считает, что порт больше не используется и отдает другому.
Такое время "жизни" порта действительно задается, как правило оно около 2-3 минут, но... провайдер видимо может на свое усмотрение поставить. Вобщем, я сам особо в этом не разбирался, за что купил за то и отдаю )
На тему использования UDP играх есть классная cерия статей(англ): http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
Интересная статья. Спасибо. Теперь точно с UDP не слезу:-)
radiantor
при использовании TCP можно использовать сжатие пакетов...
делаем xor между предыдущим и текущим состоянием, то что получится жмем (а в результате будет очень много нулей так как состояния меняются редко). даже самые простые алгоритмы сильно снизят количество передаваемых данных, а ТСП будет гарантировать что клиент получил все...
может из этого можно получить больше выигрыша чем от быстрой доставки?
в УДП постоянно придется отправлять лишние данные, то есть стейт полностью, события подтверждать и тп + идентификация и куки...
забыл упомянуть о проблеме дробления пакетов, которую тоже прийдется решать, вводя что-то подобное механизмам ТСП...
Я делаю ФПС, поэтому сразу начал с UDP. Состояние игроков меняется постоянно, редко когда не меняется, по крайней мере положение и ориентация. Я только сомневался что UDP подойдет для интернета, а прочитав статью мне стало ясно что TCP точно не подходит.
Pushkoff
Не. TCP не вариант. Даже в локалке пинг зверский получается.
radiantor
> Состояние игроков меняется постоянно, редко когда не меняется, по крайней мере
> положение и ориентация.
оно меняется предсказуемо... особенно когда появится такое явление как инерция (а оно по любому появится)..
Pushkoff
То что меняется относительно редко помечается как static и передается по требованию(например если хэш статики не совпадает на клиенте и сервере).
Pushkoff
Инерция то она есть, но PhysiX... Его предсказать сложно, хотя наверное можно.
Оптимизация пакетов по любому нужна. Простое перемещение 2х игроков, уже 1к исходящих пакетов от сервера в секунду.
На UDP можно жать каждый пакет, хотя думаю там мало что сожмется :-)
Идея с XOR мне понравилась, можно же и на UDP её использовать, для передачи перемещений например, так как для них
потеря даже 30% не так критична. Например раз в секунду полный пакет, а остальное время только дельты.
radiantor, главное отпишись когда тесты проведешь, как получается, какие впечетления и т.д. :) было бы очень интересно.
з.ы. Вообще, чтобы сильно не завязывать игру на udp, мало ли что, для тестов хотябы просто типа чата пгонать, думаю сраз бы все прояснилось.
Народ. НИКТО не делает мультиплеер на TCP.
Серьезно. TCP используют для установки соединения, для чата, но вся динамика - UDP и только.
@!!ex
А-а-ткуда такое мнениие !!??? Я слежу софтинами как работают клиенты и у меня светится только TCP.
ksacvet777
Личный опыт + общение с коллегами из 1С и еще нескольких контор.
+ описание мультиплеера Source: http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking:ru
+всякая инфа которая попадалась по мере вникания в особенности создания МО
radiantor
> Идея с XOR мне понравилась, можно же и на UDP её использовать, для передачи
> перемещений например, так как для них
> потеря даже 30% не так критична. Например раз в секунду полный пакет, а
> остальное время только дельты.
вот тут ты и прозреешь от всех достоинств UDP... и наворотишь его до возможностей TCP...
radiantor
> Простое перемещение 2х игроков, уже 1к исходящих пакетов от сервера в секунду
откуда цифра?
у меня 20 пакетов по 256 байт в секунду...
Тема в архиве.