This is an extremely simple reproduction of gRPC concurrent connection behavior in dap vs. vanilla ASP.NET communications. After cloning the repository, you can run the client code with connections established through dapr sidecars or using direct gRPC communication between ASP.NET client and server services.
The two variables in the following screenshot can be adjusted in docker-compose.yml to switch use cases or adjust the environment for proper addressing. For Windows-based Docker Destkop installations, the localhost addressing may not work consistently, and the USE_DOCKER_ADDRESS should be set to 1. Otherwise, set to 0. Use case switching is accomplished by changing USE_DAPR from 1 (dapr-based) to 0 (ASP.NET native).
Default configuration is to use Windows-based (kubernetes.internal.docker) addressing for non-dapr use cases and to use the dapr-based communication ports.
To run the dapr-based use case:
- Set the
USE_DAPRvariable indocker-compose.ymlto 1 - Run
docker-compose up -d
To run the ASP.NET use case:
- Set the
USE_DAPRvariable indocker-compose.ymlto 0 - Run
docker-compose up -d
View the concurrent connection management behavior either in the client or server logs. grpc-server logs will indicate how many concurrent streams are being served. The code in grpc-client will also echo the total stream count from the server.
In the dapr-based communication, the concurrent streams are capped at 100, which is the limit of a single HTTP2 connection. Sidecars are expected to open new HTTP2 connections when the concurrent stream limit is reached, but this does not seem to be occurring. The expected behavior is seen in the ASP.NET use case, where the (adjustable) total of 350 concurrent streams is successfully opened and maintained.
I personally just tail the grpc-server container log and toggle the USE_DAPR between 0 and 1, running docker-compose up -d to see the different concurrent stream behavior. It's stable on one PC, I hope others can rerun as easily. I have not built a local dapr sidecar to try to investigate where the connection cap is occurring.