25 replies to this topic

[Nick]

Hi all,

I'm trying to display application statistics and diagnostic information (e.g. framerate) in a web page, updating it in real time. Anyone know what technology I could use for this?

I'm currently already using WinSock 2 to directly open a socket and serve a web page with controls to modify application behavior. But it requires reloading the page to exchange data. For an FPS counter and such I was hoping it could continuously call a function on the server side and update the text field without reloading. Note that I'm trying to keep this as lightweight as possible. Any ideas?

Thanks!

Nicolas

[TheNut]

I take it your custom web server is very simple? Otherwise I would have suggested using AJAX calls to exchange the data. This would be your most lightweight solution, next to using a more sophisticated solution such as Flash or Silverlight.

[alphadog]

I think I need more details on your architecture. What is your client built from? What's on the server side?

[Nick]

TheNut said:

I take it your custom web server is very simple?

Yes, I simply open a socket and send the web page as a string. :happy: And I'd like to keep this as minimal and low overhead as possible.

Quote

Otherwise I would have suggested using AJAX calls to exchange the data. This would be your most lightweight solution, next to using a more sophisticated solution such as Flash or Silverlight.

I started looking at AJAX, and it seems like it's just a collection of standard technologies used together. So possibly something as simple as a framerate counter could be done with little extra code. I'm baffled by all the advanced uses and derived technologies though. Many tutorials assume you're using high-level tools, while I'm trying to understand it at the lowest level... :surrender

Anyway, thanks for the suggestion! If anyone knows where I might find essential information about this technology or something similar that would be much appreciated.

[alphadog]

AJAX is a big world of lots of differing technologies and frameworks that operate at different levels.

But, at the core, it is a browser's use of asynchronous calls, via Javascript, using an in-browser object (XMLHttpRequest) such that the browser can send and retrieve information. Typically, this information is then used to alter the browser's DOM. That's AJAX at it's core...

[Nick]

alphadog said:

What is your client built from?

Any browser.

Quote

What's on the server side?

A full-screen application opening a socket and listening for HTTP requests. It sends HTML pages as an ordinary string, containing several basic controls such as checkboxes, drop-down lists and buttons. When changes are posted the server can parse the control settings and pass these on to the actual application.

I've used this in SwiftShader 2.0, to control quality settings interactively (and remotely). Now I want to reuse that for a new project and extend it with real-time diagnostic information.

[alphadog]

If you focus on finding tuts on how XMLHttpRequest is used to support AJAX ideas, you'll probably find what you need.

Edit: Get familiar with low-level, cross-browser issues. Most of the AJAX libraries are made for app-building and encapsulate all the nitty-gritty for this.

[Reedbeta]

Here's a decent low-level article showing the client-side Javascript needed to send an asynchronous HTTP request and parse the result. You can certainly use this to download some information from the server and update the page without reloading it. XML is used because it's easy for Javascript to parse. On the server side, you just need to listen for the requests and dump out the requested data.

[alphadog]

Reedbeta said:

Here's a decent low-level article showing the client-side Javascript needed to send an asynchronous HTTP request and parse the result. You can certainly use this to download some information from the server and update the page without reloading it. XML is used because it's easy for Javascript to parse. On the server side, you just need to listen for the requests and dump out the requested data.

That reminds me. Ignore the 'X' in 'AJAX', Nick. If anything, you want to look at JSON, but it seems like your server-side code send HTML fragments already?

[geon]

You could try using Comet for updating the stats. You would basically send new data to the browser continuously, overwriting the old. The easiest way is to send immediate Javascript like

<html>

<body>

<script type="text/JavaScript">

document.write("FPS: 0.23")

document.write("FPS: 0.24")

document.write("FPS: 0.21")

document.write("FPS: 0.23")


(...)

Each "document.write()" will overwrite the content of the browser window. You probably want something more sophisticated, like

var MyElement = document.getElementById("SomeID");

MyElement.innerHTML = "FPS: 0.23";

MyElement.innerHTML = "FPS: 0.21";

MyElement.innerHTML = "FPS: 0.25";


(...)

NOTE!!! Some browsers will not update unless they have recieved some minimum ammount of data. (like 1kB or something.)

[Nick]

AJAX, DOM, XML, DHTML, XHTML, JSON, Comet... any more acronyms that will make my head explode? :blink:

Thanks for the suggestions using XMLHttpRequest! It looks like that's the vital part for creating dynamically updated content. I assume it's no big deal to make JavaScript contact the server at fixed intervals?

[alphadog]

Yeah, welcome to a new acronym soup.

If you are trying to keep it absolutely dirt simple, then all you need to look at is the Javascript timer ( window.setTimeout() ) for polling your server. Careful with this though. All that polling can turn into a self-inflicted DDOS pretty quickly. Consider finding a way to do updates based on some client-side event, if possible, rather than on a fixed interval.

Essentially, COMET, like AJAX, has a big name, but at its core is the same XHR object plus polling.

Added: I think the main distinction is that COMET uses long polling, which means keeping the client connection in waiting. So, instead of "are we there yet?", "no", "are we there yet?", "no", "are we there yet?", "no" ... "are we there yet?", "yes!", you have "are we there yet?" <wait for a long time until Dad has an answer, could be one minute, could be one hour> "yes".

[Reedbeta]

Nick said:

I assume it's no big deal to make JavaScript contact the server at fixed intervals?

Not at all; you can use Javascript's setTimeout() function to schedule a function call in the future.

[Mihail121]

Hm, a somewhat simple solution with complex tools would be to include a stream control and feed it data. Like a MediaPlayer stream. Of course, this requires overhead to generate the stream server-side.

[TheNut]

Just remember that you enter the realm of browser wars ;) IE does their thing, mozilla and the rest do theirs.

// For Firefox, Opera 8.0+, Safari, use

new XMLHttpRequest();


// For IE, use

new ActiveXObject("Msxml2.XMLHTTP");


// For older versions of IE, use

new ActiveXObject("Microsoft.XMLHTTP");

They all carry the same API though. I just use a try/catch ladder and keep going until one of them works.

[Nick]

Got it working! :yes:

alphadog said:

Ignore the 'X' in 'AJAX', Nick.

Yes, exactly. All I needed on the server side was to write the FPS value as a string in an ordinary HTTP response, and on the client side it pops out as the responseText property of the XMLHttpRequest object. The remaining piece of the puzzle was to assign it to the HTML text field using DOM.

Thanks all for the help!

[Nick]

Got one more oddity...

First I was using the URL http://localhost:8080/configtest for the web page, and http://localhost:8080/configtest/fps for retrieving the FPS (i.e. the URL passed to XMLHttpRequest.open). Everything worked fine. Now I'm trying to change "configtest" to another name, and the browser hangs. No exception thrown, no error message, just 100% CPU usage.

I've checked like a hundred times that I replaced "configtest" everywhere. I was also able to verify that the request reaches the server, the URL is the correct one, and it sends the HTTP response containing the FPS. It just appears to never arrive. I've fully disabled my firewall but it still hangs.

Any clues? :huh:

[alphadog]

Hmm, without knowing more details on your custom stuff, it's hard to tell. Did you try different browsers? Did you try an HTTP analyzer?

[Nick]

I fixed it using HTTP POST instead of GET. It probably has something to do with the way GET requests are cached by the browser itself. The first GET request fails because the XMLHttpRequest object isn't completely ready yet, and for subsequent calls the browser appears to assume it has to repeat that error code. :wallbash:

Anyway, I'm glad I got that fixed, but I already discovered a new issue. It works fine using Internet Explorer (8), but not using FireFox 3.5. I get the FPS once and then it freezes. I guess I can use Venkman to attempt to debug it. If anyone has any guess what the issue could be please share.

[geon]

Nick, if you want to do more than just the simplest javascripting for a single browser,you REALLY should look into something like jQuery.

It abstracts away most of the retarded browser differences and annoying API:s.

If you are into functional programming, you will appreciate the jQuery API.