Hi Dojo - evaluating evolutions from the legacy SLNet towards gRPC and I'd like to check if the following could be a viable transition to get started:
- Cube → DMA = gRPC (for any server in the cluster)
- DMA ↔ DMA = existing SLNet communication
From this page, I understand that
so I'm wondering if gRPC is used for auto-forwarding events from the server to the client or if the client is still expected to request updates (e.g. as in SLNet polling mode).
In a big cluster environment where storm modes can be expected, I'd like to avoid the overhead of "polling" that slows down the client considerably - .NET Remoting with eventing would be the preferred mode pre-gRPC migrations, but any steer will be helpful.
Thanks
Hi Alberto,
One thing that might already help clarify part of the picture: in recent Cube versions there’s an automatic switch to gRPC when you connect to a cloud setup.
So if the host is a cloud relay (anything ending in .dataminer.services), Cube will force gRPC, even if you explicitly selected something like Remoting. The reason is simply that cloud-connected agents don’t support .NET Remoting at all, so this guarantees the connection actually works.
For the other part of your question (eventing vs polling): this change is really just about how the connection is established. It doesn’t provide details yet on whether gRPC is already behaving like push/eventing or still follows a request-driven model internally.
Hope this helps a bit to position your migration approach