Last time around, I outlined what would go into my build. This time, I’ve actually placed the order for the parts. I was originally going to place with newegg, but the motherboard was out of stock. This forced me to consider amazon instead. Amazon had everything, and at fairly decent prices. That plus prime shipping, and good return policy, made it a relative no brainer (sorry newegg).
I did a hand wave on some of the parts in the last post, so I’ll round out the inventory in detail here.
this item used to require a ton of thought in the past, but today, you can spit in generally the right direction and things will likely work out. I wanted to outfit my rig with 64GB total ram. I wanted RAM that was reliable and looked good. I probably should have gone for some red colored stuff, but I went with the black G.SKILL Ripjaws V Series DDR4 PC4-25600 3200MHz parts (model F4-3200C16D-32GVK).
They come in sets of two (32GB per set), so I ordered two sets. Who knows, maybe I’ll get lucky and they’ll be red.
I know from my laptop, and my current Shuttle PC that having a SSD as your primary OS drive is an absolute must these days. Please, no 5400 RPM spinning rust! On this item, I chose the Samsung V-NAND SSD 950 Pro M.2 NVM Express 256 GB.
As Rocky and Bullwinkle used to say; And now for something we know you’ll really like…
There are literally hundreds of screen sharing solutions out and about in the market. Probably the reason there are so many is because the technologies behind them have become really pervasive, and the “good enough” solution is readily at hand. Well, not wanting to be left behind by the computing world, I decided to implement my own form of screen sharing that runs in any browser (that implements WebSocket at least).
Here’s my take on it:
Well, this is a .htm file that any browser can load. It’s only 85 lines of code, not including the inclusion of jquery. JQuery is incidental to the implementation, it’s only used to notify when the document is ready, and to select the div tag that I use.
So, what’s going on here? It’s really fairly simple. To break it down, I’ll start from the reverse. The simplest form of screen sharing is simply taking snapshots of the screen that is to be shared, and send those snapshots out to whomever you intend to share with. If you can send them fast enough, the sharer will have a nice live update of your screen.
To truly share the desktop though, you have to be able to send keyboard and mouse events back to the desktop that is taking the snapshots. If you can do this fast enough, then you can actually control elements on the desktop and see them update in real time as your screen updates.
So, to do this in the browser takes two parts. The first part is to simply display screen captures. In this code, I assume there is a service I can talk to and ask for a particular bitmap image. The refreshImage() funcition does exactly this. It basically just asks the server for this image, and displays it. But we need this to occur on a regular basis.
That little bit of code that starts with $(document).ready(… calls setInterval(“refreshImage()”, FrameInterval);
This will ensure that the function is called every so many milliseconds.
Great. That covers the first part of the equation. Every few milliseconds, the screen will be updated with an image. This web page neither knows nor cares what the image is, where it comes from, or anything else. It just knows it will display the image. This is handy not just for screen sharing, but for cameras, or anything else that can generate an image with any regularity.
OK. So, now an image will show up every once in a while. What about sending keyboard and mouse events back the other way? Well, here I’ve chosen to employ websockets. The WebSocket API essentially gives you a bi-directional socket to the server you specify. This is great because you can then send anything down that pipe once the connection is established. This socket is completely independent from the one the browser might be using to do its normal tasks such as downloading that image. This is great for sending mouse and keyboard out of band because it’s fast and minimal. Other than the initial setup, which is in http protocol speak, the socket is just a plain old socket.
So, down at the bottom of the code, I’ve implemented some mouse and keyboard event handlers. Basically, just capture the keyboard and mouse, create a string that the server side can understand, and send that string to the server side using the WebSocket. Again, the script doesn’t know what it’s talking to for real. The keyboard and mouse commands could cause any number of actions to occur on the server side. The script just sends the data.
And that’s about it!
This is a very rudimentary implementation. It’s possibly good enough for me to help my mom if she’s having problems with her computer and I need to quickly help her out. It can only get better from here. You could add copy/paste, better compression, and all sorts of things that might have you thinking you’re ready to compete with the best of them in the race to replace the desktop.
But, for me, it just goes to show you that this is a category of software that has become easy enough that 84 lines of html is enough to demonstrate the basic concept.