Выбор эмулятора Опции

[Ubu]

Привет!

Если бы вы сейчас запускали новый серв, так сказать, с "чистого листа", какой бы эмуль взяли и почему?

[Ubu]

RunUO is coming back in 2021....

интересно, а что говорят интересного будет? или молчат пока и не факт что будет что-то?) Почему-то мне кажется, что последнее, судя по тому как обычно все происходит...

Создай тему в соответствующем разделе, а то каша получается.

done, извиняюсь)

@Juzzver ответь в асю плиз

[Juzzver]

интересно, а что говорят интересного будет? или молчат пока и не факт что будет что-то?) Почему-то мне кажется, что последнее, судя по тому как обычно все происходит...

Там на сайте ссылка на дискорд, в котором шумиху эту обговаривают. Собралось уже человек 200, из которых многие из старых разработчиков RunUO и просто знатных девов. Из того что сделали - подняли бекап старого сайта со всеми данными, скриптами и прочей инфой.
Что говорят - особо не вникал, и до сих пор вроде активных действий еще не было. Я думаю они размышляют в каком направлении двигаться, читал разговоры про ранку на js фреймворках и прочие идеи, но пока это только разговоры.
Там же есть дев от ModernUO, который уже внес большой вклад в форк ранки, переписывает её уже пару лет под современные технологии, добился хороших показателей в плане оптимизаций, кросфплатформенности и еще ряда решений, так-же еще много планов на пути. Активно отвечает всем заинтересовавшимся его проектом, и есть хорошая вероятность что плоды его работы возьмут для рануо.

@Juzzver ответь в асю плиз

Аськой перестал пользоваться.
Пиши в дискорд или скайп:
Juzzver#6102

[nullptr]

Там же есть дев от ModernUO, который уже внес большой вклад в форк ранки, переписывает её уже пару лет под современные технологии, добился хороших показателей в плане оптимизаций, кросфплатформенности и еще ряда решений, так-же еще много планов на пути. Активно отвечает всем заинтересовавшимся его проектом, и есть хорошая вероятность что плоды его работы возьмут для рануо.

У ModernUO, самый большой плюс современный tcp стек, что значительно снижает пинг при больших обменах(замесы итд), Runtime code generation, хоть это и актуально только для разработчиков, но всё же.

В планах создать веб интерфейс для возможности редактирования мира через меню.

Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода.
Пример
https://vimeo.com/523271600

[Aimed]

У ModernUO, самый большой плюс современный tcp стек, что значительно снижает пинг при больших обменах(замесы итд), Runtime code generation, хоть это и актуально только для разработчиков, но всё же.

В планах создать веб интерфейс для возможности редактирования мира через меню.

Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода.
Пример
https://vimeo.com/523271600

Что такое "современный" tcp стек? Очередное модное слово? Я смотрел что он там делает, там по большому счёту микро оптимизации старого кода и небольшие архитектурные оптимизации, которые главных проблем никак не решают. Сервер всю игровую логику на одном потоке обрабатывает, практически никак другие ядра не утилизирует для самых ЦПУ интенсивных задач и никаких планов по этому поводу нету. По крайней мере год назад точно не было. А сегодня уже доступны сервера с 64 ядрами.

Глянул я ваш "современный tcp стек", правда бенчмарк тестов я там не увидел, что бы можно было сравнивать "профит" по сравнению со старым кодом. Имхо, совершенно неэффективная трата времени и сплошной фейл в плане идей. Можно было бы в разы, а может и на целый порядок больше профита получить, если добавить в УО протокол концепцию "buffer" пакетов и заимплементить это на сервере, в Орионе, КлассикУО и сделать патч для официального клиента. Вместо того что бы слать каждый пакет по отдельности, как сейчас, и спамить в тех самых замесах или как это делается в Vita-Nex. Можно буферизировать пакеты и высылать их клиентам всегда одной пачкой, одним пакетом и всегда строго по интервалу в Х ms, таким образом сильно стабилизруя нагрузку на сеть, вместо того что бы переделывать старый асинк код и на пару % больше выжимать из железа, по сравнению с тем что было раньше. А может там и вовсе никакого профита нету, потому что бенчмаркинга я так и не нашёл. C# это все таки не плюсы и тут можно запросто получить нежданчик в виде оптимизаций на уровне CLR.

А что значит "значительно снижает пинг"? Пинг в основном определяется расстоянием и количеством узлов между сервером и клиентами и он в тысячи раз выше, нежели обработка данных на сервере и отправка пакетов. Если у тебя сервер начинает лагать так что начинаются проблемы с пингом, то у тебя точно проблемы не на уровне сети, а на уровне обработки игровой логики - скриптов. Сервер не справляется с нагрузкой на его основной поток и не может во время выслать пакеты клиентам и в результате все клиенты лагают. Нагрузка на сеть в УО сервере просто микроскопическая ( при условии что там нету идиотизма в скриптах, где на 1 тике 1 клиент спамит всех вокруг кучей пакетов ) по сравнению с нагрузкой на главный поток, к тому же что даже при старом коде все сокеты работали асинхронно.

[nullptr]

Глянул я ваш "современный 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]

Проблема даже не в коде, просто собрав проект на .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]

А причем тут HTTP протокол? O_o УО сервер не использует HTTP протокол, все летит по TCP. Или это в контексте ваших планов на веб интерфейс для модификации мира?

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

Я повторяюсь TCP(Soscket) .net 4 - 4.5.2 просто ужасны.

Даже на старой ранке/сервуо "тупой" производительности больше чем хватает.

Ранка дала жизнь всем другим серверам, это самый большой взнос в комьюнити UO + C#.

[Aimed]

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

Я повторяюсь TCP(Soscket) .net 4 - 4.5.2 просто ужасны.

Я выше уже написал:

Миграция на net5 - окей, засчитано.

Это и правда хорошо, но если это единственный плюс, то кхм, нахера тогда было создавать ещё один форк ранки? Можно было и её просто перевести на net5.

И причем тут опять HTTP протокол? УО не использует HTTP и там может быть не мало оптимизаций и на уровне HttpClient/в хендлерах у эндпоинтов и вообще то что ты кинул, это хендлинг HTTP запросов в веб аппликациях.
1) Если пройтись по твоей же ссылке - там нету данных о перформансе .NET Framework для сравнения.
2)Опять таки, все эти бенчмарки делаются под кейсы с миллионами реквестов под типичное использование фреймворка, а это вполне может означать что значительная часть перформанса была в самом создании коннекшенов для http запросов, а не в передаче данных. В УО серверах не надо постоянно создавать миллионы коннекшенов. Это бесполезный перформанс буст, который в итоге даст чуть больше чем нихера.
3) Самый большой УО сервак - UO Outlands, на пик имел под 2к коннекшенов. Это просто тотальный пшик. Супер модный и современный код пишется, время тратится, а итоговый value чуть больше 0 (IMG:style_emoticons/default/smile.gif)

Ранка дала жизнь всем другим серверам, это самый большой взнос в комьюнити UO + C#.

Спасибо кєп, сильное заявление, тем паче на этом то форуме/в рунете, где ранка наименее популярна.

[nullptr]

Только причем тут 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]

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]

Зачем серверу слать HTTP запросы и главное, кому? Клиентам?

И в контексте УО всё это чуть больше чем бесполезно, в плане оптимизации.

Суть не в том, что ты отправляешь, а чем ты отправляешь, если у шарпа это system.net.sockets, то там хоть письмо, хоть бандероль.
Http, буфер, пакеты, один хрен.

Ибо всё это в конечном итоге, буфер байтов, которые записывают в сокет.

И Ключевой момент будет играть, исключительно реализация socket на конечной платформе.
net framework vs .net 5

[Aimed]

Суть не в том, что ты отправляешь, а чем ты отправляешь, если у шарпа это 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,1306

net5 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
Который и возвращает такой массивчик из буфферов. Все таки он частично внедрил буфферизацию пакетов, о которой я говорил в самом начале. Хотя это все равно субоптимальное решение в целом.