Is there a way to update a picture live and dynamically? Let me explain:
There is an application that uploads a picture in a various amount of time. At the moment, my script just ask every 5seconds for a new picture on the server but thats kinda old school and not a very good solution. So my question: Is it possible to detect a new picture on the server and show it immediately on the page?
The problem with regulary requests (every 5seconds) is that if the picture is loaded after a request it takes like 10seconds to update and thats a bit too long. And to make a request every second is quite a bad idea.
You will need server side push technology (also known as Comet) to do this. The exact implementation is really dependent on the server-side programming language you are using.
Edit:
A quick search on stackoverflow on 'Comet' gives a lot of additional info (also specific to certain programming languages): https://stackoverflow.com/search?q=comet
Related
So, I have made a script that attempts to solve a slitherlink puzzle ( not relevant to the question, but here are the rules: http://en.wikipedia.org/wiki/Slitherlink )
The script runs at: http://www.kokkorogiannis.gr/slitherlink/ and it solves the puzzles I have given it.
When the algorithm runs, it goes through many steps. In each step it solves a little bit of the puzzle. For example, all the steps for this puzzle are at: http://www.kokkorogiannis.gr/slitherlink/?showdos=1
Now, I want to do the following: Instead of showing each step (each board state) the one under the other, I want to show the initial board, and then, as I walk through my script, to change the board, showing its progress.
Problems:
I know that php is server side only, so once it sends something, there is no way to modify it.
I could use javascript and ajax, and program my javascript, every second or so, to ask the server for the changes to show, but: ajax is asynchronous. Each request stands alone, so the server would not know that to show next.
One solution would be to run the algorithm once (and not each time the page gets requested), save the state, or the changes in a db, and just use php and js to show it (sending the next state, or the changes each time they get requested). But I dont like this idea, as it does not solve the puzzle, just shows different states (and any modifications to the algorithm don't get reflected).
Working on an other technology (not web), for example at a desktop or mobile app, I could do what I wanted, show the progress. But how could I do that in the web?
K.
I'm running an enterprise level PHP application. It's a browser game with thousands of users online on an infrastructure that my boss refuses to upgrade and the machinery is running on 2-3 system load (yep linux) at all times. Anyhow that's not the real issue. The real issue is that some users wait until the server gets loaded (prime time) and they bring their mouse clickers and they click the same submit button like 10 - 20 times, sending 10-20 requests at the same time while the server is still producing the initial request, thus not updated the cache and the database.
Currently I have an output variable on each request, which is valid for 2 minutes and I have "mutex" lock which is basically a flag inside memcache which if found blocks the execution of the script further, but the mouse clicker makes so many requests at the same time that they run almost simultaneously which is a big issue for me.
How are you, the majority of StackOverflow folks dealing with this issue. I was thinking of flagging the cookie/session but I think I will get in the same issue if the server gets overloaded. Optimization is impossible, the source is 7 years old and is quite optimized, with no queries on most pages (running off of cache) and only querying the database on certain user input, like the one I'm trying to prevent.
Yep it's procedural code with no real objects. Machines run PHP 5 but the code itself is more of a PHP 4. I know, I know it's old and stuff but we can't spare the resource of rewriting this whole mess since most of the original developers left that know how stuff is intertwined and yeah, I'm basically patching old holes. But as far as I know this is a general issue on loaded PHP websites.
P.S: Disabling the button with javascript on submit is not an option. The real cheaters are advanced users. One of them had written a bot clicker and packed it as a Google Chrome extension. Don't ask how I dealt with that.
I would look for a solution outside your code.
Don't know which server you use but apache has some modules like mod_evasive for example.
You can also limit connections per second from an IP in your firewall
I'm getting the feeling this is touching more on how to update a legacy code base than anything else. While implementing some type of concurrency would be nice, the old code base is your real problem.
I highly recommend this video which discusses Technical Debt.
Watch it, then if you haven't already, explain to your boss in business terms what technical debt is. He will likely understand this. Explain that because the code hasn't been managed well (debt paid down) there is a very high level of technical debt. Suggest to him/her how to address this by using small incremental iterations to improve things.
limiting the IP connections will only make your players angry.
I fixed and rewrote a lot of stuff in some famous opensource game clones with old style code:
well, i must say that cheating can be always avoid executing the right queries and logic.
for example look at here http://www.xgproyect.net/2-9-x-fixes/9407-2-9-9-cheat-buildings-page.html
Anyway, about performace, keep in mind that code inside sessions will block all others thread untill current one is closed. So be carefull to inglobe all your code inside sessions.Also, sessions should never contain heavy data.
About scripts: in my games i have a php module that automatically rewrite links adding an random id saved in database, a sort of CSRFprotection. Human user will click on the changed link, so they will not see the changes but scripts will try to ask for the old link and after some try there are banned!
others scripts use the DOM , so its easy to avoid them inserting some useless DIV around the page.
edit: you can boost your app with https://github.com/facebook/hiphop-php/wiki
I don't know if there's an implementation already out there, but I'm looking into writing a cache server which has responsibility for populating itself on cache misses. That approach could work well in this scenario.
Basically you need a mechanism to mark a cache slot as pending on a miss; a read of a pending value should cause the client to sleep a small but random amount of time and retry; population of pending data in a traditional model would be done by the client encountering a miss instead of pending.
In this context, the script is the client, not the browser.
First I'll outline my problem.
What I want to do is create a site. When a client connects, every second or so a number will be broadcast by him.
This is done by everybody on the site.
So every second every client receives every other clients number.
My Solution (that isn't currently making sense)
I thought of using XMPP and an OpenFire server to do this, but I can't seem to make it work with PHP.
Finally the question
Is there a better way to solve my problem than the one I outlined? Another potocol or something?
Is there something that'll play nicely with OpenFire
I already looked at these
http://code.google.com/p/xmpphp/
https://github.com/tong/hxmpp/
and Happy new Year,
XMPP, is the most common way with dealing with notifying problems, but yet you can use a less heavy approach (Technique) to deal with your problem which is Pushlets, and for sure the previous link is not the only one. Pushlets area servlet-based mechanism where data is pushed directly from server-side to (Dynamic) HTML pages within a client-browser. This allows a web page to be periodically updated by the server.
and sure it's much lighter than XMPP.
you can also use it with Java server side like in Here, which will give you some new ideas.
anyways, if you have a web application which has a lot of users you have to think twice then. and make sure that XMPP gives you a lot of controlling features over many requests. When pushlet is good enough to do your broadcasting.
Hope that will help you.
Read this http://belski.net/archives/37-Phurple-for-PHP-5.3-and-up.html
You can make it work with PHP+XMPP using the phurple extension. It works upon libpurple which is the base for Pidgin. That will make you able to work with many other protocols as well, XMPP will already enable Facebook, Google and any other XMPP based.
I'm refactoring an API where there are user profiles from a profiles table and profile images in a separate table. Currently the API queries the profile tables, and then loops through the images table for associated image data (paths etc). There is logic built in that adds a default img path when a profile image isn't set. So if we are displaying 50 profiles there are 51 queries being run.
I'm considering refactoring where the initial profile query joins the image table. I'm now left with two options.
I can loop through the results server side to build the image paths. I will have to loop through them again client side to display the results.
I can loop through the results one time client side and build the image paths there. The path logic is easy and a simple if statement.
It seems 2 would be the logical choice. But is it? I guess this is part of a bigger question of when you are building out APIs and the client side interfaces when do you move code from the server to the client to keep the API fast at risk of slowing down the browser? How do you do this dance? I'm working on another API using Node for the jquery datatables plugin where there needs to be a lot more code to marry the backend, and it's been a bit of a tug of war determining how much I should hand over to the browser. A fast API is of not much use if you are crashing your visitors browsers.
The tipping for the decision for me, would be
Am I by exposing parts of the component path, so the client can build it, exposing something I don't want to.
vs
Am I by constructing the image paths server side doing work that the client might not need, or that the client might have to redo, like chopping them up on occasion for instance.
In terms of passing more data than is needed, I'm not seeing an issue from what you've said, and the first question would be one with the most priority for me.
Sort of stretching in this scenario, but the client having to know how to compose the image path, sets a few constraints, whereas if it's all done server side the implementation details are hidden. Despite them being simple, that would be my default option
As you've said it's a tug of war. Another way to look at issues like this, is the "right" answer can depend on when you ask the question. You could go one way and them a bit later, some new requirement pops up, and now it's the wrong one....
Simple and consistent is the thing to aim for. Right as in best? 20/20 hindsight time.
When I've seen and done this in the past I've found it better not to store images (like what it sounds like you are doing) in a db. Put them in a place where the browser can link to them and pass the path from the server.
If I understand you correctly.. you are displaying some sort of profiles list where each profile has associated image... right?
Abstracting from the way you store images(db or vfs images are faster but straight files - with at least minor MRU Cache - are easier to maintain).
Solution numero uno is the right way to go.
It is just simpler and more "restful". I am a huge fan of client logic, but we should use it for a good cause(such as Soopa-UI). Same goes for db logic code vs server logic code. I dislike sql and having to maintain another layer of problems, but I do understand the difference it makes in some cases to the final result.
EDIT: Oh... you are storing just paths.
So if you are not doing some fancy one page web app then there is another problem with building paths client side. Client would have to wait for script to finish loading before his images would even start to load.
After searching the web for a good Comet and also and asking you guys what my best option is, I've chose to go with Orbited. The problem is if you need a good documentation about Comet you won't find. I've installed Orbited and It seems It works just fine.
Basically, I want to constantly check a database and see if there is a new data. If there is, I want to push it to my clients and update their home page but I can't find any good and clear doc explaining how constantly check the database and push the new info to Orbited and then to the clients. Have you guys implemented that?
Also, how many users can Orbited handle?
Any ideas?
You could add a database trigger that sends messages to your message queue when the database got changed. This is also suggested here. Or, if it is only your app talking to the database, you could handle this from within the app via a Subject/Observer pattern, notifying the queue whenever someone called an action changing something in the DB.
I don't know how good or bad Orbited scales.
Have a reference table that keeps track of the last updated time of the source table. Create a update/delete/insert trigger for the source table that updates the time in the reference table.
Your comet script should keep checking the reference table for any change in the time. If the change is noticed, you can read the updated source table and push the data to your client's home page. Checking the reference table in a loop is faster because the MySQL will serve the results from its cache if nothing has changed.
And sorry, I don't know much about Orbited.
I would use the STOMP protocol with Orbited to communicate and push data to clients. Just find a good STOMP client with PHP and get started.
Here is an example of a use case with STOMP, although the server side is written in Ruby:
http://fuglyatblogging.wordpress.com/2008/10/
I don't know if PHP with Apache (if that's what you are using) is the best suite for monitoring database changes. Read this article, under the section title "Orbited Server", for an explanation: http://thingsilearned.com/2009/06/09/starting-out-with-comet-orbited-part-1/
EDIT: If you want to go the route with PHP through a web server, you need to make one, and one only, request to a script that starts the monitoring and pushes out changes. And if that script times out or fails, you need to start a new one. A bit fugly :) A nicer, cleaner way would be, for example, to use twisted with python to start a monitoring process, completely separated from the web-server.