chat management

[alexho]

i have developed a chatroom running with js/ajax on client, and php for server side storing data in mysql. My only real issue is the method i use in having registered (site members) being logged in right as they enter the page -- And being logged out when they leave; thus being added/removed from the table...

possible methods for this that i tried but dont work well for me are using onload/onunload which are not really reliable enough.


i though about using Java as some applet in the page for monitoring and passing data more easily, but im not sure what to use and i haven't used java that much so.. For the chat I need a better way of managing the users IN real time, more reliably....

or possibly a timeout using php time() recoreded last updated ping greater than a value then user is assumed logged out

does anybody have experience in creating chatrooms? or have any knowledge of Java and possible implements to this which could guide me to the right direction?
tyvm

 

[enouwee]

You really shouldn't rely on the client to be nice and tell you it's leaving. Just like the IRC servers, keep track of the last data pushed/pulled to the browser and remove the client when it's been idle longer than a grace period.

Or join the "ultimate" chat theory thread [THREAD=110587]here[/THREAD].

 

[alexho]

what i have is 2 divs 1 for users 1 for content. within the content of user div i add new divs with ids of the users. so dynamically when users leave it removes that user from all clients in the parent user div.
^^^ that is what i was hoping to do.....

//client idle afk w/e kick using ajax
in the client i make a timeout of 60*60 seconds every sent post made it counts off to kick them from the chat idle users who just sit there will eventually get kicked out.

now for users who leave in any way disestablished from the server:
in the request i send, suppose i have a variable user=test

server get:
for kicking idle grace periods..
mysql find user test in table get last activity/ping currenttime-lastactivitytime()

if the sent request grace period is every second and lastactivity is > grace period then user removed from chat. and it sends a bit of data to all clients marking user id to be removed from the users div.

this is doing it for all connected clients--alot of load it would seem

how do i do this server side effectively? checking whole user in chat table for last ping time and removing all users > grace period its a bit cumbersome

i will not rely on the client for anything but data retrieval, that was a test workaround.

 

[enouwee]

this is doing it for all connected clients--alot of load it would seem

how do i do this server side effectively? checking whole user in chat table for last ping time and removing all users > grace period its a bit cumbersome

i will not rely on the client for anything but data retrieval, that was a test workaround.

Through a paradigm change: by pushing data to the connected clients and not having them repeatedly poll for new things. If it works for the big ones(TM), it should be fine for you.

I posted a link to a sample implementation in the other thread, here's another blog post with a nice time diagram.

You can further improve performance by getting rid of the database, which is entirely useless, given the ridiculously little data you're managing. I'd run an non-blocking application that handles the "persistent" client streams and keeps the whole data (chats, members) either in-memory of MMAPed to disk.

PHP won't be a good choice though for such an implementation. I'd rather rely on a heavy duty server (written in C/C++ or Java). See CometDaily for more information.

Not the "easy-to-implement" answer you expected? Sorry, this is the price to pay for improving server-side performance.

 

[alexho]

thanks, and for the diagram.
i didnt expect it to be easy to implement, but for my situation i guess it is ok and best i keep it simple. it is more of a simple chatroom, with 1 room. i will have to put more boundaries and limits on it. but if my situation demanded a very active user base then id have to and it wouldn't be an easy implementation. ill have to do with what i have.