Hi Alberto,

Here is a comparsion of .NET Remoting and gRPC:

• .NET Remoting with eventing can deliver subscription messages instantly, but requires setting up a TCP connection from DMA to client, which is often not possible due to firewalls or NAT.
• .NET Remoting with polling uses "short polling", where the waiting happens on the clientside and the server answers immediately (either with some messages that were waiting to be delivered, or with an empty response). It is basically a tradeoff on how frequently the client will spam the server and how much extra delay you can tolerate for messages to be delivered. By default we have a slow polling cycle of 1000ms and a fast polling cycle of 100ms if the previous cycle received messages.
• In gRPC streaming the client performs a single HTTP request with an infinite response: the server uses "Transfer-Encoding: chunking" and delivers messages as soon as they occur, each in another chunk. However, this does not always work if there is a (reverse) proxy, gateway or deep-packet-inspecting firewall inbetween. These may either transform the random chunk sizes into fixed-length chunks, or buffer the chunking to try and convert it into a Content-Length response, or it may abort requests that take longer than x seconds. We have a detection mechanism for this, and if chunking is not working as expected, we fall back to polling (see next).
• gRPC with polling uses "long polling", where the waiting happens on the serverside. The client has an infinite loop of HTTP requests, and the server will wait up to 20 seconds until it has messages ready to be delivered. The advantage here is that there is no extra delay introduced as with "short polling", and that it does not rely on special HTTP features such as chunking or infinite responses. All subscription requests are typically pipelined on the same TCP connection, although that is not guaranteed (depends on the .NET HTTP connection pooling logic). Long polling is also used for Remote Cube access through *.on.dataminer.services.

Important to note is that we are using gRPC-web over HTTP/1.1 as opposed to "native" gRPC over HTTP/2 (where all traffic can be multiplexed over a single TCP connection) because we cannot yet guarantee support on all systems. (see https://learn.microsoft.com/en-us/aspnet/core/grpc/supported-platforms?view=aspnetcore-10.0 - mainly support for Windows Sever 2016/2019 and .NET Framework 4.x for clients such as Cube prevent the use of HTTP/2).

Let me know if you have any further questions.