|
|
|
Выбор эмулятора |
|
|
Juzzver |
3.4.2021, 3:20
|
Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008 Группа: Супермодераторы Наличность: 22562 Из: Северная Корея
Пользователь №: 11.273
|
Цитата(Ubu @ 3.4.2021, 0:58) хоть убейте, так и не понял чем рануо от сервуо отличается в приниципе, кроме того что сервуо больше контента
Ну тем и отличается (IMG: style_emoticons/default/smile.gif) Качеством кода отличается. Если делать ренесанс версию, то нет смысла брать сервуо с её контентом, ибо будет только лишняя нагрузка на производительность и плотные сейвы с параметрами, которые не будут использоваться, + косяки повылазят точно, т.к. там не сильно смотрят под какие эры правки делаются. А с недавних пор они вообще отказались от поддержки ренесанса и начали выпиливать код, так что последние паблиши вовсе негодные под ренесанс версию. Так что тут либо брать предыдущие паблиши (до <= 54 publish), либо вовсе отказаться и взять чистую ранку, где ничего не вылезет, но придется приложить немного руку - чтобы что-то появилось по контенту (IMG: style_emoticons/default/biggrin.gif) Из сервуо всегда можно будет что-то вырвать и перенести на рануо, правда не без крови, т.к. они там уже пишут совсем как попало, количество зависимостей неимоверное теперь. Если делать максимально по оси что-то, то брать сервуо со всеми их изъянами, благо можно поправить, это будет проще чем писать тонны контента с нуля.
--------------------
|
|
|
|
Ubu |
3.4.2021, 20:56
|
Neophyte
Сообщений: 16
Регистрация: 31.5.2018 Группа: Пользователи Наличность: 0
Пользователь №: 18.962
Возраст: 32
|
Цитата RunUO is coming back in 2021.... интересно, а что говорят интересного будет? или молчат пока и не факт что будет что-то?) Почему-то мне кажется, что последнее, судя по тому как обычно все происходит... Цитата Создай тему в соответствующем разделе, а то каша получается. done, извиняюсь) @Juzzver ответь в асю плиз
|
|
|
|
Juzzver |
3.4.2021, 22:40
|
Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008 Группа: Супермодераторы Наличность: 22562 Из: Северная Корея
Пользователь №: 11.273
|
Цитата(Ubu @ 3.4.2021, 20:56) интересно, а что говорят интересного будет? или молчат пока и не факт что будет что-то?) Почему-то мне кажется, что последнее, судя по тому как обычно все происходит...
Там на сайте ссылка на дискорд, в котором шумиху эту обговаривают. Собралось уже человек 200, из которых многие из старых разработчиков RunUO и просто знатных девов. Из того что сделали - подняли бекап старого сайта со всеми данными, скриптами и прочей инфой. Что говорят - особо не вникал, и до сих пор вроде активных действий еще не было. Я думаю они размышляют в каком направлении двигаться, читал разговоры про ранку на js фреймворках и прочие идеи, но пока это только разговоры. Там же есть дев от ModernUO, который уже внес большой вклад в форк ранки, переписывает её уже пару лет под современные технологии, добился хороших показателей в плане оптимизаций, кросфплатформенности и еще ряда решений, так-же еще много планов на пути. Активно отвечает всем заинтересовавшимся его проектом, и есть хорошая вероятность что плоды его работы возьмут для рануо. Цитата @Juzzver ответь в асю плиз
Аськой перестал пользоваться. Пиши в дискорд или скайп: Juzzver#6102
--------------------
|
|
|
|
nullptr |
18.8.2021, 17:24
|
Neophyte
Сообщений: 49
Регистрация: 13.3.2021 Группа: Пользователи Наличность: 0
Пользователь №: 19.916
|
Цитата(Juzzver @ 4.4.2021, 0:40) Там же есть дев от ModernUO, который уже внес большой вклад в форк ранки, переписывает её уже пару лет под современные технологии, добился хороших показателей в плане оптимизаций, кросфплатформенности и еще ряда решений, так-же еще много планов на пути. Активно отвечает всем заинтересовавшимся его проектом, и есть хорошая вероятность что плоды его работы возьмут для рануо.
У ModernUO, самый большой плюс современный tcp стек, что значительно снижает пинг при больших обменах(замесы итд), Runtime code generation, хоть это и актуально только для разработчиков, но всё же. В планах создать веб интерфейс для возможности редактирования мира через меню. Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода. Пример https://vimeo.com/523271600
|
|
|
|
Aimed |
18.8.2021, 18:16
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 7778
Пользователь №: 15.607
|
Цитата(nullptr @ 18.8.2021, 16:24) У ModernUO, самый большой плюс современный tcp стек, что значительно снижает пинг при больших обменах(замесы итд), Runtime code generation, хоть это и актуально только для разработчиков, но всё же. В планах создать веб интерфейс для возможности редактирования мира через меню. Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода. Пример https://vimeo.com/523271600Что такое "современный" tcp стек? Очередное модное слово? Я смотрел что он там делает, там по большому счёту микро оптимизации старого кода и небольшие архитектурные оптимизации, которые главных проблем никак не решают. Сервер всю игровую логику на одном потоке обрабатывает, практически никак другие ядра не утилизирует для самых ЦПУ интенсивных задач и никаких планов по этому поводу нету. По крайней мере год назад точно не было. А сегодня уже доступны сервера с 64 ядрами. Глянул я ваш "современный tcp стек", правда бенчмарк тестов я там не увидел, что бы можно было сравнивать "профит" по сравнению со старым кодом. Имхо, совершенно неэффективная трата времени и сплошной фейл в плане идей. Можно было бы в разы, а может и на целый порядок больше профита получить, если добавить в УО протокол концепцию "buffer" пакетов и заимплементить это на сервере, в Орионе, КлассикУО и сделать патч для официального клиента. Вместо того что бы слать каждый пакет по отдельности, как сейчас, и спамить в тех самых замесах или как это делается в Vita-Nex. Можно буферизировать пакеты и высылать их клиентам всегда одной пачкой, одним пакетом и всегда строго по интервалу в Х ms, таким образом сильно стабилизруя нагрузку на сеть, вместо того что бы переделывать старый асинк код и на пару % больше выжимать из железа, по сравнению с тем что было раньше. А может там и вовсе никакого профита нету, потому что бенчмаркинга я так и не нашёл. C# это все таки не плюсы и тут можно запросто получить нежданчик в виде оптимизаций на уровне CLR. А что значит "значительно снижает пинг"? Пинг в основном определяется расстоянием и количеством узлов между сервером и клиентами и он в тысячи раз выше, нежели обработка данных на сервере и отправка пакетов. Если у тебя сервер начинает лагать так что начинаются проблемы с пингом, то у тебя точно проблемы не на уровне сети, а на уровне обработки игровой логики - скриптов. Сервер не справляется с нагрузкой на его основной поток и не может во время выслать пакеты клиентам и в результате все клиенты лагают. Нагрузка на сеть в УО сервере просто микроскопическая ( при условии что там нету идиотизма в скриптах, где на 1 тике 1 клиент спамит всех вокруг кучей пакетов ) по сравнению с нагрузкой на главный поток, к тому же что даже при старом коде все сокеты работали асинхронно.
|
|
|
|
nullptr |
18.8.2021, 19:52
|
Neophyte
Сообщений: 49
Регистрация: 13.3.2021 Группа: Пользователи Наличность: 0
Пользователь №: 19.916
|
Цитата(Aimed @ 18.8.2021, 20:16) Глянул я ваш "современный tcp стек", правда бенчмарк тестов я там не увидел, что бы можно было сравнивать "профит" по сравнению со старым кодом. Имхо, совершенно неэффективная трата времени и сплошной фейл в плане идей. Можно было бы в разы, а может и на целый порядок больше профита получить, если добавить в УО протокол концепцию "buffer" пакетов и заимплементить это на сервере, в Орионе, КлассикУО и сделать патч для официального клиента. Вместо того что бы слать каждый пакет по отдельности, как сейчас, и спамить в тех самых замесах или как это делается в Vita-Nex. Можно буферизировать пакеты и высылать их клиентам всегда одной пачкой, одним пакетом и всегда строго по интервалу в Х ms, таким образом сильно стабилизруя нагрузку на сеть, вместо того что бы переделывать старый асинк код и на пару % больше выжимать из железа, по сравнению с тем что было раньше. А может там и вовсе никакого профита нету, потому что бенчмаркинга я так и не нашёл. C# это все таки не плюсы и тут можно запросто получить нежданчик в виде оптимизаций на уровне CLR.
Проблема даже не в коде, просто собрав проект на .net 5 вместо .net framework(4 - 4.5.2) можно получить до 35% производительности в стандартных операциях. Время .net framework уходит, и скора его можно будет встретить исключительно в интерпрайзе. На каком месте находиться .net core(.net5) по показателю request/per second? Как мы знаем http базируется на tcp. https://www.techempower.com/benchmarks/#sec...;test=plaintextПо поводу того, что Batman, топит за архитектурные решения, его дело. Я понимаю, что для кого-то алокация при использовании string, ничего не значит, но для кого-то нет ничего кроме span.
|
|
|
|
Aimed |
18.8.2021, 23:22
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 7778
Пользователь №: 15.607
|
Цитата(nullptr @ 18.8.2021, 18:52) Проблема даже не в коде, просто собрав проект на .net 5 вместо .net framework(4 - 4.5.2) можно получить до 35% производительности в стандартных операциях. Время .net framework уходит, и скора его можно будет встретить исключительно в интерпрайзе. На каком месте находиться .net core(.net5) по показателю request/per second? Как мы знаем http базируется на tcp. https://www.techempower.com/benchmarks/#sec...;test=plaintextПо поводу того, что Batman, топит за архитектурные решения, его дело. Я понимаю, что для кого-то алокация при использовании string, ничего не значит, но для кого-то нет ничего кроме span. Миграция на net5 - окей, засчитано. До 35% в контексте УО сервера, сильно сомневаюсь, скорее всего прирост есть только в каких-нить супер специфических кейсах, которые больше как приятный плюсик, но в целом просто пшик. А причем тут HTTP протокол? O_o УО сервер не использует HTTP протокол, все летит по TCP. Или это в контексте ваших планов на веб интерфейс для модификации мира? Дык там нагрузка через HTTP просто смехотворной будет, это ж админская утилита. И нет, как раз таки Batman топит за слишком слабые/маленькие архитектурные решения, которые чаще даже просто являются переписыванием кода на новые структуры данных и просто больше похожи на оптимизации/микро оптимизации. Больше работы со стеком, меньше аллокаций и меньше работы для GC. Тот-же span, на который теперь все дрочат, как будто это просто мега открытие из-за которого, внезапно, можно написать очень быстрый код, является просто синтаксическим сахаром. Со стэком, в unsafe контексте можно работать ещё с самого создания C#/.NET. Ещё раз моё мнение: нужно основательнее подходить к данному вопросу, с самого верху, включая клентскую часть, потому что теперь есть Орион и КлассикУО. Даже на старой ранке/сервуо "тупой" производительности больше чем хватает. Тот же Outlands сервер довольно хорошо справился с нагрузками при минимальных изменениях в ядре. А серверов с таким высоким онлайном, скорее всего, больше не будет. Если уж и переделывать что-то настолько основательно, то надо делать это так, что бы модернизация затрагивала УО как игру, а не только сам эмулятор, и на уровне архитектуры позволяла внедрять фичи, которые поднимут геймплей на новый уровень.
|
|
|
|
nullptr |
19.8.2021, 0:01
|
Neophyte
Сообщений: 49
Регистрация: 13.3.2021 Группа: Пользователи Наличность: 0
Пользователь №: 19.916
|
Цитата(Aimed @ 19.8.2021, 1:22) А причем тут HTTP протокол? O_o УО сервер не использует HTTP протокол, все летит по TCP. Или это в контексте ваших планов на веб интерфейс для модификации мира?
Хорошо, давай детально. HTTP реализован на TCP имеет свои заголовки и свой формат передачи, что бы добиться таких цифр req/per second, нужно было переписать полностью работу сокетов. Я повторяюсь TCP(Soscket) .net 4 - 4.5.2 просто ужасны. Цитата(Aimed @ 19.8.2021, 1:22) Даже на старой ранке/сервуо "тупой" производительности больше чем хватает.
Ранка дала жизнь всем другим серверам, это самый большой взнос в комьюнити UO + C#.
|
|
|
|
Aimed |
19.8.2021, 2:34
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 7778
Пользователь №: 15.607
|
Цитата(nullptr @ 18.8.2021, 23:01) Хорошо, давай детально. HTTP реализован на TCP имеет свои заголовки и свой формат передачи, что бы добиться таких цифр req/per second, нужно было переписать полностью работу сокетов.
Я повторяюсь TCP(Soscket) .net 4 - 4.5.2 просто ужасны.
Я выше уже написал: Цитата(Aimed @ 18.8.2021, 22:22) Миграция на net5 - окей, засчитано.
Это и правда хорошо, но если это единственный плюс, то кхм, нахера тогда было создавать ещё один форк ранки? Можно было и её просто перевести на net5. И причем тут опять HTTP протокол? УО не использует HTTP и там может быть не мало оптимизаций и на уровне HttpClient/в хендлерах у эндпоинтов и вообще то что ты кинул, это хендлинг HTTP запросов в веб аппликациях. 1) Если пройтись по твоей же ссылке - там нету данных о перформансе .NET Framework для сравнения. 2)Опять таки, все эти бенчмарки делаются под кейсы с миллионами реквестов под типичное использование фреймворка, а это вполне может означать что значительная часть перформанса была в самом создании коннекшенов для http запросов, а не в передаче данных. В УО серверах не надо постоянно создавать миллионы коннекшенов. Это бесполезный перформанс буст, который в итоге даст чуть больше чем нихера. 3) Самый большой УО сервак - UO Outlands, на пик имел под 2к коннекшенов. Это просто тотальный пшик. Супер модный и современный код пишется, время тратится, а итоговый value чуть больше 0 (IMG: style_emoticons/default/smile.gif) Цитата(nullptr @ 18.8.2021, 23:01) Ранка дала жизнь всем другим серверам, это самый большой взнос в комьюнити UO + C#.
Спасибо кєп, сильное заявление, тем паче на этом то форуме/в рунете, где ранка наименее популярна.
|
|
|
|
nullptr |
19.8.2021, 2:54
|
Neophyte
Сообщений: 49
Регистрация: 13.3.2021 Группа: Пользователи Наличность: 0
Пользователь №: 19.916
|
Цитата(Aimed @ 19.8.2021, 4:34) Только причем тут HTTP протокол? УО не использует HTTP.
RunUO использует socket, если точнее то System.Net.Sockets. WebRequest использует System.Net.Sockets. Ну и образно, на сколько нужно было улучшить System.Net.Sockets в .net 5, чтобы попасть в топ 5 лучших ? Вот Http запрос на сокете, если так будет легче. var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); socket.Connect("127.0.0.1", 80); string GETrequest = "GET / HTTP/1.1\r\nHost: 127.0.0.1\r\nConnection: keep-alive\r\nAccept: text/html\r\nUser-Agent: CSharpTests\r\n\r\n"; socket.Send(Encoding.ASCII.GetBytes(GETrequest));
|
|
|
|
Aimed |
19.8.2021, 3:14
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 7778
Пользователь №: 15.607
|
Цитата(nullptr @ 19.8.2021, 1:54) RunUO использует socket, если точнее то System.Net.Sockets. WebRequest использует System.Net.Sockets.
Ну и образно, на сколько нужно было улучшить System.Net.Sockets в .net 5, чтобы попасть в топ 5 лучших ?
Вот Http запрос на сокете, если так будет легче.
var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp); socket.Connect("127.0.0.1", 80); string GETrequest = "GET / HTTP/1.1\r\nHost: 127.0.0.1\r\nConnection: keep-alive\r\nAccept: text/html\r\nUser-Agent: CSharpTests\r\n\r\n"; socket.Send(Encoding.ASCII.GetBytes(GETrequest));
Это чистая спекуляция уже начинается. Я сверху свой пост отредактировал, посмотри его ещё раз. Там вполне себе реальная ситуация что весь твой перформанс идёт от улучшенного создания коннекшенов и парсинге стрингов, потому что речь тут о ХЕНДЛИНГЕ HTTP запросов, а не в создании самих запросов, как в твоём примере с кодом. И в контексте УО всё это чуть больше чем бесполезно, в плане оптимизации. Я не знаю как тебе это ещё обьяснить. nullptr, почитай как работает HTTP request lifecycle, а потом посмотри УОшный network код ( вот тебе ссылочка ) и скажи мне причем здесь все то что ты тут понаписал? П.С. Я не смотрел исходники самого Socket.cs на .NET Framework и net5 для сравнения, но уверен на 99.9999% что там практически ничего не было улучшено в плане передачи данных. Потому что там попросту НЕКУДА улучшать. В нетворк стрим копируется массив с байтами. В контексте передачи данных этот класс практически напрямую связан с апи самой ОС и просто кормит в ОС все что попадает в его стрим, дальше ОС передаёт данные в сетевую карту и так далее. Поэтому, я УВЕРЕН что весь этот перформанс ( 5е место по твоей ссылке ), это в основном, улучшение работы с самими коннекшенами на уровне эндпоинтов в asp.net core и парсинге хттп стрингов. Что имеет ровно 0 отношения к УО серверам или даже просто апплкациям, где вручную создаётся менеджмент коннекшенов через TcpListener/Async колбэки на сокет обжектах.
|
|
|
|
nullptr |
19.8.2021, 3:25
|
Neophyte
Сообщений: 49
Регистрация: 13.3.2021 Группа: Пользователи Наличность: 0
Пользователь №: 19.916
|
Цитата(Aimed @ 19.8.2021, 5:04) Зачем серверу слать HTTP запросы и главное, кому? Клиентам?
И в контексте УО всё это чуть больше чем бесполезно, в плане оптимизации.
Суть не в том, что ты отправляешь, а чем ты отправляешь, если у шарпа это system.net.sockets, то там хоть письмо, хоть бандероль. Http, буфер, пакеты, один хрен. Ибо всё это в конечном итоге, буфер байтов, которые записывают в сокет. И Ключевой момент будет играть, исключительно реализация socket на конечной платформе. net framework vs .net 5
|
|
|
|
Aimed |
19.8.2021, 4:37
|
Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012 Группа: Пользователи Наличность: 7778
Пользователь №: 15.607
|
Цитата(nullptr @ 19.8.2021, 2:25) Суть не в том, что ты отправляешь, а чем ты отправляешь, если у шарпа это system.net.sockets, то там хоть письмо, хоть бандероль. Http, буфер, пакеты, один хрен.
Ибо всё это в конечном итоге, буфер байтов, которые записывают в сокет.
И Ключевой момент будет играть, исключительно реализация socket на конечной платформе. net framework vs .net 5
Реализация Socket.cs в разных контекстах по разному утилизируется. Если речь о хендлинге миллионов http запросов, то будет дикая нагрузка не только на код по отправке данных, но и на код связанный с созданием и закрытием коннекшенов, потому что так работает HTTP протокол. И я уже, честно говоря, устал это повторять. В УО сервере открытие и закрытие коннекшена это довольно таки редкое явление, в отличии от отправки данных. И это мы ещё не начали говорить о десериализации данных, которая никак не связана с Socket.cs, на который ты так здесь молишься. Попытаюсь тебе другим способом это донести, хотя у меня уже складывается впечатление что я общаюсь с религиозным фанатиком. net framework https://referencesource.microsoft.com/#Syst.../Socket.cs,1306net5 https://github.com/dotnet/runtime/blob/main...Windows.cs#L202Получается что по самой отправке данных вся разница в том что убрали 2 аллокации. Там теперь работа либо полностью на стеке, либо, если вышли за лимит, используется пуллинг. Речь об этих аллокациях. Код WSABuffer[] WSABuffers = new WSABuffer[count]; GCHandle[] objectsToPin = null; objectsToPin = new GCHandle[count]; Что бы этот метод утилизировать, Batman создал класс Pipe<T> https://github.com/modernuo/ModernUO/blob/m...Network/Pipe.csКоторый и возвращает такой массивчик из буфферов. Все таки он частично внедрил буфферизацию пакетов, о которой я говорил в самом начале. Хотя это все равно субоптимальное решение в целом.
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|