Comments 53
А я думал, это очевидно… Неужели кто-то будет разрабатывать сетевую FPS и не будет знать, что такое TCP и UDP?
Я-то думал тут какие-то особые фишки UDP будут. А тут вода на целую страницу, соединенная из двух статей википедии.
Хотя бы про анти-лаг — методы в UDP написали бы и прочие обработки/оптимизации.
Я-то думал тут какие-то особые фишки UDP будут. А тут вода на целую страницу, соединенная из двух статей википедии.
Хотя бы про анти-лаг — методы в UDP написали бы и прочие обработки/оптимизации.
Ну это только первая статья, в следующих, естественно, все будет раскрыто на практике. Ну и конечно вряд ли кто-то сразу сядет за написание сетевой FPS в качестве первой игры:) Так что это скорее для тех, кто только начинает заниматься сетевыми играми.
Не знаю… Просто я не представляю, как бы я сел за написание сетевой игры, не зная, что такое сеть и такие фундаментальные основы, как протоколы :) И не представляю таких людей, хотя, может быть даже они и существуют.
Спорить не буду, конечно, все знают, что есть TCP и UDP, и т.п. Просто такой стиль у автора — от самых основ. Мне, например, такое нравится больше, чем когда сразу «с места в карьер»:)
Я тоже не представлял. Потом в форумный топик моей опенсорс либы для мульиплеера набежал народ и начал задавать глупейшие вопросы. И я стал давать ссылки на статьи из представленного выше цикла.
Есть еще вариант «Я собираюсь написать… О! А тут рассказывается что лучше использовать в моем слечае. Спасибо большое!»
Вот уж не знаю. Ваш пассаж про википедию — это такой тонкий сарказм? Если так, лично у меня он вызывает лишь недоумение. Первые два абзаца дают вот что:
— это перевод;
— автору хотелось попробовать себя переводчиком;
— это цикл статей;
— опытным разработчикам статья может показаться очевидной;
— это часть онлайн-книги.
Так что, пожалуйста, либо пропустите статью, либо дождитесь новых переводов.
P.S. По поводу воды, думаю, разумно обращаться напрямую к автору :)
— это перевод;
— автору хотелось попробовать себя переводчиком;
— это цикл статей;
— опытным разработчикам статья может показаться очевидной;
— это часть онлайн-книги.
Так что, пожалуйста, либо пропустите статью, либо дождитесь новых переводов.
P.S. По поводу воды, думаю, разумно обращаться напрямую к автору :)
Почему Вы считаете что статья только для разработчиков?
мне как геймеру было очень инстересно. Хоть я и знал большинство из изложеного, но не системно, а тут всё по полочкам и доступно.
мне как геймеру было очень инстересно. Хоть я и знал большинство из изложеного, но не системно, а тут всё по полочкам и доступно.
Супер профи — видите что статья не вашего уровня, идите читайте ассемблерный код в HEX. Зачем высказывать свое фи, когда ясно что это серия статей и материал подан довольно круто? Мне как человеку не писавшему ничего realtime статья понравилась.
TCP и UDP это же протоколы, а не типы сокетов, я думаю правильно было б какой протокол использовать а не какой тип сокета.
Кстати на хабре есть перевод (имхо, отличный) еще одной статьи автора по той же теме (правда не из данного цикла) — habrahabr.ru/post/84543/
можно ли будет ждать перевода продолжения статей?
Зачитывался оригиналами, всем их обычно советую (в довесок к мануалу от Valve).
Теперь русскоязычным буду переведенные версии советовать. Спасибо!
Теперь русскоязычным буду переведенные версии советовать. Спасибо!
Исключительно для истории: отличный мануал от Valve developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
Начало интересное, жду продолжения.
Тема SPDY, Microsoft S+M и QUIC, UDT не раскрыта.
Что скажете про танкионлайн или комбатсектора от альтернативы? Вполне себе шутеры и при этом на TCP.
Кроме того, аргумент «отправлять на сервер нажатия клавиш быстрее по UDP» не очень удачный, это тоже не самая хорошая практика построения шутера.
Но даже использование UDP никак не освобождает от всяких интерполяций, предсказаний, отматывания времени и т.д.
Жаль альтернатива не делится своим опытом построения шутеров на флеше с TCP.
Кроме того, аргумент «отправлять на сервер нажатия клавиш быстрее по UDP» не очень удачный, это тоже не самая хорошая практика построения шутера.
Но даже использование UDP никак не освобождает от всяких интерполяций, предсказаний, отматывания времени и т.д.
Жаль альтернатива не делится своим опытом построения шутеров на флеше с TCP.
Насколько я знаю, на флеше нет свободы выбора — только TCP. Конечно можно и на TCP реализовать сетевую часть, вопрос в том, насколько принципиально время передачи по сети, и насколько это будет эффективно и быстро в разработке.
Про предсказание и симуляцию на клиенте конечно согласен, и это правда слабо связано с выбором протокола обмена.
Вот еще на stackoverflow подсказали пару игр на флеше (с TCP, соответственно):
http://www.xgenstudios.com/play/stickarena
http://everybodyedits.com/
Про предсказание и симуляцию на клиенте конечно согласен, и это правда слабо связано с выбором протокола обмена.
Вот еще на stackoverflow подсказали пару игр на флеше (с TCP, соответственно):
http://www.xgenstudios.com/play/stickarena
http://everybodyedits.com/
WoT использует UDP. Причем даже для загрузки данных аккаунта.
TCP при современном инете сойдет. Не для шутеров, но для РПГ — вполне. UDP не всегда актуален и, с нашим инетом, он как раз в проигрыше, т.к. шанс что пакет дойдет меньше. Сам сидел и сравнивал с Москвой.
З.Ы.: разрабатываю игру на TCP и с 10мб/с скоростью при ухватывании WASD и правильном прогерстве — вполне норм идет.
З.Ы.: разрабатываю игру на TCP и с 10мб/с скоростью при ухватывании WASD и правильном прогерстве — вполне норм идет.
Спасибо, замечательная статья. Хотел бы спросить про статистику потери UDP-пакетов на большие расстояния. Понимаю, что все сильно относительно, однако не создаст ли применение TCP/IP большего пинга, но бОльшей стабильности, нежели «дергания» при UDP?
Вопрос связан больше из истории своего детства. Мне было примерно 16 лет, когда я играл в одну из популярных мморпг. По правовым причинам (сервер был пиратский) администрации было удобнее держать сервер в Америке, хоть ориентировался только на русскоязычный сегмент. И тогда я задался вопросом как повысить именно стабильность, пусть даже с увеличением пинга. Для реализации этой затеи я перечитал многое, и решил проверить результат, если арендую VPN, находящийся рядом в Америке, соединюсь с ним как туннель по TCP/IP и UDP пакеты бы терялись меньше в случае меньшего кол-ва передающих хостов от VPN к игровому серверу. Сделал, проверил. Разницы, к сожалению, не ощутил.
Была ли обоснованность моей подобной логики? И можно ли сделать определенный вывод по фидбеку «разницы не ощутил»? Например — игровая особенность; потери пакетов были совсем недалеко от самого сервера (какой-то перегруженный маршрутизатор); потерь стало меньше, но лишние потенциальные тормоза при шифровании нивелировали преимущество надежности.
Вопрос связан больше из истории своего детства. Мне было примерно 16 лет, когда я играл в одну из популярных мморпг. По правовым причинам (сервер был пиратский) администрации было удобнее держать сервер в Америке, хоть ориентировался только на русскоязычный сегмент. И тогда я задался вопросом как повысить именно стабильность, пусть даже с увеличением пинга. Для реализации этой затеи я перечитал многое, и решил проверить результат, если арендую VPN, находящийся рядом в Америке, соединюсь с ним как туннель по TCP/IP и UDP пакеты бы терялись меньше в случае меньшего кол-ва передающих хостов от VPN к игровому серверу. Сделал, проверил. Разницы, к сожалению, не ощутил.
Была ли обоснованность моей подобной логики? И можно ли сделать определенный вывод по фидбеку «разницы не ощутил»? Например — игровая особенность; потери пакетов были совсем недалеко от самого сервера (какой-то перегруженный маршрутизатор); потерь стало меньше, но лишние потенциальные тормоза при шифровании нивелировали преимущество надежности.
Спасибо!
Статистика потерь в зависимости от расстояния, думаю, сильно зависит от промежуточных сетей, через которые проходит пакет. Поэтому говорить о какой-то общей закономерности вряд ли можно. В статье, на которую ссылается автор (http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM), зато есть интересные закономерности потерь в зависимости от размера UDP пакета, количества параллельных TCP соединений и наличия эффекта синхронизации TCP.
Статистика потерь в зависимости от расстояния, думаю, сильно зависит от промежуточных сетей, через которые проходит пакет. Поэтому говорить о какой-то общей закономерности вряд ли можно. В статье, на которую ссылается автор (http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM), зато есть интересные закономерности потерь в зависимости от размера UDP пакета, количества параллельных TCP соединений и наличия эффекта синхронизации TCP.
Видел я такие игры на UDP — в конечном итоге все равно всё сводится к написанию своего TCP повверх UDP, но без всяких вкусных фич\расширений TCP типа congestion avoidance и т.п.
Если писать мега крутую игру с большим бюджетом типа CoD или BF, наверное, есть смысл использовать UDP и реализовывать на нем нужные фишки TCP. Но если проект с небольшим бюджетом, то немногим более высокий пинг это последнее о чем стоит беспокоиться.
А что значит, между одним и другим компьютером могут быть тысячи промежуточных? Это как-то расходится с моими наблюдениями. В худших случаях — малые десятки.
Меня всегда интерисовало использование, что-то типа ømq для связи. Очень же удачно подходит?
А пространство портов для TCP и UDP одно или для каждого своё?
Пространство конечно одно, но есть «устоявшиеся» порты и возможные протоколы, с которыми работают приложения на этих портах. Порты с номерами < 1024 стандартизированы жестко, >= 1024 — можно использовать любые, но тоже есть определенные устоявшиеся пары «порт — приложение». В вики есть полный список — http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Пространство портов конечно же разное. Если вы например слушаете порт 3333 на TCP, то вне зависимости от этого вы можете слушать 3333 порт на UDP. Просто эти пространства совпадают по размеру, и часто совпадают по использованию.
Ох, спасибо, понял свою ошибку. Я думал fshp спрашивает про разделение номеров портов вообще.
Вроде все прочитанное уже известно, но прочитал с интересом. Спасибо, буду с нетерпением ждать продолжения.
Очень советую — github.com/lsalzman/enet
ENet's purpose is to provide a relatively thin, simple and robust network communication layer on top of UDP (User Datagram Protocol). The primary feature it provides is optional reliable, in-order delivery of packets.
Простая и компилится под все что можно.
ENet's purpose is to provide a relatively thin, simple and robust network communication layer on top of UDP (User Datagram Protocol). The primary feature it provides is optional reliable, in-order delivery of packets.
Простая и компилится под все что можно.
Спасибо, хорошая статья.
Послушать бы комментарии разрабов WOT, tankionline…
Послушать бы комментарии разрабов WOT, tankionline…
помните, что между отправителем и получателем могут находитЬся тысячи компьютеров
Over 9000!
Кстати вот я заметил, что для видео и аудио есть протоколы транспортного уровня, а для игр как-то все слабо. Я понимаю что игры стандартизировать довольно сложно, ведь всякие бывают и у них разные требования к сети.
Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).
В общем кому интересно читайте:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf
Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).
В общем кому интересно читайте:
citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf
Сделайте, пожалуйста, ссылки на последующие части в начале поста. Как-то не очень удобно с конца их листать.
Sign up to leave a comment.
Сетевое программирование для разработчиков игр. Часть 1: UDP vs. TCP