Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 2 of 2
12-03-2012, 07:30 PM #1
- Join Date
- Nov 2006
- Thanked 1 Time in 1 Post
Update database and ticker simultaneously, saving bandwidth?
I was hoping to gather some opinions on how I'd go about the following:
I'm first looking to create an admin page for admins of my website to update my database (add, edit, delete records). This will be admin.php. The database has three tables - Merchants, Issues, Updates.
I'm also looking to include a ticker (for simplicity's sake, a HTML marquee) on index.php which will contain the last record of certain fields from the database's tables.
The purpose of the database is to record issues with merchants. There are updates to those issues. The ticker is meant to provide live information to my colleagues of new issues.
What is the best way to update the ticker without using much bandwidth?
I have limited knowledge of these things. I can only see two options:
1. Having the ticker check the database every five minutes (bad news for bandwidth?).
2. Make the last update posted through the admin.php form get submitted to the ticker?
Not a fan of option 1 if 20 PC's are doing that.
If I use option 2 and a user logs into my website after the last issue was submitted via admin.php, will they still see it without the script constantly checking the database?
Maybe if when logging in, the script checks the database for the last record(s) once and then accepts new updates via admin.php from that point onwards?
I could probably do it that way and add a manual refresh button for the ticker to call the current last record(s)?
Sorry I'm just thinking out loud here. Please let me know what you think. Thank you.
12-03-2012, 07:45 PM #2
- Join Date
- Sep 2002
- Saskatoon, Saskatchewan
- Thanked 2,659 Times in 2,628 Posts
You don't have a lot of options here.
Since you are using a stateless protocol, you cannot push the updated event change directly to a client. The client has to go ahead and request that themselves. If you use something like AJAX, at least you can make it look flawless in the access.
So in a diagram type of description:
Client A retrieves data
Client B retrieves data (client A and client B see the same data)
Client B modifies data
Client B retrieves data (client A sees original data, client B sees modified data)
Client A retrieves data (client A and client B see the same data)
No matter what you do, you'll need to consume throughput in order to make all client's see the same data. If they refresh the page or if you use AJAX to determine the new data, no matter which the case they need to access the script to generate the data again. This is simply the behaviour of using a stateless protocol. The server cannot force the client (or even request it for that matter) to update.
PHP wouldn't be the best solution for this; it works fine in a server level (where I have the php interpreter), but you could create a socket program to listen and connect to another PHP page that establishes as a socket server. Then pump messages through and displays. Works good on cli, not so much in browsers as even flushing doesn't really work the way it used to. A better option for that would be java or C# using an actual gui application and can respond to events easily. No matter what though, you need to consume throughput to get the message through.