Originally Posted by America (Post 2799058)

Chrome RDP doesn't work like other incantations of RDP. It runs virtual applications, cloned from RAM of the viewed PC, locally on the viewer machine and superimposes them over cropped jpgs or png or whatever sent from the viewed PC. That way the images transferred can be much smaller, and bandwidth constraints are much less an issue. It's a wild implementation. Side effects, of course, Google gets to read the state of the applications and track user behavior thoroughly for advertising. And the traffic can be read by IP log and deep package inspection as though the remote machine were local. Check out the docs, chrome rdp is wackadoodle af.

Originally Posted by this user was banned (Post 2799073)

Ok, but isn't the only socket connection to EQ being run on the home PC's hardware? You can't trace that from RDP if the physical machine has no connection to his work PC other than through the HTTPs based RDP connection.

Or does Chrome use your local PC's hardware for networking instead of the home PC?

If you started EQ on the home PC then connected to it and picked it up at work, the process and socket are only running on the home PC, otherwise EQ will just not work because it would need to open a new connection on new hardware. Maybe there's something I'm missing?

Originally Posted by branamil (Post 2799074)

How about you copy and paste the part from the documentation where it "clones ram"?

Originally Posted by this user was banned (Post 2799073)

Ok, but isn't the only socket connection to EQ being run on the home PC's hardware? You can't trace that from RDP if the physical machine has no connection to his work PC other than through the HTTPs based RDP connection.

Or does Chrome use your local PC's hardware for networking instead of the home PC?

If you started EQ on the home PC then connected to it and picked it up at work, the process and socket are only running on the home PC, otherwise EQ will just not work because it would need to open a new connection on new hardware. Maybe there's something I'm missing?

Originally Posted by America (Post 2799077)

The EQ instance is cloned from host (or whatever, the viewed machine I mean) to client (viewer) and run locally. Then a bitwise two-way synchronization is done as the application state changes.

It's bizarre. That's why it takes so long to "buffer", though, and why achievable framerate is so high. Check the docs out, it's wild.

Originally Posted by this user was banned (Post 2799080)

Ok, but the ACTUAL TCP connection to EQ is only run through the hardware on the home PC; I'm not sure that network traffic between the home PC and the EQ servers would ever be visible through Chrome RDP.

The network traffic for EQ wouldn't even route through his work PC would it? His work would only be able to monitor his work PC's traffic and they would only see the HTTPS traffic from Chrome RDP.

Originally Posted by America (Post 2799083)

ohhhh that's a good question. I had to look into the doc for this.

Turns out though that it's not safe. While the bitwise sync is active, Chrome RDP protocol designates a "primary incarnation" window based upon the most recent user interaction timestamp and conducts all tcpip from that machine. Weird. p99 might just drop the connection in that case. Check it out:

https://support.google.com/chrome/an...ynchronization

Originally Posted by this user was banned (Post 2799092)

There's nothing in that link about that besides how to set up Chrome RDP for me.