I look forward to the mix of reactions, with some calling this project awesome and others calling it pointless and useless. Nonetheless, here we go!

Introducing VAPOR, a project I've been working on for the past few days. It occurred to me to work on this project when I considered that I had a server almost entirely devoted to one game and one website... that I could expand that a bit and share that hosting with other developers who may want to make and/or host games (or general programs) that use a server. I don't know if many exist, but perhaps this may encourage development in that arena.

Project VAPOR is a service I run on my TI-Trek server that the VAPOR client, running on your calculator, can connect to. The VAPOR client can connect to the server I have running. That server can tell the calculator about any active calculator game services that are running on my host, and allow you to connect to them by retrieving a list of dependencies, installing them, and then installing the Client that is needed, and then handing off execution to that client.

For example, say a user running VAPOR would try to connect to my TI-Trek server. The service.conf file would inform VAPOR that in order to play, a client needs: srldrvce, usbdrvce, fileioc, graphc, and keypadc, as well as the appvar TrekGFX.8vx, and finally the client program TITREK. The VAPOR client would request copies of those binaries from the network, which would be served and created on your device (skipping any existing files that are up to date). Those files would also be CRC'd and logged in a library which is saved on your calculator (the CRC is compared with the CRC of the binary on the server to determine if an update is needed). Once all of the needed files are created, the VAPOR client will launch the appropriate client to play the game.

If this sounds awfully familiar to Steam, well, just think of what "vapor" is another word for.

In addition, the Library tab shows you any programs on your device that VAPOR has downloaded. The CRC's, name, and type are saved for each, and while viewing your library you can press a button to have your Library's CRC's checked against those on the server to determine if anything on your device needs updating.

Here's a screenshot of VAPOR's early build in action, displaying the 3 services I have running, Uno (which is still under development, Trek, which is active, and Vapor which is only online when I am testing at the moment.)

@ toolchain devs, would you mind if I maintained an active toolchain build on that network/server, for providing the libs to potential users?

dude. This is an amazing idea, go for it! I wouldn't know what I'd do with myself if this rolls out my guy. Do it is what I say!

THIS IS AMAZING! There are so many possibilities with this that didn't get realized with CalcNet2- we could possibly download programs directly from sites like ticalc.org, Wide spread online multiplayer, etc...

However, I would like to suggest possibly releasing the server side code as well if this comes to fruition so that people can run their own servers in case yours goes down for whatever reason. That part's up to you though.

Yes I like this idea, if networkable games and programs are going to be common place then a standard service/library to handle it would be beneficial.

Sounds amazing, a service that allows users to directly install and connect to loads of games, all in one calculator file? It would be some of the coolest stuff I've seen in ages. The opportunities something like this would create are endless. I hope something gets fully completed, I would love to check it out.

this is fantastic but I want to scam my users with microtransactions

This is a great idea, ACagliano! Definitely do it!

So, if I understand it right, it means that you want to make something that calcs can connect to the internet and play calculator games online?
That sounds cool.
But for what calculators will it be then?

Since they have been developing both TITrek and Uno for the CE, I'm assuming that's what it is for. Perhaps the idea could be used in other calculators, although that sounds a little hard to manage. Luckily the only calculators I have are CEs, so I won't miss out on this.

This is so cool! As an avid user of Steam, this would make my calculator use so much easier. Do you plan on allowing users to submit services? As you may know, I'm working on M.U.L.E. CE and need a way to easily make multiplayer. This would be so easy. Keep up the amazing work Cags!
-Knights

…but the CE cannot connect to the internet

Well, CE is in the topic's title, soo.... :p
But yea, it's for the TI-84+ CE. Though it is expandable, through just assigning certain servers a device type flag.


Oh but they can my good sir, they can. It takes a bit of work on the user's side, right now. The user would need their calc connected to their computer with the USB cable, and would need a "bridge" program running on their computer (until commandblockguy expands InternetCE for this) to translate the serial data incoming into TCP and the TCP incoming into serial data. But yes, they can. The same bridge that I've released for project TI-Trek will work for this.

This sound very promising
i'll be making concept art if libary gets released

Questions
Why is there only one server why can't devs host their own servers? (for example, if I want to host with firebase instead of default)

Will this only be limited to pc users or server will run on a browser?

Lastly, This opens a very "big" door for the CE .
I'm so excited .

Well the way Vapor is going to be set up is such that if you want to run your own calc game server, you can, instead of uploading the binaries/scripts yourself, you can input the host name of the server, and VAPOR will print the hostname of the server. However, if there are dependencies, VAPOR will need them in order to serve them (unless I do a curl or something to get the binary.

Dude, this sounds pretty neat. Keep up the good work.

Quick Update before I turn in for the night.

I was working today on beginning to implement the "verify and install dependencies and client" portion of the VAPOR client/server interaction. While the interface isn't fully done, I have a roughly-UI'd demo of the program's ability to learn what pieces of software your calc needs to join a specific service.



In addition, on all of the routines where the server can fail to find something or do what is needed, a packet is sent from the server to the calc that results in something looking like this:

I've been ranting about the logistics for this project for a while, and I figure I might as well bring up my questions/concerns here. I think this is a great project and should allow for some seriously cool games and easy maintenance for programs, I mean it is basically steam, and it's on line with Nomkid's Calcbucket project. However there are issues with both the calc client-side and server management, and I just want to put in my two cents since I've been bouncing this idea for some time.

For the calcs, and I mean any of them, there are multiple ways to set up an internet connection, and while some might not support all the methods, we have proved that they work. There's the existing TI-Trek client bridge, which works well but isn't exactly portable. Nanotube is extremely promising, but needs an ethernet port or a chain of USB -> ethernet -> wireless adapter, and isn't to portable either. We do have WiFi with gCn as well, and that could theoretically work for all calcs with serial and hobbyist MCU's with internet capability. Those three ways work, and I'm barely covering all the variations we could try, but it's pretty much only limited by the serial capabilities of each calc, since HID standards just aren't standardized enough (although Nanotube might be able to pull it off since there's an abundance of cheap ethernet adapters and I can't imagine that they all have different interfaces) so we'd need to push out serial libraries for lots of calcs that may or may not have them already (C'mon, the CE isn't the only thing that could benefit from this). I imagine that whatever libraries are used may end up being large, so there would need to be a package selection available so people could install library "drivers" for each option. It wouldn't be as plug-in-play, but it would be easy to streamline the program size. Security on the calc side could be a legitimate problem though, since you could easily write up some simple IP scanners and password scrapers for WiFi and other networks, not to mention other malware people might make.

Now to blather on about servers: we could either rig up an old Dell in the garage with an internet connection and whatever server system a game wants for constant hosting or have some more powerful calcs handle hosting games. A simple universal application to start, say, a game of UNO could be run on a Linux machine of some kid over in France, while all the bois come together from Brazil and 'Murica or wherever and put in an IP or URL provided to join the host; once the program's closed the address is invalid and the game no longer exists. Permanent servers are good, but a decentralized system similar to SAX would be much easier for most people to use and harder to compromise via cyber attacks ('cause who doesn't want to spoof the servers for a bunch of calc games and install adware?). The biggest issue I can foresee is moderation, keeping dangerous hacked servers/clients from cheating in games or damaging other's machines. We'd need either a global moderation server or a public list of users to avoid, and anyone who's smart enough to get this working could easily cover their tracks and set up burner accounts, especially if CEmu gets a server connection to experiment with. The solution is to close-source a lot of the client-side code as obfuscated ASM libraries, which could be reverse-engineered by a number of people here already, and hope that it keeps out the casual hackers. People on Cemetech seem to be decently mature and respectful of others, but there are plenty of other forums and users who could easily provide the toxic element that could bring down lots of careful planning *cough*Omnimaga*cough* even then the server code has to be open-source in order to build custom games, and it's hard to obfuscate python (well it's easy, but it makes it so awful to run).

In short: this is an incredible project, how do you hope handle security and deployment?

Well first things first, bear in mind that the "bridge" was devised when there was no alternative method. Nanotube, as far as I am aware, will likely never be a LIBLOAD-compatible library because its too large and that would require rewriting LIBLOAD (command can explain that better than me). If/when commandblockguy expands InternetCE's functionality to replace the bridge, that will be the existing method of connecting.

Deployment depends on precisely what you're referring to. All software on the server is signed with a CRC-32 (if needed I can use a full-hash). The general method of authentication used is, upon upload of software to the server, a CRC is attained and logged. A user-script will run on occasion that will mark packages as invalid if their CRC does not match the stored one. The server itself uses strict packet checking, as in attempting to connect to a VAPOR and then sending an invalid control code and/or invalid packet segments triggers a security alert and results in immediate disconnect.

I'm not too worried about the logistics of someone launching man-in-the-middle attacks on traffic going from a calculator game server to a a calculator. I suspect most of the hackers who would have the skill to do this wouldn't waste their time on such nonsense. As for direct assault on the server itself, my server itself is jailed, with strict directory permissions, decent firewall implementation, IDS and file integrity software running-- I'm no stranger to server security. Oh and, once I get everything done.. the calculator service itself and the website to interface with the backend both will run on SSL with a signed certificate. I may also set it up that every service hosted by my network is proxied from the main VAPOR network to whatever port the service will run on via loopback, such that the connection from your client to VAPOR is SSL, and the connection from localhost:51000 to localhost:arbitrary is not. This would eliminate the need for me to open like a million ports on my router as well.

As for individual files uploaded by users for their service... it is on them to ensure those services communicate in a secure way. I do intend to provide the library allowing custom services to authenticate and do other sensitive tasks through VAPOR (benefiting from the SSL connection for security), but beyond this all I can really do is de-list a service if security issues with them are reported.

I'll reserve judgment on this until it gets a little further along, but the basic idea of a server that can be re-used by multiple types of clients, downloadable on the fly, is a good one. Where I'm reserving my judgment is (a) execution - that it can be done properly and well (I share concerns about security and scalability), and especially (b) adoption - that people will bother building anything for it, based on my experiences with DCS, CALCnet, gCn, the Doors CS GUI, etc.

Setting yourself up to let this be called "vaporware" is a bit on the nose, though.

Well right now, existing plans for security are retaining a CRC-32 or some other form of hash, server-side that is generated for every hosted file the network serves, as well as the service itself running over SSL (although I am doing my beta testing without SSL).
Once a user is connected to the main network, assuming they request a proxied connection (which will be a default setting), a loopback connection to any service on the same network will be opened for the game to connect to.
As I also know commandblockguy might be expanding InternetCE to support bridging a computer's internet devices, I suppose that the current bridge's invocation of an ssl context will need to be swapped out for an alternate.
I'm 100% open to suggestions on the topic of security.


Yea, I share that concern as well. I'm not quite sure there will ever be an extensive repository of online calculator games, and if it be the case that the network doesn't get much use, I can always retire it and go back to just hosting TI-Trek there. Nonetheless I figured while i had the spare resources, I may as well share them.

An update as well.
The file download system works... it would seem. The libraries error out because they're not actually hosted yet, but the one file I put there for testing is located, opened in 'rb' mode, streamed to your device, and installed.
To prevent you from losing your existing *good* programs to a potentially bugged download, it is my intent to have the downloaded file stored to a temporary file in its entirety, at which point, the CRC algorithm runs on the calculator, ensuring that the CRC reported by the server matches the CRC of the download. If these CRC's do not match, the new temporary file is deleted, and an error is reported. If they do match, the old file is deleted, the new one replaces it, and the library entry for that file is updated.