Help needed to built a chat feature.

[napster7]

I want to built a feature on my website for a project where a user can see a new post sent to him without refreshing the page.

What i am doing now is that i call a function every second to see whether a new post has arrived or not? But this is not a good programming practice.

Hence my question is that, how do i make it possible for the server to say to the client that a post has been arrived for you. Then only the client should call the function to fetch the post and not every second.

I found some topics here, but were not useful.

Please help me.

Thank You.

 

[DeadBattery]

I don't mean to interrupt here but just to let you know, chats aren't allowed on x10Hosting servers.

 

[napster7]

Sorry.. but i didn't mean to use chat on x10 servers.

Actually it is a part of my college project, hence i thought i could get some help over here.

 

[lostcommander]

This rather depends, napster7, on whether you mean to alert people as to when they have received a PM (ala Facebook's notifications) or whether you mean something like AJAX Chat (disallowed on x10) or a shout box (disallowed on x10).

In any of those cases, though, to the best of my knowledge you will have to refresh at least part of the page since HTTP servers NEVER initiate contact with a client over the internet. One way around this is to write some JavaScript that appends a JavaScript file written in PHP (which includes the database calls to find out whether there are any new messages or not yet, and the JS to change display values as needed) to the current page. The client will then make that request at some standard interval. The difference then is then only the interval length and how interactive you want it to be: e.g. Gmail rechecks like every 2-5 minutes, Facebook seems to check every 1-3 minutes, and JS+PHP+MySQL -powered web chat probably checks every few seconds (making a TON of page and database calls in the process, which is why they are not allowed around here).

 

[essellar]

Chat apps will always be "chatty", and over HTTP(s) they will always have to be client-pull, but they don't need to be particularly expensive in terms of data traffic or database calls. Ajax requests, for instance, can be HEAD requests until a new message is found, message data can be persisted in memory rather than going through the database, etc. I'm building something similar but a bit more ambitious on Google AppEngine right now, and the bandwidth and resource usage is really pretty small, thanks in large part to the memcache feature and HEAD requests. Think hard about what actually has to travel over the pipes, and what the check interval really needs to be to seem responsive -- I was able to build a live, near-real-time charity auction site on a single-processor 800MHz PIII Lotus Domino server (with a full 256MiB of RAM) that supported 1500 concurrent users and 40 simultaneous items up for bid back in 2001, and I had to use iframes/ilayers to do it since XmlHTTPRequest was an IE-only thing (and you couldn't count on MSXML being installed).

Chat can be done in a lightweight, efficient manner. But then, so can most webby things -- I consider it a failure if any web page I create causes more than five requests on load or "weighs" more than 20K all in (including cachables), but I've seen a lot of static, do-nothing pages that load Dojo, a 50K CSS file and a thousand tiny images for no reason, simply because the developer didn't think. Don't become one of those.