Лучше бы вернули в студию UML дизайнер с возможностью создания экземпляров (было в 2010 студии кажись)
и наконец пофиксили интерактив для шапровых корковых проектов.
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Serginio1, Вы писали:
S>>Используй UWP там .Net Native!
vaa>Мне вот другое не понятно. Акиньшин из джетбрэйнса работает над микрооптимизацией ядра. vaa>Со всех утюгов кричат мы апнули перформанс сильно в новой версии корки. теперь уже просто НЕТ. vaa>Так объясните почему стартует аналогичная по функционалу прога(типа привет мир) сильно медленнее(заметно без секундомера) vaa>старого классического фрэймворка заточенного под винду? да впф и в классике на слабом железе заставлял нервничать, но сейчас! с ссд стартует аналог vaa>просто позорно медленно. у нас же восхитительный перформанс основанный на агрессивных оптимизациях. vaa>!щёрт подери! vaa>на линуксе обратил внимание что сначала стартует хост-процесс, и затем уже процесс приложения. но неужели так сложно загрузить несколько сборок. vaa>Что не так? причем обрезание и редитуран все еще глючит и непонятно что дает кроме увеличения времени сборки
Здравствуйте, Serginio1, Вы писали:
vaa>> редитуран S> Кстати не пробовал R2R
Если это вопрос? то пробовал, то ли само то ли совместо с обрезанием оно либо совсем не стартует либо никакого effect
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Serginio1, Вы писали:
vaa>>> редитуран S>> Кстати не пробовал R2R vaa>Если это вопрос? то пробовал, то ли само то ли совместо с обрезанием оно либо совсем не стартует либо никакого effect
Спасибо. А .Net 6 не пробоал?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vaa, Вы писали:
vaa>Здравствуйте, Serginio1, Вы писали:
S>>Спасибо. А .Net 6 не пробоал? vaa>Смысл? релиз осенью. подождем.
Ну ветка то про новости .Net 6
и солнце б утром не вставало, когда бы не было меня
gRPC-Web и потоковая передача
Традиционный API gRPC по HTTP/2 поддерживает потоковую передачу во всех направлениях. gRPC-Web имеет ограниченную поддержку потоковой передачи:
Клиенты браузера с gRPC-Web не поддерживают вызов методов потоковой передачи клиента и двунаправленной потоковой передачи.
Службы gRPC в ASP.NET Core, размещенные в Службе приложений Azure и IIS, не поддерживают двунаправленную потоковую передачу.
При использовании gRPC-Web мы рекомендуем применять только унарные методы и методы серверной потоковой передачи.
Вызов gRPC-Web из браузера
Приложения браузера могут использовать gRPC-Web для вызова служб gRPC. При вызове служб gRPC с помощью gRPC-Web из браузера существует ряд требований и ограничений.
Сервер должен быть настроен для поддержки gRPC-Web.
Потоковая передача клиента и вызовы двунаправленной потоковой передачи не поддерживаются. Потоковая передача сервера поддерживается.
Для вызова служб gRPC в другом домене требуется настроить CORS на сервере.
S>gRPC-Web и потоковая передача
S>Традиционный API gRPC по HTTP/2 поддерживает потоковую передачу во всех направлениях. gRPC-Web имеет ограниченную поддержку потоковой передачи:
S>Клиенты браузера с gRPC-Web не поддерживают вызов методов потоковой передачи клиента и двунаправленной потоковой передачи.
S>Службы gRPC в ASP.NET Core, размещенные в Службе приложений Azure и IIS, не поддерживают двунаправленную потоковую передачу.
S>При использовании gRPC-Web мы рекомендуем применять только унарные методы и методы серверной потоковой передачи.
S>Вызов gRPC-Web из браузера
S>Приложения браузера могут использовать gRPC-Web для вызова служб gRPC. При вызове служб gRPC с помощью gRPC-Web из браузера существует ряд требований и ограничений.
S>Сервер должен быть настроен для поддержки gRPC-Web.
S>Потоковая передача клиента и вызовы двунаправленной потоковой передачи не поддерживаются. Потоковая передача сервера поддерживается.
S>Для вызова служб gRPC в другом домене требуется настроить CORS на сервере.
что то мутное — надо самому что то реализовывать. В SignalR ничего такого не надо — оно само перезапускает всё с самого начала (handshake) если соединение оборвалось где то например на роутете. или ПК заснул+проснулся
Здравствуйте, VladCore, Вы писали:
VC>что то мутное — надо самому что то реализовывать. В SignalR ничего такого не надо — оно само перезапускает всё с самого начала (handshake) если соединение оборвалось где то например на роутете. или ПК заснул+проснулся
Здравствуйте, Serginio1, Вы писали:
VC>>что то мутное — надо самому что то реализовывать. В SignalR ничего такого не надо — оно само перезапускает всё с самого начала (handshake) если соединение оборвалось где то например на роутете. или ПК заснул+проснулся
S> Ну gRPC достаточно новая технология по сравнению и WebSocket, но достаточно перспективная.
а в вики лень посмотреть? gRPC появился за год до .NET Core
На мой скромный взгляд нужно прежде всего отказаться от zlib вообще.
Она крайне долго жмет и ужасно расточительна по современным меркам (речь о скрытых аллокациях в нэйтиве, но менеджед реализация стрима тоже... доставляет), когда речь не идет о сжатии потоков данных, а малых сообщений какой-то вменяемой длины. Аллокация кодировщика стоит около 60Кб. Какой-либо вменяемой абстракции для этого нет.
К примеру libdeflate — просто рвет оригинал по всем показателям, можно легко использовать tls-кодировщики каждый из которых будет "самообучаем", что далеко не всегда хорошо, но приемлимо.
Ну собственно использовать можно что угодно, лиж бы это как-то кастомизировалось без аллокации на дополнительный стрим, иначе оно вообще не нужно.
***
Я, например, не хочу видеть неотключаемую валидацию входящего текстового сообщения в клиентском вебсокете, на то что это валидный utf8 — а это там есть. Спасибо, но мне виднее как разобрать входящий набор байт (и читает он байты).
Вместе с тем современный клиентский вебсокет (net5+, может и 3.1) — вот сделан нормально. Синхронизация на посылке завершенного сообщения (одним блоком) — не нужна — внутри она есть бесплатно. А 2.0 и раньше — там же код от лучших планокуров был.
Здравствуйте, Mystic Artifact, Вы писали:
VC>>вот тут пишут что они сами не могут добавить его без ихменений в asp.net и стоит milestone 6.0.0: https://github.com/dotnet/runtime/issues/31088
MA> На мой скромный взгляд нужно прежде всего отказаться от zlib вообще.
MA> Она крайне долго жмет и ужасно расточительна по современным меркам (речь о скрытых аллокациях в нэйтиве, но менеджед реализация стрима тоже... доставляет), когда речь не идет о сжатии потоков данных, а малых сообщений какой-то вменяемой длины. Аллокация кодировщика стоит около 60Кб. Какой-либо вменяемой абстракции для этого нет.
MA> К примеру libdeflate — просто рвет оригинал по всем показателям, можно легко использовать tls-кодировщики каждый из которых будет "самообучаем", что далеко не всегда хорошо, но приемлимо.
MA> Ну собственно использовать можно что угодно, лиж бы это как-то кастомизировалось без аллокации на дополнительный стрим, иначе оно вообще не нужно.
MA> ***
MA> Я, например, не хочу видеть неотключаемую валидацию входящего текстового сообщения в клиентском вебсокете, на то что это валидный utf8 — а это там есть. Спасибо, но мне виднее как разобрать входящий набор байт (и читает он байты).
MA> Вместе с тем современный клиентский вебсокет (net5+, может и 3.1) — вот сделан нормально. Синхронизация на посылке завершенного сообщения (одним блоком) — не нужна — внутри она есть бесплатно. А 2.0 и раньше — там же код от лучших планокуров был.
нелюбовь именно к zlib это конечно интереснй случай. но это тут каким боком? перечитай цитату чтоле.
Здравствуйте, VladCore, Вы писали:
VC>нелюбовь именно к zlib это конечно интереснй случай. но это тут каким боком? перечитай цитату чтоле.
К zlib у меня нет нелюбви. Оно просто морально устарело и не развивается. Тут тогда скорее нелюбовь к deflate должна быть, т.к. именно алгоритм является сдерживающим фактором к в 10х/100х большей пропускной способности на серверной/клиентской стороне (сжатие/распаковка, но это уже надо смриться).
Цитату я прочитал, и лишь сказал, что страдают от этого не только вебсокеты. Обычный GZipStream стрим — это трэш. Было бы хорошо, если бы это было сделано более аккуратно. Это далеко не все недочеты. CBOR формально есть в фреймворке — но это не более чем игрушка. Использовать это для чего-либо хоть как-то нагруженного — категорически вредно.
Здравствуйте, Mystic Artifact, Вы писали:
VC>>нелюбовь именно к zlib это конечно интереснй случай. но это тут каким боком? перечитай цитату чтоле.
MA> К zlib у меня нет нелюбви. Оно просто морально устарело и не развивается. Тут тогда скорее нелюбовь к deflate должна быть, т.к. именно алгоритм является сдерживающим фактором к в 10х/100х большей пропускной способности на серверной/клиентской стороне (сжатие/распаковка, но это уже надо смриться).
MA> Цитату я прочитал, и лишь сказал, что страдают от этого не только вебсокеты. Обычный GZipStream стрим — это трэш. Было бы хорошо, если бы это было сделано более аккуратно. Это далеко не все недочеты. CBOR формально есть в фреймворке — но это не более чем игрушка. Использовать это для чего-либо хоть как-то нагруженного — категорически вредно.
в SignelR вообще нет сжатия. где там сжатие увидел? и WebSocket в .NET от GZipStream не страдают. ты о чем?
