Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[🚀 Feature]: Move determination of free network port to driver service itself #14928

Open
nvborisenko opened this issue Dec 21, 2024 · 2 comments

Comments

@nvborisenko
Copy link
Member

Feature and motivation

This is purely related how we start chromedriver.exe (and others) and wait until it is initialized. The current logic is:

  1. Determine free available port on client side
  2. Start chromedriver.exe process on this port
  3. Polling via http to determine when the process becomes able to accept incoming connections on this port

The current logic is expensive and risky. Expensive because of we allocate new OS network connection just to check, risky because of there is "very small" chance that determined available port might be stolen in middleware.

How to improve? We can delegate determination of available port to chromedriver.exe.

c:\Users\Nick\.cache\selenium\chromedriver\win64\128.0.6613.119>chromedriver.exe --port=0
Starting ChromeDriver 128.0.6613.119 (6e439cfca4deda5954b0c74cde9b521c03cb31ad-refs/branch-heads/6613@{#1464}) on port 0
Only local connections are allowed.
Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully on port 50779.

We see ChromeDriver was started successfully on port 50779. where driver found available port itself.

Solution

Don't try to determine available port on client side. Just start the process and get the port, where the service is listening to, via console standard output.

Why

  • We remove "network tools" from selenium code base
  • We fix "race condition" when the same port might be considered as available by several clients (now we are not responsible to do it)
  • We do not allocate OS network connection just to check that "driver.exe is started and ready"

Benchmark

I have quickly implemented new approach and the results on my environment (desktop, pretty fast):

Just to start driver and exit: existing 523.35 ms versus proposed 21.09 ms

Constraints

  • Chrome/Edge driver v128+ only. Old versions don't output port to console.
  • Geckodriver 0.34.0 works, I didn't test older version yet.
  • I didn't test Safari driver yet.

Usage example

Everything stays as before, but faster and safer.

Copy link

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.


Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

@nvborisenko
Copy link
Member Author

It resolves: #14913

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant