Пользователь
0,0
рейтинг
15 января 2014 в 13:13

Разработка → Сетевое программирование для разработчиков игр. Часть 1: UDP vs. TCP перевод

От переводчика: Это перевод первой статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.


Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.

image

В этой статье мы начнем с самых базовых аспектов сетевого программирования — приема и передачи данных по сети. Прием и передача данных — это основная и наиболее простая часть из всего круга задач, которыми занимаются сетевые программисты, но часто бывает сложно определить, каким путем лучше двигаться. Уделите этой части достаточно внимания — если у вас останется непонимание, то это может привести к ужасным последствиям для вашей многопользовательской игры в дальнейшем!

Вы, скорее всего, уже что-нибудь слышали о сокетах, и, возможно, знаете, что они делятся на два основных типа — TCP и UDP. Первое, что нужно решить при разработке многопользовательской игры — это какой тип сокетов использовать — TCP, UDP, или оба?

Выбор типа сокетов полностью зависит от жанра игры, которую разрабатываете. В данном цикле статей я буду считать, что вы пишете игру в стиле action — наподобие Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress и т.п.

Теперь мы более подробно рассмотрим свойства каждого типа сокетов (учитывая тот факт, что мы разрабатыватаем игру в стиле action), и немного углубимся в детали работы сети интернет. После подробного обзора правильный вариант станет очевиден!

TCP расшифровывается как “transmission control protocol” (протокол контроля передачи), а IP — как “internet protocol”. Вместе они лежат в основе практически всего, что вы делаете в сети, начиная от просмотра веб-страниц и кончая общением в IRC и электронной почтой — все это работает на основе TCP/IP.

Если вы когда-либо уже использовали TCP сокеты, то вы должны знать, что TCP — это протокол, использующий принцип надежного соединения. Это означает, что вы устанавливаете соединение между двумя компьютерами, и затем пересылаете данные между ними подобно тому, как если бы вы записывали информацию в файл на одном компьютере, а на другом — считывали бы ее из того же файла.

При этом соединение считается надежным и последовательным — то есть, вся информация, которую вы посылаете, гарантированно должна дойти до получателя в том же порядке, в каком была отправлена. Также TCP соединение можно считать непрерывным потоком данных — протокол сам заботится о разбивке данных на пакеты и пересылке их по сети.

Еще разок — все просто, как обычная запись или чтение из файла. Элементарно, Ватсон!

Но такая простота в обращении совершенно отличается от того, что на самом деле происходит «под капотом», на более низком уровне — уровне протокола IP.

На этом уровне нет понятия соединения — вместо этого отдельные пакеты передаются от одного компьютера к другому. Можно представить этот процесс как передачу записки от одного человека к другому в комнате, полной народу: в конце концов записка попадает к кому надо, но при этом пройдя через множество рук.

При этом нет никакой гарантии того, что записка дойдет до адресата. Отправитель просто отправляет записку в надежде, что она дойдет, но при этом даже не знает, дошло ли послание или нет — до тех пор, пока получатель не решит написать в ответ.
Естественно, в реальности все немного сложнее, поскольку компьютер-отправитель не знает точную последовательность компьютеров в сети, через которые надо передать пакет, чтобы он добрался как можно быстрее. Иногда IP передает несколько копий одного и того же пакета, которые могут идти до адресата разными путями — и, скорее всего, дойдут в разное время.

Так происходит потому, что сеть интернет — это самоорганизующаяся и самовосстанавливающаяся система, которая может “обходить” проблемные участки в сети. На самом деле, то, что происходит на таком низком уровне в сети — реально круто. Вы можете почитать об этом более подробно в уже ставшей классикой книге — “TCP/IP Illustrated”.

А что, если мы захотим пересылать информацию между компьютерами не в стиле чтения/записи в файл, а непосредственно отправляя и получая отдельные пакеты?

Что ж, мы можем сделать это, используя UDP. UDP расшифровывается как “user datagram protocol” (протокол пользовательских датаграмм), и он работает поверх IP (как и TCP), но вместо добавления кучи функциональности он представляет собой лишь небольшую надстройку над IP.

Используя UDP, мы можем отослать пакет по определенному IP адресу (к примеру, 112.140.20.10) и порту (к примеру, 52423), и он будет передаваться от компьютера к компьютеру, пока не достигнет цели (или не потеряется по пути).

При этом, на стороне приемника мы просто сидим и ждем, прослушивая определенный порт (52423 в нашем случае), и, когда на него приходит пакет от кого-либо (помним, что соединения не используются), мы получаем об этом уведомление с адресом и портом компьютера-отправителя, размером пакета, и после этого можем прочитать данные из этого пакета.

Протокол UDP не гарантирует доставку данных. На практике большинство пакетов, конечно, доходят, но всегда имеются потери около 1-5%, а иногда бывают периоды времени, в которые пакеты вообще не доходят (помните, что между отправителем и получателем могут находиться тысячи компьютеров, на любом из которых что-то может отказать или сломаться).

Также UDP не гарантирует порядок доставки пакетов. Вы можете отправить пять пакетов по порядку — 1, 2, 3, 4, 5 — а прийти они могут совершенно в другом порядке — к примеру, 3, 1, 2, 5, 4. Опять же, на практике, они скорее всего придут в правильном порядке в большинстве случаев, но полагаться на это нельзя!

Наконец, хоть UDP и ничего особо не добавляет к IP, одну вещь он все-таки гарантирует. Если вы пересылаете пакет, то он либо дойдет полностью, либо не дойдет вообще. Так, если вы пересылаете пакет в 256 байт другому компьютеру, то он не может получить только первые 100 байт от пакета — он обязательно должен получить все 256 байт. Это реально единственная вещь, которую гарантирует протокол UDP — все остальное ложится на ваши плечи.

Итак, нам нужно решить — использовать TCP или UDP сокеты? Давайте взглянем на их свойства:

TCP:
  • Использует принцип соединений
  • Гарантирует доставку и очередность
  • Автоматически разбивает информацию на пакеты
  • Следит за тем, чтобы не пересылать данные слишком интенсивно (контроль потока данных)
  • Легко использовать — как запись/чтение из файла

UDP:
  • Не использует принцип соединений — придется реализовывать это вручную
  • Не гарантирует доставку и порядок доставки пакетов — они могут дойти в неправильном порядке, с дубликатами, или вообще не дойти!
  • Нужно вручную разбивать данные на пакеты и отправлять их
  • Нужно следить за тем, чтобы не пересылать данные слишком интенсивно
  • Если пакет потеряется, то нужно как-то это отследить, и в случае необходимости переслать его заново

С таким списком решение кажется очевидным — TCP реализует всю необходимую нам функциональность и его проще использовать, тогда как использование UDP обещает геморрой с написанием всего на свете вручную, с нуля. Значит, используем TCP, да?

А вот и нет.

Использовать TCP — это наверное, худшая ошибка, которую можно совершить, разрабатывая многопользовательскую игру. Чтобы понять почему, давайте разберемся, что делает TCP таким простым в использовании!

Как работает TCP

TCP и UDP оба работают поверх IP, но по факту они совершенно разные. UDP ведет себя очень похоже на IP, в то время как TCP абстрагирует пользователя от всех проблем с пакетами, делая взаимодействие с ним похожим на чтение/запись в файл.

Итак, как же он это делает?

Во-первых, TCP использует абстракцию потока данных — вы можете просто записывать байты данных в этот поток, и TCP позаботится о том, чтобы они дошли до адресата. Так как протокол IP передает данные пакетами, а TCP работает поверх IP, TCP должен разбивать поток входных данных пользователя на отдельные пакеты. Таким образом, внутри TCP некоторая логика собирает данные в очередь, и, когда их накапливается достаточно много, она формирует пакет и отправляет его адресату.

Такое поведение может стать проблемой для нашей многопользовательской игры, если нужно передавать очень маленькие пакеты. Может случиться так, что TCP решит не передавать наши данные, пока их не накопится достаточно, чтобы сформировать пакет определенного размера (скажем, больше ста байт). И это — большая проблема, потому что необходимо передавать данные с клиента (нажатия клавиш игрока) на сервер как можно быстрее, и если при этом будут возникать задержки из-за буферизации данных протоколом, то для игрока на клиентской стороне игра будет происходить далеко не самым приятным образом. При этом обновление объектов игры будет происходить с задержкой и редко — тогда как нам нужно делать обновление объектов вовремя и часто.

В TCP есть опция, призванная исправить это — “TCP_NODELAY”. Она говорит протоколу, чтобы он не ждал накопления данных в очереди на отправку, а отсылал их сразу.

К сожалению, даже с установленной данной опцией, у TCP наблюдается множество проблем при использовании его в сетевых играх.

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

Как TCP обеспечивает надежность соединения

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

Но что будет, если один из пакетов не дойдет? Или если пакеты придут не по порядку, или с дубликатами?

Если особо не углубляться в детали работы TCP (а это реально очень сложная тема — можете почитать в TCP/IP Illustrated), процесс выглядит так: TCP отправляет пакет, определяет, что пакет не дошел, и заново отправляет тот же пакет адресату. Дублирующиеся пакеты отсеиваются на стороне адресата, а пакеты, пришедшие не по порядку — переупорядочиваются, чтобы все было как надо — надежно и по порядку.

Проблема заключается в том, что когда TCP таким образом “синхронизирует” поток данных, в случае потери пакета передача останавливается до тех пор, пока потерянный пакет не будет отправлен заново (и получен адресатом). Если во время ожидания придут новые данные, они будут поставлены в очередь, и вы не сможете прочитать их, пока не дойдет тот самый потерянный пакет. Сколько времени занимает посылка пакета заново? Она занимает как минимум время, равное времени прохождения пакета туда и обратно (когда TCP определяет, какой пакет надо отправить заново), плюс время на повторную доставку потерянного пакета. Так что, если пинг между компьютерами составляет 125 мс, повторная передача пакета займет примерно одну пятую секунды, а в худшем случае — до полсекунды (представьте, если вдруг заново отправленный пакет тоже потеряется). Веселуха!

Почему никогда не стоит использовать TCP для многопользовательских игр

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

Рассмотрим простой пример многопользовательской игры, например, 3d-шутер. Сетевая часть в игре построена очень просто: каждую итерацию цикла игры клиент посылает на сервер описание всех действий игрока (нажатые клавиши, положение мыши и т.п.), и каждую итерацию сервер обрабатывает эти данные, обновляет модель игрового мира и посылает обратно клиенту текущие позиции объектов мира, чтобы тот отрисовал игроку новый кадр.

Итак, в нашей игре, если пакет будет потерян при передаче по сети, игра останавливается и ждет, пока пакет не будет доставлен заново. На клиентской стороне игровые объекты замирают, и на сервере игроки также не могут двигаться или стрелять, так как сервер не может принимать новые пакеты. Когда потерянный пакет наконец доходит, в нем содержится уже устаревшая информация, которая уже является неактуальной. К тому же после этого приходят и все те пакеты, которые накопились в очереди за время ожидания, и их всех нужно обработать за одну итерацию цикла. Полная неразбериха!

К сожалению, изменить такое поведение TCP никак нельзя, да и не надо, так как в нем и заключается смысл TCP. Это — необходимость, чтобы сделать передачу данных через интернет надежным и последовательным потоком данных.
Но нам не нужен надежный и последовательный поток данных.

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

Но подождите! Почему я не могу использовать и UDP, и TCP вместе?

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

Конечно, велико искушение использовать UDP для передачи данных пользовательского ввода и состояния мира, а TCP — для тех данных, которые должны быть гарантированно доставлены. Возможно, вы даже думаете, что можно сделать несколько “потоков” команд — например, один для загрузки уровней, другой — для команд AI. Вы думаете: “Мне не нужно, чтобы команды AI ждали в очереди, если потеряется пакет с данными для загрузки уровня, ведь они же совершенно не связаны!”. В данном случае вы правы, и вы можете решить создать по TCP сокету на каждый поток команд.

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

Заключение

Я рекомендую не просто использовать UDP, но и использовать только UDP и больше ничего. Не используйте TCP и UDP вместе — вместо этого лучше узнайте, как реализовать те “фишки” TCP, которые вам нужны, самостоятельно, на основе UDP.

В следующих статьях я расскажу, как это сделать — от реализации собственного протокола с использованием соединений на основе UDP, до реализации обеспечения надежности передачи и контроля потока данных.
Перевод: Glenn Fiedler
@bvasilyev
карма
21,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (53)

  • +3
    А я думал, это очевидно… Неужели кто-то будет разрабатывать сетевую FPS и не будет знать, что такое TCP и UDP?

    Я-то думал тут какие-то особые фишки UDP будут. А тут вода на целую страницу, соединенная из двух статей википедии.

    Хотя бы про анти-лаг — методы в UDP написали бы и прочие обработки/оптимизации.
    • +9
      Ну это только первая статья, в следующих, естественно, все будет раскрыто на практике. Ну и конечно вряд ли кто-то сразу сядет за написание сетевой FPS в качестве первой игры:) Так что это скорее для тех, кто только начинает заниматься сетевыми играми.
      • 0
        Не знаю… Просто я не представляю, как бы я сел за написание сетевой игры, не зная, что такое сеть и такие фундаментальные основы, как протоколы :) И не представляю таких людей, хотя, может быть даже они и существуют.
        • +5
          Спорить не буду, конечно, все знают, что есть TCP и UDP, и т.п. Просто такой стиль у автора — от самых основ. Мне, например, такое нравится больше, чем когда сразу «с места в карьер»:)
        • +1
          Я тоже не представлял. Потом в форумный топик моей опенсорс либы для мульиплеера набежал народ и начал задавать глупейшие вопросы. И я стал давать ссылки на статьи из представленного выше цикла.
        • 0
          Есть еще вариант «Я собираюсь написать… О! А тут рассказывается что лучше использовать в моем слечае. Спасибо большое!»
    • +10
      Вот уж не знаю. Ваш пассаж про википедию — это такой тонкий сарказм? Если так, лично у меня он вызывает лишь недоумение. Первые два абзаца дают вот что:
      — это перевод;
      — автору хотелось попробовать себя переводчиком;
      — это цикл статей;
      — опытным разработчикам статья может показаться очевидной;
      — это часть онлайн-книги.
      Так что, пожалуйста, либо пропустите статью, либо дождитесь новых переводов.

      P.S. По поводу воды, думаю, разумно обращаться напрямую к автору :)
      • 0
        Да, я уже перечитал до вас.

        Либо я этого не заметил, либо автор его не сразу вписал. В первом случае — прошу прощения.
    • +1
      Почему Вы считаете что статья только для разработчиков?
      мне как геймеру было очень инстересно. Хоть я и знал большинство из изложеного, но не системно, а тут всё по полочкам и доступно.
    • 0
      Супер профи — видите что статья не вашего уровня, идите читайте ассемблерный код в HEX. Зачем высказывать свое фи, когда ясно что это серия статей и материал подан довольно круто? Мне как человеку не писавшему ничего realtime статья понравилась.
  • +3
    TCP и UDP это же протоколы, а не типы сокетов, я думаю правильно было б какой протокол использовать а не какой тип сокета.
    • +1
      Согласен, но такова терминология автора. Скорее он подходит утилитарно — для передачи данных по сети нужен сокет, и вот тут оказывается, что они бывают разные.
  • +1
    Кстати на хабре есть перевод (имхо, отличный) еще одной статьи автора по той же теме (правда не из данного цикла) — habrahabr.ru/post/84543/
  • 0
    можно ли будет ждать перевода продолжения статей?
    • +5
      Конечно. Работа идет не очень быстро, но идет:)
  • 0
    Зачитывался оригиналами, всем их обычно советую (в довесок к мануалу от Valve).
    Теперь русскоязычным буду переведенные версии советовать. Спасибо!
    • 0
      Исключительно для истории: отличный мануал от Valve developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
      • 0
        Интереснее было бы взглянуть на описание механизмов unreal. Сорсовый движок удручает подходом «проблемы со связью у одного — проблемы у всех».
  • +2
    Начало интересное, жду продолжения.
  • –6
    Тема SPDY, Microsoft S+M и QUIC, UDT не раскрыта.
    • +4
      А какое это, собственно, имеет отношение к теме?
  • –3
    Что скажете про танкионлайн или комбатсектора от альтернативы? Вполне себе шутеры и при этом на TCP.
    Кроме того, аргумент «отправлять на сервер нажатия клавиш быстрее по UDP» не очень удачный, это тоже не самая хорошая практика построения шутера.
    Но даже использование UDP никак не освобождает от всяких интерполяций, предсказаний, отматывания времени и т.д.

    Жаль альтернатива не делится своим опытом построения шутеров на флеше с TCP.
    • 0
      Насколько я знаю, на флеше нет свободы выбора — только TCP. Конечно можно и на TCP реализовать сетевую часть, вопрос в том, насколько принципиально время передачи по сети, и насколько это будет эффективно и быстро в разработке.
      Про предсказание и симуляцию на клиенте конечно согласен, и это правда слабо связано с выбором протокола обмена.

      Вот еще на stackoverflow подсказали пару игр на флеше (с TCP, соответственно):

      http://www.xgenstudios.com/play/stickarena
      http://everybodyedits.com/
      • 0
        во флеше есть, конечно, UDP, но доступно только на платформе AIR
    • 0
      WoT использует UDP. Причем даже для загрузки данных аккаунта.
      • 0
        речь идет про танкионлайн, которые на флеше, а не про WOT.
        • 0
          Прошу прощения, ошибся. Для меня «танки онлайн» это исключительно WoT :)
  • –4
    TCP при современном инете сойдет. Не для шутеров, но для РПГ — вполне. UDP не всегда актуален и, с нашим инетом, он как раз в проигрыше, т.к. шанс что пакет дойдет меньше. Сам сидел и сравнивал с Москвой.

    З.Ы.: разрабатываю игру на TCP и с 10мб/с скоростью при ухватывании WASD и правильном прогерстве — вполне норм идет.
    • 0
      Немного не понял — как от типа протокола (TCP или UDP) зависит вероятность прохождения IP пакета?
      • 0
        Я имел в виду шанс доставки сообщения серверу вобще.
  • 0
    Спасибо, замечательная статья. Хотел бы спросить про статистику потери UDP-пакетов на большие расстояния. Понимаю, что все сильно относительно, однако не создаст ли применение TCP/IP большего пинга, но бОльшей стабильности, нежели «дергания» при UDP?

    Вопрос связан больше из истории своего детства. Мне было примерно 16 лет, когда я играл в одну из популярных мморпг. По правовым причинам (сервер был пиратский) администрации было удобнее держать сервер в Америке, хоть ориентировался только на русскоязычный сегмент. И тогда я задался вопросом как повысить именно стабильность, пусть даже с увеличением пинга. Для реализации этой затеи я перечитал многое, и решил проверить результат, если арендую VPN, находящийся рядом в Америке, соединюсь с ним как туннель по TCP/IP и UDP пакеты бы терялись меньше в случае меньшего кол-ва передающих хостов от VPN к игровому серверу. Сделал, проверил. Разницы, к сожалению, не ощутил.

    Была ли обоснованность моей подобной логики? И можно ли сделать определенный вывод по фидбеку «разницы не ощутил»? Например — игровая особенность; потери пакетов были совсем недалеко от самого сервера (какой-то перегруженный маршрутизатор); потерь стало меньше, но лишние потенциальные тормоза при шифровании нивелировали преимущество надежности.
    • 0
      Спасибо!
      Статистика потерь в зависимости от расстояния, думаю, сильно зависит от промежуточных сетей, через которые проходит пакет. Поэтому говорить о какой-то общей закономерности вряд ли можно. В статье, на которую ссылается автор (http://www.isoc.org/INET97/proceedings/F3/F3_1.HTM), зато есть интересные закономерности потерь в зависимости от размера UDP пакета, количества параллельных TCP соединений и наличия эффекта синхронизации TCP.
  • +2
    Видел я такие игры на UDP — в конечном итоге все равно всё сводится к написанию своего TCP повверх UDP, но без всяких вкусных фич\расширений TCP типа congestion avoidance и т.п.
    • 0
      Ну собственно автор именно это и предлагает:)
      Расскажите подробнее, если можно — почему так получалось? Интересно почитать про реальный опыт разработки.
      • 0
        Именно это автор не предлагает. Автор объясняет, почему tcp использовать не нужно. Конкретные причина — допустимость потерь отдельных пакетов и не допустимость задержек, связанных с тем что tcp разруливает потери пакетов и перепосылает их заново.
    • 0
      Да. И самое удивительное, что в итоге свой «TCP» работает лучше, т.к. заточен под конкретную специфику.
  • 0
    Если писать мега крутую игру с большим бюджетом типа CoD или BF, наверное, есть смысл использовать UDP и реализовывать на нем нужные фишки TCP. Но если проект с небольшим бюджетом, то немногим более высокий пинг это последнее о чем стоит беспокоиться.
  • 0
    А что значит, между одним и другим компьютером могут быть тысячи промежуточных? Это как-то расходится с моими наблюдениями. В худших случаях — малые десятки.
    • 0
      Согласен, конечно в большинстве случаев промежуточных нод намного меньше. Думаю, тут автор подчеркивает что их теоретически может быть очень много, и полагаться на то, что всегда пакеты будут проходить корректно, нельзя.
  • 0
    Меня всегда интерисовало использование, что-то типа ømq для связи. Очень же удачно подходит?
  • 0
    А пространство портов для TCP и UDP одно или для каждого своё?
    • 0
      Пространство конечно одно, но есть «устоявшиеся» порты и возможные протоколы, с которыми работают приложения на этих портах. Порты с номерами < 1024 стандартизированы жестко, >= 1024 — можно использовать любые, но тоже есть определенные устоявшиеся пары «порт — приложение». В вики есть полный список — http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
      • 0
        Пространство портов конечно же разное. Если вы например слушаете порт 3333 на TCP, то вне зависимости от этого вы можете слушать 3333 порт на UDP. Просто эти пространства совпадают по размеру, и часто совпадают по использованию.
        • 0
          Ох, спасибо, понял свою ошибку. Я думал fshp спрашивает про разделение номеров портов вообще.
  • 0
    Вроде все прочитанное уже известно, но прочитал с интересом. Спасибо, буду с нетерпением ждать продолжения.
  • 0
    Очень советую — 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.

    Простая и компилится под все что можно.
  • 0
    Спасибо, хорошая статья.
    Послушать бы комментарии разрабов WOT, tankionline…
  • –1
    помните, что между отправителем и получателем могут находитЬся тысячи компьютеров

    Over 9000!
  • 0
    Кстати вот я заметил, что для видео и аудио есть протоколы транспортного уровня, а для игр как-то все слабо. Я понимаю что игры стандартизировать довольно сложно, ведь всякие бывают и у них разные требования к сети.

    Но вот стало интересно даже и нашел в сети статью от корейских исследователей на тему ММО(ну а кто ж еще, как не корейцы этим будут заниматся :)).

    В общем кому интересно читайте:
    citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.98.7687&rep=rep1&type=pdf
    • –1
      Картинка_xkcd_про_стандарты.жпег
  • 0
    Сделайте, пожалуйста, ссылки на последующие части в начале поста. Как-то не очень удобно с конца их листать.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.