Provide an extra private readonly property on the SignalR HubConnectionContext

[Bond-Addict]

Is there an existing issue for this?

• I have searched the existing issues

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

Currently there is no way for us to know way to calculate size of the payload content sent to signal r.
As confirmed in #59335 (comment)

Not having any mechanism to determine this size makes it very difficult to accurately set the MaximumReceiveMessageSize for SignalR.

Describe the solution you'd like

As we already have a bunch of private readonly properties we can inspect on the HubConnectionContext when we break on the InvalidDataException inside DispatchMessagesAsync while in debug mode with Common Language Runtime Exceptions enabled as shown below.

Please add an additional private readonly property which only contains the buffer length that is used to compare against the maxMessageSize inside

   if (segment.Length > maxMessageSize)
   {
       segment = segment.Slice(segment.Start, maxMessageSize);
       overLength = true;
   }

The ability to understand the message size sent to appropriately adjust the MaximumReceiveMessageSize is highly requested, searched for and mentioned in Stackover and Reddit.

We don't need any sort of mechanism to calculate the payload size programmatically, but we do need a way to know what the MaximumReceiveMessageSize is compared against to ensure we have a large enough ceiling while also not sacrificing performance.

[davidfowl]

@BrennanConroy maybe a reasonable first step here is verbose logging to help people understand payload sizes

[Bond-Addict]

@BrennanConroy maybe a reasonable first step here is verbose logging to help people understand payload sizes

That alone would be really helpful. I've spent many hours going down deep rabbit holes, trying to find a way. I tried every solution i could find from Microsoft or any other blog that talked about SignalR Trace logging and couldn't get any necessary information to come through. I even went as far as cloning each of the Microsoft repos SignalR touches to try and visually step through all the classes and logic to try and get some kind of idea of what it's doing and how it's doing just to try and figure out a way to accurately calculate the payload size myself.

[Bond-Addict]

@davidfowl it's been a couple of weeks. Do you know if @BrennanConroy or any of the other SignalR devs have had a chance to review this?

[davidfowl]

We're on vacation. In the new year.

[Bond-Addict]

We're on vacation. In the new year.

Totally get that. Just trying to keep the Github bot from marking this as stale, not rush yall. Enjoy your time off! 😄

[BrennanConroy]

We don't know the size of the message, the only way to do that would be to parse the oversized message and then throw that work away which kind of defeats the point of having a max size in the first place.

Let me give a silly example:
Imagine the max size is 9 and we receive {"a":"b"}\x1e{"c":"d"}\x1e which happens to be 2 separate messages each of size 10. We'll see that we got 20 bytes and we'll grab a slice of it up to the max size of 9 and pass that on to the parser. Since 9 bytes here isn't a full message it'll fail and all we can tell the app developer is that we tried to parse a message but 9 bytes wasn't enough. If we used the buffer.Length as suggested we would report that we received a 20 byte message from the client.

If you still really want the buffer length and your clients are using WebSockets then there is a trace level log that looks like:

trce: Microsoft.AspNetCore.Http.Connections.Internal.Transports.WebSocketsTransport[9]
Message received. Type: Text, size: 71, EndOfMessage: True.

And for some clients like the browser this is very likely the size of X complete messages where X is likely 1. This is not guaranteed for all clients and can be multiple messages so it can't be completely relied on.