SiteExperts.com Logo Home | Community | Developer's Paradise
User Groups | Site Tools | Site Information | Search
 Main Menu
 Forums
SiteExperts.com Forums
All Discussions

SiteExperts Feedback
The Lounge
Dynamic HTML
Site Design/ Critiques
HTML and CSS
XML Technologies
The Wireless Internet
Internet Explorer
Microsoft .NET
The Server
Technical Support

Sponsored Links

User Groups : Forums : SiteExperts : Microsoft .NET :

Previous DiscussionNext Discussion
 Silverlight + LAMP question...

Ok, as some of you know, I occasionally do some work for a local high school sports site.

I want to do something similar to a "game tracker", with near-real-time updates of what's going on in the game (preferably without using a timer).

I was originally going to use Silverlight and sockets, but the site is hosted on a Linux system, so it's a LAMP stack. Although, I could use Silverlight for the front-end, I don't really know how to handle (or what to do about) the back-end of things. It would be database driven.

Ideally, I would want the system to work this way:

A play happens. Someone inserts the play into an interface (web-based), which the client detects, and then the client updates. The entire system would be web-based. For an idea of what I'm talking about refer to the MLB Gameday system, or NFL GameTrax (I think that's what it's called).

I know this sounds a LOT like sockets.

Does anyone have any ideas as to how I could do this? I'm thinking this may be something I could sell to other schools as well.

Anyway, I was thinking of using Silverlight and PHP somehow. The database on the backend is (obviously) MySQL.

Any ideas, or a point in the right direction would be GREATLY appreciated.

Started By Monte on Nov 1, 2010 at 11:47:52 AM

18 Response(s) | Reply

Earlier Replies | Replies 5 to 11 of 18 | Later Replies
Goto Page: 3 2 1
bod1467 on Nov 2, 2010 at 7:39:30 AM (# 5)
This message has been edited.

An AJAX timer (executing every few seconds) wouldn't be much of a hog at all - particularly if it is only retrieving a small amount of data (timestamp) from the PHP server code, and then periodically getting the full update when the timestamp changes.

The basic program flow could be like so ...

START
  |
Timer=0
  |<---------------------------
GetTimeStamp (AJAX)            |
  |                            |
If GetTimeStamp <> Timer {     |
    GetUpdatedInfo (AJAX)      |
    PopulateDIV                |
    Timer = GetTimeStamp       |
}                              |
  |                            |
WAIT                           |
  |                            |
LOOP --------------------------

:-)
brian on Nov 2, 2010 at 8:40:56 AM (# 6)

You could simply use a $.post("jsonurl.ext",callback) call with jQuery and a setInterval("call()",30000) to call every 30 seconds
virtually no impact at all


Monte on Nov 2, 2010 at 9:05:43 AM (# 7)

What if I cut the time down to one second? OR 5 seconds? That's my real concern. I want it to be as near real-time as possible, given the limitations I illustrated earlier.


bod1467 on Nov 2, 2010 at 9:40:44 AM (# 8)
This message has been edited.

5 seconds wouldn't be an issue (IMHO). 1 second updates is possibly a bit too fast, as you need to also consider DNS lookups, transport times client <-> server, etc.

And brian's suggestion of JQuery would be easy to implement, but simple Javascript AJAX code is only a few dozen lines of code without the need for several (hundred?) KB of other JQuery bloat. ;-)

	var xmlHttp;
var resp = '';
try {
// Firefox, Opera 8.0+, Safari
xmlHttp = new XMLHttpRequest();
}
catch (e) {
// Internet Explorer
try {
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e) {
try {
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
}
catch (e) {
alert ('Your browser does not handle the AJAX process.');
return false;
}
}
}
xmlHttp.onreadystatechange = function() {
if (xmlHttp.readyState == 4) {
resp = xmlHttp.responseText;
if (resp != 'OK') {
alert ('There was a problem getting the timestamp.');
}
}
}

// Send the info to the PHP handler page
var tstamp = 'ticker.php?gameid=' + gameid;

xmlHttp.open ("GET",tstamp,true);
xmlHttp.send (null);

Monte on Nov 2, 2010 at 10:04:10 AM (# 9)

So, if I understand you right, the timestamp would be a field in the DB. Then, all I would need to do is query that field, and compare it to a timestamp JS variable. If they don't match, then I would get the game update. Otherwise, I would just wait the 5 seconds and do it again.

Is that correct?


bod1467 on Nov 2, 2010 at 1:06:46 PM (# 10)
This message has been edited.

Yes. e.g ticker.php would be a PHP file that connects to the database and returns the value of a timestamp field. The value of that field would only be updated when there is a game update. (You would need whichever page applies the game update to also update that timestamp).

You would then use another AJAX call (e.g. to gameinfo.php) to get the latest info and refresh the contents (innerHTML) of a DIV element. The JS timestamp value would then be made equal to the database timestamp.

Thus, until the next game update then ticker.php would see the same timestamp as the JS variable. Obviously, the first time the client web page is loaded the JS timestamp is 0, so you will always get the game data.

PS - my consultancy invoice is in the post. ;-)


brian on Nov 4, 2010 at 2:14:01 AM (# 11)

I agree with bod to an extent on the bloat but jquery is only 84kb minimised so not as bad as the likes of extJS for example (love jQuery, hate extJS with a passion and won't be using every again after end of year). The jQuery data will be far more compact than the ajax data so comms is generally faster but it really depends on the data you need to fetch, sizes etc. As it happens, when you use Ajax too there's generally a massive code overhead since each browser has different ways of handling XML requests - IE being the one causing the most grief.

As for the output to a ticker, the json and ajax code should be similarly sized, the only difference is how you treat the data and since the json comes through as a pre-parsed array of structures it is really easy to work with.

Thing is, you could use ajax to deal with the data request in json format and parse it - I experimented with it before I used jQuery - there is little performance difference for small data requests but there are differences - jQuery was generally better and as a rule produces more compact code since everything usually uses $ for commands.

1 second would probably be too frequent and for large user numbers could cause server issues. 50 users would involve 50 requests a second which is 3000 requests a minute, 180,000 requests an hour and so on. Factor in processing time to get the relevant data from the database it could be making another request before the first is finished, especially if you have lots going on concurrently.

Regarding silverlight - just noticed this. All you would need there is a web service - silverlight could use asynchronous calls to the web server to get the data. Still, 1 second would be mostly too frequent.

If you're talking scores or status updates, I doubt people could type messages or change scores faster than 10-15 seconds between changes and I doubt there'd be scoring happening that frequently anyway so worst case a user would not see the change for 9.99 seconds in a 10 second interval.

The best example I can give you is when the BBC covered the World cup on their website - there was typically a 1-2 minute lag between updates as the reporters typed up the messages and them being checked. That would be considered acceptable.

Last thing regarding JSON. Useful sites:
www.jsonlint.com is a JSON validation site. Makes sure your data is well formatted for the parser.

www.json.org will give you the specification for JSON file formats. A little tricky to follow at first but handy. Also includes links to other resources.


Earlier Replies | Replies 5 to 11 of 18 | Later Replies
Goto Page: 3 2 1

To respond to a discussion, you must first logon.

If you are not registered, please register yourself to become a member of the SiteExperts.community.

User Name
Password
Copyright 1997-2004 InsideDHTML.com, LLC. All rights reserved.