Здравствуйте, гость ( Вход | Регистрация )

3 страниц V < 1 2 3 >  
Ответить в эту темуОткрыть новую тему
> Выбор эмулятора
Juzzver
сообщение 3.4.2021, 3:20
Сообщение #21


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



Цитата(Ubu @ 3.4.2021, 0:58) *

хоть убейте, так и не понял чем рануо от сервуо отличается в приниципе, кроме того что сервуо больше контента

Ну тем и отличается (IMG:style_emoticons/default/smile.gif)
Качеством кода отличается.

Если делать ренесанс версию, то нет смысла брать сервуо с её контентом, ибо будет только лишняя нагрузка на производительность и плотные сейвы с параметрами, которые не будут использоваться, + косяки повылазят точно, т.к. там не сильно смотрят под какие эры правки делаются. А с недавних пор они вообще отказались от поддержки ренесанса и начали выпиливать код, так что последние паблиши вовсе негодные под ренесанс версию. Так что тут либо брать предыдущие паблиши (до <= 54 publish), либо вовсе отказаться и взять чистую ранку, где ничего не вылезет, но придется приложить немного руку - чтобы что-то появилось по контенту (IMG:style_emoticons/default/biggrin.gif) Из сервуо всегда можно будет что-то вырвать и перенести на рануо, правда не без крови, т.к. они там уже пишут совсем как попало, количество зависимостей неимоверное теперь.

Если делать максимально по оси что-то, то брать сервуо со всеми их изъянами, благо можно поправить, это будет проще чем писать тонны контента с нуля.


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Ubu
сообщение 3.4.2021, 4:37
Сообщение #22


**

Neophyte
Сообщений: 15
Регистрация: 31.5.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 18.962
Возраст: 32



А подскажите плиз как в CentrEd+ карту сохранить?

изменения не появляются. файлы, которые mul пробовал копировать в папку с сервером и тп, все равно в игре ничего нет. Захожу в CentrEd+ изменения есть.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Ozzy Osbourne
сообщение 3.4.2021, 13:43
Сообщение #23


*********

Grandmaster
Сообщений: 2.067
Регистрация: 5.8.2003
Группа: Пользователи
Наличность: 0
Пользователь №: 810
Возраст: 32



Цитата(Ubu @ 3.4.2021, 0:58) *

хоть убейте, так и не понял чем рануо от сервуо отличается в приниципе, кроме того что сервуо больше контента

RunUO is no longer officially supported by a core team.
If you wish to find support in a wider UO development commuity, visit ServUO - Ultima Online Emulation


--------------------
Forest Wars
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Ubu
сообщение 3.4.2021, 13:54
Сообщение #24


**

Neophyte
Сообщений: 15
Регистрация: 31.5.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 18.962
Возраст: 32



Ozzy, понял, спасибо.

подскажите с CentrEd+, как изменения в игру добавить? второй день е..сь (IMG:style_emoticons/default/sad.gif)
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 3.4.2021, 19:38
Сообщение #25


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



Цитата(Ozzy Osbourne @ 3.4.2021, 13:43) *

RunUO is no longer officially supported by a core team.
If you wish to find support in a wider UO development commuity, visit ServUO - Ultima Online Emulation

RunUO is coming back in 2021....
http://runuo.com/
Цитата
подскажите с CentrEd+, как изменения в игру добавить? второй день е..сь sad.gif

Создай тему в соответствующем разделе, а то каша получается.
https://forum.uokit.com/index.php?showforum=8

Сообщение отредактировал Juzzver - 3.4.2021, 19:40


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Ubu
сообщение 3.4.2021, 20:56
Сообщение #26


**

Neophyte
Сообщений: 15
Регистрация: 31.5.2018
Группа: Пользователи
Наличность: 0
Пользователь №: 18.962
Возраст: 32



Цитата
RunUO is coming back in 2021....

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

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

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

@Juzzver ответь в асю плиз
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Juzzver
сообщение 3.4.2021, 22:40
Сообщение #27


**********

Модератор RunUO
Сообщений: 3.425
Регистрация: 1.11.2008
Группа: Супермодераторы
Наличность: 22565
Из: Северная Корея
Пользователь №: 11.273



Цитата(Ubu @ 3.4.2021, 20:56) *

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

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

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

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


--------------------
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
nullptr
сообщение 18.8.2021, 17:24
Сообщение #28


**

Neophyte
Сообщений: 49
Регистрация: 13.3.2021
Группа: Пользователи
Наличность: 2
Пользователь №: 19.916



Цитата(Juzzver @ 4.4.2021, 0:40) *

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

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

Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода.
Пример
https://vimeo.com/523271600
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 18.8.2021, 18:16
Сообщение #29


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 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 клиент спамит всех вокруг кучей пакетов ) по сравнению с нагрузкой на главный поток, к тому же что даже при старом коде все сокеты работали асинхронно.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
nullptr
сообщение 18.8.2021, 19:52
Сообщение #30


**

Neophyte
Сообщений: 49
Регистрация: 13.3.2021
Группа: Пользователи
Наличность: 2
Пользователь №: 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.

Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
PrintScrin
сообщение 18.8.2021, 22:16
Сообщение #31


****

Apprentice
Сообщений: 106
Регистрация: 2.4.2017
Группа: Пользователи
Наличность: 0
Пользователь №: 18.419



хотел написать aimed тут уже оставил свой пост?

а он уже отписался, шустрый парень...
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 18.8.2021, 22:49
Сообщение #32


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 15.607



Цитата(PrintScrin @ 18.8.2021, 21:16) *

хотел написать aimed тут уже оставил свой пост?

а он уже отписался, шустрый парень...


Завидуешь?
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 18.8.2021, 23:22
Сообщение #33


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 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 сервер довольно хорошо справился с нагрузками при минимальных изменениях в ядре. А серверов с таким высоким онлайном, скорее всего, больше не будет. Если уж и переделывать что-то настолько основательно, то надо делать это так, что бы модернизация затрагивала УО как игру, а не только сам эмулятор, и на уровне архитектуры позволяла внедрять фичи, которые поднимут геймплей на новый уровень.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
nullptr
сообщение 19.8.2021, 0:01
Сообщение #34


**

Neophyte
Сообщений: 49
Регистрация: 13.3.2021
Группа: Пользователи
Наличность: 2
Пользователь №: 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#.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 19.8.2021, 2:34
Сообщение #35


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 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#.


Спасибо кєп, сильное заявление, тем паче на этом то форуме/в рунете, где ранка наименее популярна.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
nullptr
сообщение 19.8.2021, 2:54
Сообщение #36


**

Neophyte
Сообщений: 49
Регистрация: 13.3.2021
Группа: Пользователи
Наличность: 2
Пользователь №: 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));
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 19.8.2021, 3:14
Сообщение #37


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 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 колбэки на сокет обжектах.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
nullptr
сообщение 19.8.2021, 3:25
Сообщение #38


**

Neophyte
Сообщений: 49
Регистрация: 13.3.2021
Группа: Пользователи
Наличность: 2
Пользователь №: 19.916



Цитата(Aimed @ 19.8.2021, 5:04) *

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

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

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

И Ключевой момент будет играть, исключительно реализация socket на конечной платформе.
net framework vs .net 5
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
Aimed
сообщение 19.8.2021, 4:37
Сообщение #39


*********

Grandmaster
Сообщений: 2.250
Регистрация: 29.12.2012
Группа: Пользователи
Наличность: 8846
Пользователь №: 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,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
Который и возвращает такой массивчик из буфферов. Все таки он частично внедрил буфферизацию пакетов, о которой я говорил в самом начале. Хотя это все равно субоптимальное решение в целом.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения
nullptr
сообщение 19.8.2021, 14:23
Сообщение #40


**

Neophyte
Сообщений: 49
Регистрация: 13.3.2021
Группа: Пользователи
Наличность: 2
Пользователь №: 19.916



Цитата(Aimed @ 19.8.2021, 6:37) *

skip
Смотри ты узнал, что-то новое на этом и закончим.

Вот тебе bechmark стандартных операций
https://devblogs.microsoft.com/dotnet/perfo...ments-in-net-5/
Но там сравнение с .net framework 4.8, если брать 4 - 4.5.2 то там все 70% будет.
Пользователь в офлайнеDelete PostОтправить личное сообщение
Вернуться в начало страницы
+Ответить с цитированием данного сообщения

3 страниц V < 1 2 3 >
Ответить в эту темуОткрыть новую тему
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 

- Текстовая версия | Версия для КПК Сейчас: 28.3.2024, 11:26
Designed by Nickostyle