Enable compression on blazorpack

[tag5]

Is your feature request related to a problem? Please describe.

I have inspect websocket messages on a very basic blazorserver application.
I have tried for example to set a textbox value to "Helloworld" when user clicks on a button.
Server sends about 300bytes to browser for applying helloworld to textbox.
I am working with a third party component for a Grid. Displaying 200 rows with 3 text columns costs about 600kbytes.
I have inspect packet and there is a lot of strange data on the top of the packet. I think this can be compressed.

Describe the solution you'd like

Blazorpack only allows text and binary format. I think it will be a good thing to allow on-the-fly compression of blazorpack messages

[javiercn]

@tag5 thanks for contacting us.

We've been thinking about this, however there are security implications about turning on websocket compression and dynamic content (CRIME, BREACH and related attacks) and we are still working on understanding the security concerns for Blazor server.

Until we have a clear picture we won't make a decision on whether we enable folks to to turn it on and off and whether we turn it on/off by default.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[tag5]

Thanks for your answer. I think there is an optimization issue in blazorpack. I have tried to inspect messages and volume is very huge. I would like to try to find a solution in order to optimize this.

• Is there a way to enable compression by another way (on kestrel for example)

• Do you know a way for me to hook BlazorPackHubProtocolWorker Serialize/DeserializeObject methods ? Or Is there a way to put my own custom protocol instead of blazorpack, without changing anything in blazor source code ? Thanks

[javiercn]

@tag5 we would recommend that you start by using the Virtualize component to minimize the size of the data as a starting point, that will get you far better results than enabling compression.

I know there's support for websocket compression added in .NET 6.0, however I'm not familiar with the details on how to operate it.

We don't offer extensibility to the Blazor transport protocol, we don't guarantee we won't change it and break it in the future.

[tag5]

Don't worry about that: I am working with Virtualization components. But it is not enough.
I am also working with third party components (Telerik) but i am not sure this components are optimized. I would like to inspect what they send on the websocket channel. Do you know a simple way for me to inspect and decode blazorpack messages in a development environment ? (this is why i am asking how can i hook BlazorPackHubProtocolWorker, it is just for studying message content). Thanks

[javiercn]

@tag5 unfortunately I don't think there is a straightforward way.

We normally don't operate at that level of abstraction.

The best I can think of is to capture the network traffic somehow and run the appropriate pieces through a copy of blazorpack, however I anticipate that's no small feat.

[tag5]

Okay thanks.
It's unfortunate that nobody cares about network data volume optimization...

[javiercn]

@tag5 we do care, and we've done due diligence to optimize things where possible and continue to work on it.

We simply don't have a ready to go protocol analyzer for going deep into the protocol details, as it is not something we normally need.

If you want to get a better understanding of the reasons why your data is so big, I would start by debugging the framework sources alongside your code to understand how many components are being re-rendered on each render batch and the size of the render trees generated by each of those components.

[tag5]

I don't have source of the third party component.
I would like to decode BlazorPack messages in order to understand what they contain.
I can't intanciate BlazorPackHubProtocol because it is an internal class. Do you have any clue or idea for how decoding such message ? Thanks a lot

[javiercn]

I can't intanciate BlazorPackHubProtocol because it is an internal class. Do you have any clue or idea for how decoding such message ? Thanks a lot

Blazorpack is just message pack, in any case you can copy the code from the repo into your own project to parse and inspect any message.

[tag5]

I have tried to decode with a basic messagepack tool but it was not working. Blazorpack is exactly the same thing than messagepack or are there some specifc implementations ? Thanks

[javiercn]

I believe it's just message pack, with a different protocol name for signalr purposes

[tag5]

Strange: If you look at BlazorPackHubProtocolWorker.cs, you can see a part of a (de)serialization implementation which does not look like to MessagePack.
Another question, do you think i can intercept Messages in an "object" format if i create a custom circuit class ?
Thanks

[javiercn]

@tag5 no, we don't expose any of the protocol details.

Your best bet is to

1. Debug through the ASP.NET Core sources
2. Copy the code, capture the traffic on chrome network tab (somehow) and try and decode it.

[tag5]

I have tried 2 but impossible to decode; I have tried python msgpack library and i have errors:
"invalid continuation byte", "msgpack.exceptions.ExtraData: unpack(b) received extra data." So i think this is not msgpack...
Thanks
Your idea 1 is very very hard

[BrennanConroy]

The messagepack payload is prefixed with a length, see https://github.com/dotnet/aspnetcore/blob/main/src/SignalR/docs/specs/HubProtocol.md#binary-encoding for details on how to decode it

[tag5]

@javiercn : You said i can debug through the ASP.Net Core sources. I have downloaded and compile aspnetcore source code from github. How can i create a blazorserver project and make sure this project is working with my local aspnetcore version instead of nuget ones ? Should i create a project in the same sln than aspnetcore source ? Do you think it is possible to set a breakpoint in aspnetcore source ? Thanks

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[kulogix]

I’ve previously attempted (didn’t get very far) creating a Python library for socket-level load testing of Blazor server apps for use with Locust. As far as I know there is no public solution (FOSS or commercial) that appropriately handles persistent WebSockets, is easily able to establish and manage the SignalR session, and appropriately decode and encode blazorpack (msgpack with the payload length leading bytes and multi-part message splitting).

Any official assistance, even more complete/consolidated documentation, on the implementation details / spec would be extremely helpful.

Without appropriate load testing tools (scalable to hundreds of thousands of sessions - not feasible/economical with browser automation tools like Selenium or Playwright), Blazor Server will remain an unlikely choice for most enterprises - except those that take the time to create their own low-level load testing tools, like I tried (and still need to complete).

[tag5]

@kulogix I have also tried to put some hooks inside blazor server source code (dotnet core)
My goal was to understand the reason of this big amount of data in blazorpack messages.
But i am running out of time...

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.