All streams
Search
Write a publication
Pull to refresh
-1
0
Владимир @wlbm_onizuka

C# Developer

Send message
Проблема в том что все статьи в блоге PVS-Studio одинаковые как 2 капли воды… поэтому раздражает видеть в ленте очередной пост. И опции скрыть источник на хабре нет. Остается только ждать когда ребята сами осознают проблему
затем чтобы не закладывать лишних ограничений без необходимости. поменять на IList вы сможете всегда, а вот завязавшись на его методы, обратно путь будет сложнее.
В чем печаль-то? проект был своевременным, отслужил своё, принес пользу.
Теперь сообщество выбрало GitHub, ну ОК.
лучше ошибиться в одном месте, чем в нескольких. разве нет?
Я думаю сама корпорация очень хотела-бы, чтобы встроили. Только владельцы браузеров не хотя. И правильно делают
они используют старую глубоко-модифицированную версию Unreal Engine, с точки зрения движка там за почти уже 15 лет ничего значимого не поменялось
перед тем как говорить неправду, можно сначала проверить. или заглянуть в оффициальный сапорт Ports-necessary-to-connect-and-play-Lineage-II
Вовсе нет. Я считаю лишь то, что транспортные протоколы TCP и UDP реализованны оптимальным образом. а разница между ними именно для пользователя приложения — минимальная. Чем стоит озаботиться среднему разработчику — так это лаг-коменсацией. А вот если сделать то что вы предложили, поднять кучу коннектов, дублировать пакеты и все такое, станет только хуже.
Ну что вы говорите, там в настройках можно установить предел количества отображаемых персонажей, и все тормоза на осаде тут-же прекращаются. Хотя все пакеты клиент конечно-же получает.
с точки зрения графики, там тормоза квадратично нарастают, так что клиент Lineage до сих пор нагибает даже современные компы (особенно с учетом того что видеокарта почти не задействуется, и работает все через 1 поток на CPU)
Вот это жесть полная будет. Столько накладных расходов и столько усложнения кода… а самое главное — обмануть физику все равно не удастся.
Lineage клиент однопоточный и тормозит в нем графика, а не сеть.
Я не отрицаю проблему протухания пакетов на устройстве, я отрицаю практическую важность этой проблемы, поскольку условия при которых она становится важной, создают не менее критичные проблемы для UDP протокола.

Я знаю что игры создают 2 коннекта, и утверждаю что это только для борьбы с накладными расходами. в подтверждение чего привожу пример, что можно играть через UDP over HTTP и не будет никакой заметной разницы.

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

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

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

когда говорят что UDP «быстрый» имеется ввиду уменьшение накладных расходов, что выгодно при передаче жирного трафика вроде потокового видео. Или в том случае если у вас реально нагруженный сервер, например игра вроде League of Legends.

на стороне игрока разница не будет заметна. Я лично на своей первой работе играл в лигу легенд через прокси сервер, прокинув http-туннель до дома, и не заметил ни малейшего дискомфорта.

если уж такая вакханалия как UDP over HTTP прекрасно работает, чего уж там говорить о разнице UDP vs TCP
1) Пишем свой небольшой тестовый клиент и сервер, сервер запускаем на VDS, пинг до которого примерно 100мс.
2) отправляем несколько тысяч tcp пакетов, замеряем средний пинг
3) отправляем несколько тысяч udp пакетов, замеряем средний пинг. потерянные пакеты выбрасываем
4) думаете разница будет хоть сколько-то значительна?))
во первых отправлять пакеты 20 раз в секунду неправильно. о чем я и говорил. отправлять пакеты надо по мере необходимости, когда есть новые данные.
во вторых TCP пакет на нормальном соединении просто так не дропнется. если у вас дропаются TCP пакеты, что-то сильно пошло не так, и никакое UDP уже не поможет
в третьих, TCP это транспортный протокол, который сам решает транспортные проблемы. если что-то там внутри него и дропается, он исправляет проблему, и делает это очень быстро. все что вы сможете заметить — небольшой скачек пинга.
Проблема с TCP надуманна и преувеличена.
в случае плохого соединения нормально поиграть не получится независимо от протокола
а в случае хорошего соединения
1) 60-100мс пинг до сервера
2) ~200мс лаг человеческого восприятия
3) <1мс какая-то там разница между TCP и UDP

скажите мне что я не учел?
да кстати что это за дурацкий принцип, который они называют «блокировкой начала очереди», мы же ведь не собираемся отправлять пакеты в бесконечном цикле, забивая весь канал, а потом жаловаться что что-то пошло не так. или собираемся? и будем жаловаться на TCP?
такое может только большой жирный бизнес, который может инвестировать в будущее. а маленькой компании едва вставшей на ноги, большой наплыв халявщиков совсем не нужен
Сложную задачу лучше закончить сразу. С простой задачей это будет работать
Я думаю для UWP открывают, потому что заработать на них что-то вменяемое не получилось, платформа редкая

Information

Rating
Does not participate
Location
Новосибирск, Новосибирская обл., Россия
Date of birth
Registered
Activity