[HighAspect]

The Secondary Screen system is implemented as an HTTP WebServer embedded in the RunActivity executable of Open Rails. It runs in its own thread (WebServerProcess) and implements most of what is described in the bluebrint and specification, as well as James Ross’ additional comments. The WebServer implements the GET and POST methods of HTTP. Right now, I don’t see a need for other methods. Currently, the client side is simply a browser (I’m using Chrome for testing – but it works with FireFox, IE and Safari on my iPad, as well). The Browser accesses content from the server using HTML, CSS Style sheets and JavaScript. Ultimately, we may want to implement a custom WebBrowser using either the Microsoft or Chrome embeddable Browser object.

Static content is provided using the GET method of HTTP while dynamic content will be delivered with the POST method. The POST method will have the ability to service various APIs that the Open Rails community defines. API will be both read and read/write (in terms of ORTS data). API Data provided by the WebServer is delivered in JSON format, which can be acted upon in the client with JavaScript and/or jQuery. Communication with the server for API data will typically be performed using Ajax on the client side.

While James has talked about pushing data to the client, my conception is let the client handle all requests and not burden the server with maintaining the client connection. My conception is to keep the the Server processing as minimal as possible. Of course, that’s up for discussion.

While the implementation is preliminary and there is much testing to be done, I felt that input from the community at this point would be important, before I get too far along in the event that changes need to be made at the low level. Being in the preliminary stages, it will be easier to change directions if my conception differs from the rest of the community.

I have currently implemented one API that delivers the HUD window(s) to the Browser. The output is very similar to the HUD windows from within Open Rails. The client side utilizes HTML, CSS and JavaScript to display the data received from the WebServer. It does not include the graphical elements the of HUD windows yet. My first impression is that the display on the browser could use with some reformatting. Since the JavaScript requests new data at set intervals, we might want to think about separating the more dynamic data members into a separate region of the page to be updated more frequently and the things that don’t change as often updates less frequently.

What I’d like to do going forward is to:

• Complete the graphical components of the HUD windows
• Implement the remainder of the popup windows
• Work on the ability to display a “Google Maps” type display of the current route

So…… What are your thoughts ?

[Goku]

POST for dynamic content? I think the only acceptable solution for real time data is Web Socket.

[HighAspect]

Goku, on 27 December 2017 - 08:25 AM, said:

POST for dynamic content? I think the only acceptable solution for real time data is Web Socket.

There are several issues with WebSockets.

1) My understanding is that we are currently constrained to .NET 3.5, WebSockets appears to be only available in .NET 4.5. However, communication could be made at a lower socket level with our own custom protocol. Which brings up the second issue.

2) We want to allow access to the OR data from mobile devices and tablets (ordinary browsers). Not everyone has a second monitor to display a secondary screen, lots of people have a tablet of some sort. HTTP seems the easiest way to provide that functionality. I'm not sure about trying to implement a custom protocol on say an iPad or Android device.

3) So, far the thinking has been to keep the server side processing at a minimum. My client is updating once every 500 milliseconds via JavaScript and that interval seems acceptable, at least for the data in the HUD display. I haven't done any profiling to see how much of a drag that puts on the program. I'm not sure we need to be in 'real' real time.

Why do you feel that Web Sockets is the only acceptable solution for dynamic content, assuming it's not 'real' real time?

[Goku]

Quote

1) My understanding is that we are currently constrained to .NET 3.5, WebSockets appears to be only available in .NET 4.5. However, communication could be made at a lower socket level with our own custom protocol. Which brings up the second issue.

I think there are 3rd party libs for c# with WebSocket support.

Quote

2) We want to allow access to the OR data from mobile devices and tablets (ordinary browsers). Not everyone has a second monitor to display a secondary screen, lots of people have a tablet of some sort. HTTP seems the easiest way to provide that functionality. I'm not sure about trying to implement a custom protocol on say an iPad or Android device.

All current browsers support WebSocket. That's why it's WebSocket and not just Socket.
https://caniuse.com/#feat=websockets

Quote

Why do you feel that Web Sockets is the only acceptable solution for dynamic content, assuming it's not 'real' real time?

If you are thinking only about 500 ms intervals then POST isn't bad. But I think it's wrong assumption. If you are working on good, universal solution, you should consider that some people want 20 ms intervals.
And 20 ms interval is a kill for HTTP requests.

[HighAspect]

Goku,

I was not familiar with WebSockets. Thank you for bringing it to my attention.

I did a bit of research and testing. In a very un-scientific and not very rigorous test, I found that at ½, 1 and 2 seconds, there is little or no impact on Frames Per Second. On my system, FPS was between 185-200 in all three cases, as well as the case with no load on the WebSerevr at all. When I went down to 20 ms, performance dropped significantly to about 100 FPS. It tells us little about the difference between HTTP POST and WebSockets but does tell us there is no significant effect on performance at the slower intervals. In addition, for the kind of applications we are initially considering, the HUD and popup Windows, 20 ms is way to fast. The values that do change change so fast as to be almost unreadable, for example, the Force HUD window.

I looked at the protocol spec and decided that it would be easy to integrate it into the HTTP Server I’ve already implemented. A WebSocket server depends on an HTTP conversation in order to initiate the WebSocket protocol. In my server, I fork two different paths depending on whether the URI is GET or POST. My WebServer requires an API request to be a POST and to have a URI that starts with “/API/”. I could easily fork a third path when a GET request URI stats with “/API/”, thus a fork for WebSockets requests. The infrastructure for WebSockets is there, if and when we need it.

My programming philosophy has always been to start small and implement a step at a time, even if it requires reworking the code. (now, I guess they call it refactoring – seems we did all the cool stuff years ago, just didn’t have a name for it).

Can you think of any applications where we might need 20 ms communications?

Thanks again for bringing WebSockets to my attention.

Dan

[cjakeman]

HighAspect has configured a webpage for trying out the HUD information. Like the HUD, there are common data values and you can switch between the secondary data values. Currently the style is very plain.



The magic thing about the data provided by the webserver is that anyone with webskills can produce (and share) their own webpages to show what they want to see organised in a way to suit themselves.

I made an extension recently for a French member who needed the cab instrument values extracting to drive his hardware. My simple scheme worked but was primitive and not worth including in OR. Thanks to HighAspect, I can now extend OR with an API to extract those cab instrument values and they can be displayed on a second screen/device any way you want.

[cjakeman]

Here's my vision:

For showing the pop-up windows F1, F4 etc., we could make use of a "dashboard" such as this one.

It's all coded in JavaScript to run in a browser, shows text, links, and charts and data points that update. It's also configurable - by clicking the Edit icon (top right) you can re-arrange the panels and add new ones to suit you (just as you do with the F1, F4 pop-ups).



As soon as the webserver is available to provide all the data, then anyone can adapt a dashboard like this and publish it in the File Library.

[cjakeman]

Been playing some more with the webserver that HighAspect has developed.

Here is a photo of 3 browsers showing one of his HUD pages displayed (clockwise from top):

• on a second monitor on the PC which is running Open Rails
• on a laptop with a WiFi connection to the LAN
• on a tablet with a WiFi connection to the LAN

I'm now trying to code an API for myself. This will publish all the cab controls, eg Speedometer, Train Brake etc. onto the secondary device.

[cjakeman]

cjakeman, on 02 April 2018 - 11:16 AM, said:

I'm now trying to code an API for myself. This will publish all the cab controls, eg Speedometer, Train Brake etc. onto the secondary device.

Had some success. Here is a webpage showing the data:



The webpage above is just a way to test the new API. The aim of this API is to provide the data needed to drive real cab instruments as used by member BB22210 (as in this still from a video):



Now that I have learned to make an API, I'm wondering what APIs Open Rails users would like to ship with the next version. I had thought maybe a gradient indicator, but I'm open to suggestions . . .

[HighAspect]

Looks great.