Add a network port pool concept for allocating discrete service ports
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- go
- Domain
- backend, networking
Research direction
Start by reviewing the linked Aspire issue 9919 and the DCP executable port-allocation entry point. Work out the performance of searching a configurable non-ephemeral range, a reasonable default range, and support for exclusion lists. Done means executables receive ports from the pool while avoiding the stated conflict scenarios.
Written by the indexing model from the issue text.
Description
We recently tracked a long running Aspire issue (https://github.com/dotnet/aspire/issues/9919) down to just-in-time ephemeral port conflicts in a specific environment. Effectively in the time between us determining a specific ephemeral port was free and a service launching using that port, some other socket connection on the machine temporarily reserved the port in question. As the port was unused when checking the networking results immediately after the conflict, the likely cause is outgoing network connections as they also consume a port from the ephemeral range.
One option to avoid this issue would be to implement effectively our own internal port pool. We would take a (configurable) range of non-ephemeral ports and identify unused ports in the range to assign to Executables. This would force us to take on some of the work that ephemeral ports provide in identifying an unspecified available port, but the only way we'd encounter a conflict is if another socket on the machine was explicitly assigned the same port in a very short window of time, which is much less likely than an ephemeral port collision.
Main things to work out is performance impacts of searching ports, what would be a reasonable default range, and how we want to allow port ranges to be configured (we at least should support exclusion lists) to avoid conflicts with other services that might need specific ports.
- Dominant language
- Go
- Stars
- 191
- Forks
- 24
- Avg merge
- 22h 49m
- Merged PRs (30d)
- 23
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from microsoft/dcp
-
Add application iconOpen
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
microsoft/dcp#286 · 4 comments ·
Maintainers usually reply within 1 day
-
Disable DeleteCollection for DCP resourcesPossibly taken @TJ2005 claimed this 1 day ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
microsoft/dcp#206 · 2 comments · 1 reaction ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
prime-radiant-inc/evener#4223 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
open-telemetry/opentelemetry-go-compile-instrumentation#1467 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
yetone/magpie#1490 · 1 comment ·
Maintainers usually reply within 1 day
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
a:bug
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
gotify/server#1068 · 1 reaction ·
Maintainers usually reply within 2 days