When comparing screen sharing solutions with a pure HTML based co-browsing solution, such as Surfly, there are lots of similarities but also a few key differences which become more clear when you look at the underlying technology.
If you inspect how these tools synchronize content from one part of the world to another, you can globally identify two different approaches. The Remote Framebuffer Protocol is used by most screen sharing solutions such as GoToMeeting, JoinME, Skype, Hangouts, Zoom and almost all other co-browsing solutions. The second approach is a different protocol that actually synchronizes the content and not so much the visual representation.
Screen sharing – Remote Framebuffer Protocol
This protocol is relatively simple. It looks at what is on the screen and sends that over the network to other participants. In the most simple implementation, it just sends screenshot by screenshot (frame by frame) and raw pixel data.
This is, however, very bandwidth-intensive and requires a very good internet connection. More intelligent approaches cut up each frame into multiple rectangles and then send updates not just as new data but also by reference to ‘older’ rectangles in a previous frame. This helps reduce the required bandwidth for a simple operation such as scrolling up and down, as it can just reference the data from the previous frame and it no longer needs to send all the bits over the network.
However, in most cases, the required bandwidth for sending these type of frames/images is still too high for most network connections so the image data is compressed. This comes at a cost. Not only does this require CPU intensive encoding but it also reduces the image quality of the content.
Co-browsing – Surfly’s HTML Sharing Protocol
Surfly’s HTML Sharing Protocol does not send over raw pixel data but rather sends the real HTML content and direct references to all sources that build up the page on the screen of the participant. The content will be drawn on your own computer + screen directly instead of somewhere remotely.
This approach has considerable benefits:
- It requires less bandwidth to synchronize state changes, so it will still work also very well on poor connections
- No loss of quality, as we do not need to apply compression to the content itself
- Higher performance, as items, will be rendered on your screen instead of somewhere remotely
- Original content can be synchronized directly from the source including Audio + Video elements
A drawback is that our HTML based sharing approach is limited to just what you are seeing in your own browser tab. However, for certain applications, this can actually be a big benefit as you’ll not need to provide remote access to your own desktop to someone else.
An overview of the framebuffer approach of synchronization compared to the DOM based synchronization approach by Surfly
It is all about low latency
One of the most important aspects of a remote desktop-like application or a shared browsing environment is the ability to provide a real-time experience without any lag or delay. In this case, it’s similar to VOIP applications or real-time video chat.
However, real-time streaming requires a low latency network to be successful. You’ve probably come across video calls that somehow just don’t seem good enough, even though you’re connected to a high bandwidth connection. The main reason for this is that while you might be able to download things with great speed, this is different from streaming at low latency. It’s important to understand this difference if you are able to buffer things, say, up to 45 seconds (as normally is done through live streaming via either Twitch.TV or Youtube) this will give you a lot of room for small connection problems. But, for real-time communication even a short delay of 500ms is unacceptable. To cope with this, most screen sharing and video chat solutions dynamically adapt to changes in the network by greatly increasing the compression ratio and thus decreasing the quality.
With Surfly we don’t need to do this as our approach by itself has much lower connection requirements. To make this difference clear I’ll show you an example of a remote session, where we’ll join BOTH a Surfly session and a Skype screen sharing session side-by-side: