Spawn Connections Without Using The API

Question

Spawn Connections Without Using The API

j-manu opened this issue 6 years ago · comments

This can be optional. i.e those who want to do it with API can continue doing that. Have the proxy listen on another port (say 1332) and when the the client connects to ws://localhost:1332/ and the proxy server spawns a new connection (instead of the API server) and it continues from there.

Here is how I envisioned it.

Proxy listens for a connection
For a NEW connection, it spawns a new ChromeProxy instance.
The connection is handed over to the ChromeProxy instance.
From this point on it is just like current architecture

This makes it easier to load balance multiple chroxy instancers because it will be a single connection. Currently it takes two connections (one to api and one ws) and those can go to different instances. The only way to solve it from what I see is to ensure that a client machine always gets routes to the same chroxy instance but that means that a single client machine can only use one chroxy instance

Steven Holdsworth · Answer 1 · Mon Jul 02 2018 18:25:00 GMT+0800 (China Standard Time)

I like this idea in principle, but I don't see how this could be compatible with the Chrome Client libraries currently out there as they need the web socket connection passed into them (at the page interaction part of those libs).

The trouble I see with this is the fact that it is the Chrome Clients making the initial connection to the ProxyServer (as if it was a chrome instance) - as such the /devtools/<page_id> is part of the HTTP request for the web socket upgrade handshake. I don't want to mess with this.

Adding support for what you ask you require some funky protocol interception.

It would require:

The listener to accept the connection (which is currently triggered off the ChromeProxy when it generates the Page for the connection). - This could be replaced with an "Acceptor Loop" no problem there.
The client makes the web socket request to the ProxyListener (without all the chrome related info in the HTTP Request for the web socket protocol upgrade handshake).
The Listener accepts the connection, spins up the Chrome Browser Page, request the page WS url, starts performing the web socket upgrade negotiation and then sends response back to the Client Lib? - This just seems too broken if I am honest.

I think it might be possible to do, or I am missing something?

Manu J · Answer 2 · Tue Jul 03 2018 01:48:22 GMT+0800 (China Standard Time)

I didn't quite understand why you think, it will be incompatible with Chrome Client Libraries.

Steven Holdsworth · Answer 3 · Tue Jul 03 2018 02:20:49 GMT+0800 (China Standard Time)

Because the first thing they do it try to establish a web socket connection, Chroxy does not have any knowledge of web sockets, and does not do anything other than forwarding traffic between upstream (client lib) and downstream (chrome) endpoints with raw TCP sockets.
Therefore on initial connection, Chroxy would need to establish to web socket connection to the chrome page and then hand that over to the client library(?!?!), I don't think that would be a very good idea as it breaks the HTTP / web socket protocol. Or the client would need to change to expect a ws:// url as a first reply, which would break the Chrome Debug Protocol expectation and therefore the client libraries.

If you would like to have a try at doing this, you are more than welcome and I will review it for you, but right now I cannot see how this would work in a reasonable way.

Manu J · Answer 4 · Tue Jul 03 2018 19:29:32 GMT+0800 (China Standard Time)

I'm just learning elixir. I will attempt to do this once I progress enough in my learning :)

Steven Holdsworth · Answer 5 · Tue Jul 03 2018 22:03:08 GMT+0800 (China Standard Time)

No problem I will close this issue for now then. But even if you have an example from another language doing the same thing I can help you port it - as I don't see a way this will work as explained.