Is it possible to create a Azure Service Fabric External TCP (RPC, WCF, gRPC) Client?

Question

I have a number of TCP-based (Microsoft Graph Engine) Service Fabric services running in both stateless and stateful modes. I've been experimenting, creating a custom external SF client implementation using Graph Engine TCP Client. As my GE/SF Service can push data down to clients we need a persistent connection. I've been playing with ICommunicationClient and ServicePartitonClient and that seems clear enough; however, I am looking for some guidance regarding how to best handle the "ValidateClient" method in my implementation of CommunicationClientFactory. I've studied this reference quite a bit: Communication clients and factories; we already have a working TCP Client that works less service fabric.

My thinking is that I just need to use the SF Client SDK to get a secure connection to the ServicePartiton and the exposed TCP endpoint but it seems that the ASF Reverse Proxy only supports Layer 7 application protocol interactions; so it looks like you can't connect from let's say a WPF app via a TCP (gRPC, WCF, native TCP) socket to an SF service, directly. I'm using a Full Duplex connections with Call-backs and Client-side eventing - what type of network architecture should one use when porting TCP/WCF or gRPC apps and services to ASF?

NOTE: If you are trying to connect to your SF Cluster from an External Client the SF SDK is not going to help you; the Azure SF SDK is for Cluster-side development.

Answer 1

@TaviTruman-4790 Apologies for the delay in response and all the incovinience caused by the issue.

There are a couple options available for load balancing TCP connections to service fabric. You can create a helper discovery service which is available over HTTP. The client application will first connect to the discovery service and retrieve an externally reachable TCP endpoint for one of the instances of your TCP service. The client then connects directly to the TCP service without going through the L7 reverse proxy.

Your discovery service should be Service Fabric aware and implement RegisterServicePartitionResolution ChangeHandler to keep track of the TCP endpoints available.

You can read more about it here.

Another option is to introduce a dedicated L4 reverse-proxy/load-balancer (e.g. nginx, traefik, haproxy) between your client and TCP service. If your TCP service is stateful, this option is trickier as you will need a mechanism to determine the appropriate service endpoint based on partition hash and you need to keep track of any scaling events. For stateful TCP service, you'd need much of the same implementation as the discovery service, but the Service Fabric details would feed into the configuration of the proxy rather than being returned to the client. Traefik has a service fabric plug-in which you might be able to leverage to get you started if you choose to run your L4 reverse-proxy inside the ASF cluster.

Hope it helps.

Please 'Accept as answer' if it helped, so that it can help others in the community looking for help on similar topics.

Answer 2

public System.Threading.Tasks.Task<long> RegisterServiceNotificationFilterAsync (System.Fabric.Description.ServiceNotificationFilterDescription description);