Increase TCP buffer size for the chrome instance listening at a port.

[sravani93]

• I have created a chrome instance at a port(9222)
• My application makes multiple simultaneous connections with the chrome instance.(close to 150 at a time).
• I'm running into the following error - "request_sock_TCP: Possible SYN flooding on port 9222. Sending cookies. Check SNMP counters."
• Is there a way to increase the TCP backlog buffer size(set for the socket when the 'listen' sys call is made) of the chrome instance listening at port 9222 ?

Component	Version
Operating system	Debian GNU/Linux buster/sid
Node.js	v8.4.0
Chrome/Chromium/...	61.0.3163.91

[shi-cong]

selenium + chrome headless is better, but there's some bugs with it.

[samccone]

hi @sravani93 launching the same version of chrome with the same debugging port is going to be problematic, Can you share a test case so we can reproduce? Thank you.

[paulirish]

@samccone i think it's a single chrome launched just once. but essentially with 150 different instances of chrome-remote-interface connecting to that one port. Pretty exciting. :)

@sravani93 interesting challenge. we're not sure where the problem is. it could be the web/websocket server at 9222 or it could be the IPC buffer going between renderer and browser (or something else entirely).

This would require some more investigation to figure out, and doing some changes to chromium.

There's one alternative that you could try out to see if it helps though.

---

Using childProcess pipes as protocol transport

A few months back we enabled pipes to act as a protocol transport, rather than using a websocket. Performance-wise, it's not substantially different, but we see the main benefit being security. Anyhow.. if the bottleneck here is indeed near the TCP socket, then this would avoid that entirely.

1. You'll need to use content shell instead of chromium. You can find some download URLs here: https://github.com/GoogleChrome/puppeteer/pull/973/files Content shell can run both headless and headful.
2. You'll then need to communicate with the child process via these pipes. This isn't supported by chrome-launcher right now and you'd need to hack it a small bit. This puppeteer PR has the basic approach. I think mostly you need to change how the childProcess is spawned so that we pipe the stdio fds 3 and 4. (see here)
3. After that you'll want to follow the rest of that pr 1120 for handling the data transport over pipes. Their API provides a send() method and a message event. That hooks in at a level pretty internal to chrome-remote-interface, so you'll probably need changes there, too. :)

Anyhow, after all that you shoulddddddd be able to try this out.

(as I type all this I realize a probably easier solution is to fork puppeteer and merge those two PR branches in and then attempt to recreate your situation using the puppeteer API)

Anyhow, good luck!