This seems to say that is is always necessary otherwise you may resolve an incorrect service -- as there is no guarantee that services won't move around etc...
The default asp.net core service template uses
UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
Is there a reason for this? When is it okay to not use the ServiceFabricIntegration middleware?
E: I see these are actually a flags enum. So likely you should always use UseUniqueServiceUrl https://github.com/Azure/service-fabric-aspnetcore/blob/develop/src/Microsoft.ServiceFabric.AspNetCore/WebHostBuilderServiceFabricExtension.cs
Respectfully, I don't think you have read the docs well enough. It is well explained here:
Services that use a dynamically-assigned port should make use of this middleware.
Services that use a fixed unique port do not have this problem in a cooperative environment. A fixed unique port is typically used for externally-facing services that need a well-known port for client applications to connect to. For example, most Internet-facing web applications will use port 80 or 443 for web browser connections. In this case, the unique identifier should not be enabled.
So summarized: when using Kestrel or WebListener you can choose to use a dynamic port or a fixed port. See the sections Use WebListener/Kestrel with a static port and Use WebListener/Kestrel with a dynamic port in the mentioned link. When you opt to use a dynamic port use ServiceFabricIntegrationOptions.UseUniqueServiceUrl, otherwise use ServiceFabricIntegrationOptions.None as the parameter for the middleware.
Now, as of the why you need this unique service url middleware in case of a dynamic port, there is a scenario that describes the possible problem:
If services use dynamically-assigned application ports, a service replica may coincidentally use the same IP:port endpoint of another service that was previously on the same physical or virtual machine. This can cause a client to mistakely connect to the wrong service. This can happen if the following sequence of events occur:
- Service A listens on 10.0.0.1:30000 over HTTP.
- Client resolves Service A and gets address 10.0.0.1:30000
- Service A moves to a different node.
- Service B is placed on 10.0.0.1 and coincidentally uses the same port 30000.
- Client attempts to connect to service A with cached address 10.0.0.1:30000.
- Client is now successfully connected to service B not realizing it is connected to the wrong service.
This can cause bugs at random times that can be difficult to diagnose