How does Service Fabric Choose a Port to Host a Service on?

Question

I am in the middle of implementing GRPC on top of Service Fabric in C#. The GRPC Server requires a ServerPort (in charge of binding ssl credentials to a port) and a Service Definition (in charge of mapping requests on a path to a method delegate). I made a Communication Listener which reports the partition and replica ids along with the FQDN:port. This allows the client to correctly ensure its talking to the right partition/replica. I declared an Endpoint resource in the service mainifest and left the port blank to indicate that I want service fabric to assign a random port. My problem in local development (i haven't pushed this out to a cluster in azure yet) is that the replicas appear to die because they are assigned the same port. I should also note that I am telling the listener to listen on the secondary replicas.

My Question is:

1. How does service fabric choose a port to host a service replica at?
2. Is the port sharing problem for secondary replicas only a problem for local development where I am physically on the same machine? (I would assume that a replica in a real cluster will be placed on a different fault/upgrade domain)

Answer 1

Service Fabric reserves an application port range which is defined in your cluster settings (in your Resource Manager template if you're hosting in Azure). When you leave the port blank in the Endpoint resource as you did, SF will pick a port from this range that has not already been assigned to another service on the machine.

The important thing to note though is that the port allocation is per host process, and the default host process mode is shared host process, where replicas of the same service type can share a host process. In that case, replicas in the same host process will get the same port.

There are a couple ways to deal with this:

1. Use a networking stack that supports port sharing. On Windows, you have the Windows HTTP Server API (used by HttpListener and anything built on top of it, such as Katana) and WCF.
2. Use exclusive host processes instead, in which case every replica gets its own host process and therefore its own unique port. Process isolation also has a number of other benefits (e.g., if a replica crashes the host process, it doesn't bring down other replicas with it) at the cost of increased resource consumption on the machine.