Author Topic: [Resource] Webserver V4 - Making use of WebSockets  (Read 2983 times)

this is in coding help because you guys are cooler than modification discussion


Torque Webserver


Script Iterations:

* Version 1 (2010)
* Version 2 (2011)
* Version 3 (2012) - Latest release
* Version 4 (2013) - You are here

Test Pages:

Test pages are available for their respective versions in each of the previous topics (links above).
Version 2's thread has the most information and resources since that was the biggest overhaul.

Features:

Quote from: V2 Feature List

I'm still calling it beta, so test out these features sometime:

  • Preferences for port, debug echos, local IP restriction, timeout in MS, root folder, default index page, and Torquescript tag prefixes and suffixes can be set in the Webserver creation.
  • Setting of variables familiar to PHP users such as  $_GET, $_POST, and $_SERVER. The $_SERVER variables are dynamically created in Webserver::finish based in on the header received.
  • Torquescript located in pages is evaluated before the data is sent to the client, allowing for very dynamic pages such as a real-time score display or even an external server management page.

From a more in depth point of view, it has all this and more:

  • Easily editable settings in object creation
  • Optional debug echos can be turned on
  • Accepts incoming connections on any port
  • Can filter to only local IP addresses
  • Connections can timeout after a delay
  • Lines parsed as received to allow for binary data
  • Binary data can be submitted (POST)
  • Lines parsed as a whole after all submitted
  • Temporary file used for reading binary data
  • Sets $_GET based on provided arguments
  • Sets $_SERVER based on provided header
  • Sets $_POST based on provided body data
  • Allows for defaulting to an index page
  • Sends a 404 error if page is not found
  • Support functions include, print, and puts


Quote from: V2 to V3 Changelog

  • localOnly restriction now checks with isLANAddress
  • Cleaned up some of hard coding with Webserver methods
  • Client object is deleted after disconnecting
  • Improved basetype methods to be more dynamic
  • Added version of base64Encode to work with null values
  • Added a function to pad a basetype on the left
  • WebSockets! And support functions for them!


Quote from: V4 Planned Features

  • Redirect image requests to an external webserver
  • Show GUI on demand by converting to HTML and Javascript dynamically




Ok, so it's another year and another time I'm feeling motivated to add a bunch of stuff to my webserver. We last left off last year with the addition of WebSockets, and there was talk of making the server redirect image requests, but that never got done since WebSockets were more important. So I'll add that in this time, as well as this potentially cool thing I've been thinking about for some time now: in-browser GUI!

Basically, there would be functions in place that you would pass a GUI object to, and it would loop through it and its children objects and create an HTML layout representing the GUI. Here is an early picture I took when I was just starting, which includes how little the .tqs pages require in them: http://i.imgur.com/l6j3d0g.png

What are the benefits of this? Well, practically, maybe not a lot. But one thing it can do is deliver GUI to the client without them having to download anything. Of course, downloading is always the better option, but in some cases it isn't available, such as the user being unable to install add-ons - which actually happens - or if the gamemode developer wants to be able to update the GUI on the fly without requiring constant updates from the client.

Going with the idea of delivering GUI on demand, I set up a test. When a client joins the server, they would click a link in the welcome message to go to a web page they would leave open in the bacgrkound, so windowed mode is recommended. Then, when a GUI needs to open, the server tells the browser through a WebSocket of a page containing the GUI conversion code, which opens in a pop-up. Here is how it would work, where the browser window is the client's and the console is the server's: http://www.youtube.com/watch?v=U-Mz1nZM2tw&hd=1

I post this mainly so I can get your feedback as coders (and so I actually get it done):
  • Would you find in-browser GUI to be useful as a gamemode host?
  • If you were to utilize this, what features would you need implemented?
  • Are there additional features you would like implemented in the webserver?

Last topic had Lugnut contributing some code, so of course feel free to post anything you've edited with the webserver if you want me to include it in the base script. Otherwise don't hesitate to post suggestions/feedback/questions, as this is probably my favorite Torque project and I want it to be as complete as possible.

Thanks.

hory shet


How did you pull off the binary upload? I can't check on my phone

That deleting of client objects is important, I once had over 2000 of those little bastards cluttering up my tcp group
« Last Edit: October 01, 2013, 03:30:45 PM by Lugnut »

hory shet


How did you pull off the binary upload? I can't check on my phone

That deleting of client objects is important, I once had over 2000 of those little bastards cluttering up my tcp group

You posted in last year's topic after I added both these features you nub.

But for uploading, it is recommended for the coder to reserve \x02 as a "retry" code and \x03 as a "success" code. The uploading only wouldn't work because of the possible inclusion of null bytes (and some stuff with \r\n), which happen when the WebSocket's randomized encryption thing ends up using those bytes. But the server can tell if it does, it just can't make up for it on its own. So it sends \x02 to the client and tells them to re-send the last message. See the test page on version 3's post on how simple it is for the client to handle the \x02 response.

Are you saying that we can send binary files with this

Are you saying that we can send binary files with this

No, that's not the point of this webserver. Basic binary communication is already done with POST args and WebSockets, but we're not getting around the null byte limitation any time soon for file uploading, since the server would have to write to a file after decoding the frame, which appends \r\n anyway.

The point of the webserver, like most, is to send pages to a client's web browser. The advantage of using this over something like Apache is that it supports inline Torquescript and can interact directly with the server (e.g. show a live player list on a page), as that is what is running the webserver. It is also easier to set up because if you're running a Blockland server in the first place, you can run this webserver.

Aw, so we won't ever be able to send binary files?

Aw, so we won't ever be able to send binary files?

Not with this at least. It still seems like you're misunderstanding the focus of the script.

Thank you so much. The websockets will be very useful for a remote control mod.

This hard for me learn script.

Did some tests now that I'm off campus and can host. Marble Man was kind enough to be a guinea pig for a couple GUI tests and wanted to be sent a Yes/No message box, which was easy enough. However, these GUIs are blank by default, but since this is a webserver after all...

Code: [Select]
<?tqs
MBYesNoFrame.text = $_POST["title"];
MBYesNoText.text  = $_POST["text"];

showInterface(MessageBoxYesNoDlg.getObject(0));

MBYesNoFrame.text = "";
MBYesNoText.text  = "";
?>

You can pass the text you want to appear on the box as POST args! Fun stuff. The elements I have supported so far still have some hardcoding with parts of the style layout, so I'll move that and the websocket script to their own .css and .js files respectively. That way it'll be easy for me to start supporting more elements over the weekend.

Do any of you have gamemode-specific GUIs like a player's inventory I could use for testing?