Twisted Spread подходит для многопользовательских гоночных симуляторов?

Question

Считаете ли вы, что Twisted Spread может подойти (с точки зрения производительности) для многопользовательского гоночного симулятора? Остальная часть приложения основана на Python-Ogre.

Может ли Perspective Broker работать (надежно?) По UDP?

Answer 1

Это почти наверняка разумный протокол для начала. Помните главное правило оптимизации: не делайте этого. Работать с любым протоколом на основе TCP будет значительно проще, чем с любым протоколом на основе UDP. Изначально это гораздо важнее для успеха вашего проекта, чем для отправки сообщения между вашим клиентом и сервером требуется 30 или 45 миллисекунд. В конце концов, когда вы дойдете до того момента, когда станет ясно, что ваш проект действительно может быть успешным и вам действительно нужно потратить эти 15 (или сколько угодно) миллисекунд, вы можете вернуться к сетевому уровню и определить, является ли узкое место производительности (будь то задержка) или какой-либо другой показатель) из-за вашего выбора протокола. Если так, то это время, чтобы потратить время на оценку различных альтернатив. Только в этот момент усилия по выбору идеального протокола могут окупиться (поскольку вы намного ближе к завершенному проекту), и к тому времени вы получите значительно улучшенное понимание проблемы и должны очень четко сформулировали ваши требования, еще две вещи, которые сделают задачу выбора соответствующего протокола (будь то на основе TCP или UDP) намного проще и с большей вероятностью будут правильными.

Answer 2

К вашему первому вопросу, да, производительность PB может быть вполне адекватной для игры в реальном времени. Несколько игр были написаны с использованием PB. Например, MV3D использует Twisted и Python-OGRE для представления общего физического моделирования.

К вашему второму вопросу, PB использует потоковый транспорт. Он может работать поверх «надежного UDP», используя что-то вроде модуля PTCP , который поставляется вместе с вершиной.

Однако вы должны знать, что "надежный UDP" будет, как правило, работать намного хуже , чем обычный старый TCP. Маршрутизаторы по всему интернету понимают TCP и могут оптимизировать его, используя это понимание. Если вы реализуете надежность поверх UDP, по необходимости вам потребуется реализовать что-то функционально эквивалентное TCP, и тогда вас оштрафуют на несколько факторов:

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

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

Обычно данные, которые подходят для передачи по протоколу UDP в игре, являются данными движения. Когда ваша позиция изменяется, вы можете отправить пакет UDP, и его можно отбросить, потому что игра заботится только о вашей самой последней позиции - после получения обновления все предыдущие позиции не имеют значения. Многие игры отправляют данные о движении по одному (ненадежному) каналу UDP, а затем все управляющие сообщения по более надежному каналу TCP.

Но ответ Жан-Поля об оптимизации является хорошим показателем того, когда вы можете рассмотреть возможность реализации этой оптимизации.