Search code examples
c#signalrasp.net-core-signalr

How correct sending large classes via SignalR?

I have a client-server application: server, regular client and admin. Clients periodically send information to the server, and it redirects it to the admin. The admin can request information from clients.

I have a collection of a class and inside this class there are 2 other collections and inside them there are several more collections. At one point I ran into the problem that Signal has a 32kb transmission limit by default, which I increased through the method just below.

services.AddSignalR(o =>
{
    o.MaximumReceiveMessageSize = null;
});

Everything is working now, but I don't like it. I searched for similar questions and found 2 solutions:

  1. The client splits each object being sent into an array of bytes. SignalR saves the received chunk and as soon as all the parts are received, converts byte[] to our IReadOnlyCollection type.
SendData(byte[] chunk, int pos, int total)

I took into account the information that SignalR does not guarantee the sequence of receiving messages and added a pos - the current position. As soon as the server has received all the parts, successfully converted them to our type, then it starts sending these parts to the admin.

The admin receives byte[] and as soon as he has received them all, he converts them to our type himself.

  1. Many people say that Signal is not about sending files. But is a collection of classes of size 10, 100 or > 1000 KB considered a file?

After studying their advice, I came up with the following scheme. A regular client sends data via a regular post request. On the server, the controller (which received this data from the client) sends a message to the admin that "hey, I got the data and you can request it from me." The admin sends a get request and receives the data.

That is, completely change the scheme of interaction between all clients and the server, even if the information being sent is one class for 5 properties with a size of 10-20 bytes.

Which solution is correct or maybe there are others?

Solution

  • I'd recommend going with the second solution (HTTP POST + SignalR Notification).

    Here's Reason

    1. SignalR is primarily designed for real-time communication, rather than for transferring large amounts of data.

    2. As jdweng mentioned, in terms of data transmission, using HTTP has more advantages. As the demand increases, whether compression, streaming or more complex error handling mechanisms are introduced, HTTP can handle it well.

    3. In addition, assuming that Azure Signalr is not used, when there are many user connections, assuming that each connection has data transmission requirements, if the service does not expand the instance, you will soon encounter server performance problems, so the first option is not suitable.