DirectPlay и прокси(NAT) (3 стр)

Booster
> Не может этого быть, он наверняка затачивался для работы за натом.
четыре дня назад я тоже был уверен в этом.

По моему DP это идеологическая война MS против *nix сетевых стандартов. Последние победили.
прочитал в MSDN что DP будет работать через NAT, только если в качечтве прокси для клиента используется WinServer2003. Но такие встречаются редко.

сами MS настаивают чтобы DP не использовали при разработке игр. Для меня этого достаточно, чтобы прекратить разговоры о нем.

Megabyte-Ceercop
>сами MS настаивают чтобы DP не использовали при разработке игр. Для меня этого достаточно, чтобы прекратить разговоры >о нем.
А ссыль не подскажешь?

просто заходим на страницу документации:
http://msdn.microsoft.com/en-us/library/bb318767(VS.85).aspx

Megabyte-Ceercop
Спасибо, понятно, слив майкрософт.

>главное скорость получения данных.
Такое ощущение, что у тебя террабайты трафика гулять будут ))))
ТЦП совершенно без проблем шлёт как минимум сотни килобайт (а на самом деле намного-намного больше) в секунду без малейших (видимых на глаз т.е.) задержек. Килобайты он шлёт безпроблемно даже по ГПРС, в твоём случае нужны всего лишь от силы десятки байт...

>А UDP не ждет подтверждений пакета, которые требуют тогоже времени что и доставка самого пакета.
Ну, если критично будет ли пакет идти 5 мсек или 10 мсек - конечно да... Но критично ли? Особенно, учитывая, что можно слать данные вслучае если они не дошли, не надо писать кучу кода проверок и т.д. 8-)

Я сам пытался , в своё время замутить тему с УДП и умные люди убеждали меня в том, что оно мне не надо... Пока сам не понял что и в самом деле не надо - не верил им ))) Учитывая, что при этом ещё и код стал меньше в десятки раз (и, соответственно, его проще поддерживать, модифицировать, ловить ошибки и т.д.) - я более, чем доволен 8-)

tcp же не каждый пакет ждёт. Отправили мы мегабайт, драйвер разбил на несколько пакетов, сразу отправил и ждёт подтверждений. Посмотрите как работает торрент, в зависимости от размера файла меняется размер отправляемых блоков. А также идёт отправка в несколько потоков.

slava_mib
пакет от клиента хосту (без учета заголовков) у меня равен 36 байт. Обратный пакет 36*(количество игроков-1); 250 - 500 байт.

трафик не большой. но 1 секунда для динамичной раелтайм игры это вечность. По определению TCP не шлет продолжения данных пока не подтвердится доставка предыдущей порции, а это как минимум двойная задержка. по интернету пинг в среднем 100-200 мс. для p2p соединений, в пределах страны, поэтому мне критично будет доставка 50 или 100 мс. Это скажется не реакции танка на действия игрока.

Гарантированная доставка нужна будет очень редко (присоединение к игре, чат, отсоединение от игры). Остальные игровые пакеты все одного типа и их потеря не вызовет ошибки. Гараннтированные пакеты не будут высылаться пока на предыдущий гарантированный пакет не придет подтверждение доставки. Это очень прозрачно и логично. TCP на такой задумке не понадобится. Если уж появится гемор, попробую TCP. : )

Ты не забудь нам сообщить когда плюнешь на UDP :)

>трафик не большой. но 1 секунда для динамичной раелтайм игры это вечность.
у меня по ГПРС пинг в 6 раз меньше ))))

>По определению TCP не шлет продолжения данных пока не подтвердится доставка предыдущей порции, а это как минимум двойная задержка
Она обычно не критична.

>по интернету пинг в среднем 100-200 мс. для p2p соединений, в пределах страны, поэтому мне критично будет доставка 50 или 100 мс.
У меня вот при 100+ соединений, обменом пакетов порядка 10 раз/сек и среднем размере пакета около 50+ байт (а иногда в разы больше) не видно ни малейших лагов.... почему? да потому что обычно люди такие проблемы решают алгоритмами предсказания и лаго-компенсации, а вовсе не бесконечным увеличением скорости потока между клиентами ))))

ну и, как я уже много раз сказал - на тцп сделать быстрее. если бы ты делал на тцп - мы бы сейчас обсуждали работающую дему и то, какие мелкие правки надо в неё внести. а вместо этого мы сейчас обсуждаем как бы это сделать на ЦДП с учётом всех его клюков.

Ну разве тебя не учили решать любую задачу от простого к сложному? Разве не понятно, что так удобнее? Переделать ТПЦ на УДП всегда можно просто усложнив код. А вот поняв, что УДП нифига не работает, проще не переделывать на ТПЦ - проще выкинуть код и сделать заново.

Посмотри на задачу с другой стороны - ты можешь сделать на ТПЦ за день, если тебе не понравится -ты просто переделаешь (или даже просто выкинешь) код, один день не жалко. Но есть вероятность, что ты ЗА ОДИН ДЕНЬ решишьпроблему. С другой стороны, ты занимаешься УДП, который писать дольше, он менее удобен, менее поддерживаем (с точки зрения кода) и при этом писатьего по меньшей мере в разы дольше (хотя бы судя по тому, что уже не первый день сидишь). Так что проще - потратить день и, возможно, выкинуть эту работу или потратить неделю ( месяц? ) и так же, вполне вероятно, выкинуть эту работу?

>Ты не забудь нам сообщить когда плюнешь на UDP :)
Угу, поддерживаю.

З.Ы. Из спора выпал, ибо если не поможет - смысла не вижу 8-)

Megabyte-Ceercop
Нет же, есть окно пакетов которое ожидается. Последовательно каждый пакет не ожидается.

TCP очень полезен, избавляет от гемора с важными сообщениями.
Но и UDP нужен, быстро доставляет пакеты и позволит сделать общение all to all
Возможно что так будет работать еще быстрее : )

Уже делаю два коннекта UDP и TCP парралельно.

Есть вопрост тем кто точно знает.
Нужно ли самому проверять контрольную сумму UDP, чтобы отсечь поврежденные пакеты, или соккеты делают это автоматически?

PS: Два игрока уже ездят на чистых соккетах. Сейчас нужно доделать системные сообщения о коннекте/дисконнекте новых игроков. И будем тестить : )

Megabyte-Ceercop
> Нужно ли самому проверять контрольную сумму UDP, чтобы отсечь поврежденные
> пакеты, или соккеты делают это автоматически?

Автоматически провенряются контрольные  суммы. Однако, в ваш поток могут вклиниваться чужие пакеты. Так что от контроля содержимого никто не избавляет.

Zab

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

Делаю вариант на TCP, чтобы проверить не будет ли это медленно, и будут ли видеть хост игроки с подключением через NAT.