developing a intranet messenger system

[Anonymous Monk]

hi. i hav developed a intranet messenger system but problem with the logic is that i m storing the messages in the database and then it is being retrieved by respective users automatically after 1 sec. The message queue get deleted from the database when a paticular user logs off. plz tell me if there is a way to store the messages in a buffer at server side which is accessible by all users so that they need not to retrieve the messages from the database which results in a number of disk read and write.

[davido]

If the problem is that having multiple recipients polling your system every second is resulting in too much load, you could turn the system upside down and make it a server push system instead, where each client's application just sits there listening on a port for a message to be forwarded. Your server could poll a client to see if they're reachable, and if so, push the message their way. If not, then store the message in the database until the user does log in. On your server side you'll have to operate a small daemon also that receives logins from the clients, and upon login, pushes any stored messages to the client. The same daemon could receive messages from logged-in clients.

I don't know a lot about intranet messaging systems. But it does seem to me that it would be a lot lower load on your server if it operated in a sort of push mode rather than in a mode where each client polls once per second. On the other hand, POP servers handle with grace and ease the fact that email clients (potentially thousands of them) are polling at user-defined intervals that could be very short. So maybe that's not such a bad arrangement after all. ;)

Do you have any code to show? How exactly is this question related to Perl?

[perrin]

Perhaps you're looking for IRC? Or Jabber?

[gmpassos]

What you should do is a IPC between each client, where the server is used only to point the IP and port of each client. So, when A send a message to B it need to have the IP:port of B, than connects to that port and send the MSG. If A send the same message to B, C and D is the same thing, but for many ports. Is simple to do and uses less bandwidth since you can apply this process over UDB.

[brij_dumca]

hi i hav made a intranet messenger system more or less same like yahoo messenger.But problem with it is i m storing the messages in the database which is then retrieved by the respective users automatically after 2 sec. The corresponding message queue get deleted after the corrosponding user log out. Plz tell me a way to store the messages in a buffer at server side (using cgi + perl)which could be accesible by all the users logged in so as to save so many disk read and write done during storage and retrieval of messages from the database.

[davido]

Only save to mass storage messages that are older than some amount of time. That way, the quickly retrieved ones are never committed to storage, and only the ones that hang around for longer periods of time get saved away for later retrieval.

For this to work you would probably need your script to stay resident, which sounds like mod_perl.

Update: Oh, and you can also read all the answers you go the last time you asked this question here: developing a intranet messenger system. :)

[data64]

I guess you could use SQLlite and get it to store the file on some kind of Ramdisk. Otherwise you might have implement datastructures to hold the stuff in memory yourself. This will have to some process external to CGI so that different threads from the webserver can access it concurrently.

Rather than re-implementing an instant messenger system, have you looked at using Jabber ?

[TedPride]

Keep a file for each logged in user that is updated each time a new message arrives (maybe with the line numbers of the messages?). Then all the client has to do is check if the updated time has changed since the last access, and if it has, only THEN access the database. The file can be deleted if a user logs out, and also deleted if an expiration time is reached (let's say if the user hasn't logged in for 24 hours), thus keeping the number of files relatively small, or at least smaller than your total number of users.

Having the client listen for messages instead of checking for them would of course be the more elegant solution, but that method requires a good deal more complicated programming and most likely comes with problems of its own.

A third possibility is to vary the access speed so you get 1 second accesses within x minutes of your last message (in or out), then a gradually slower access speed down to eventually 30-60 second accesses. This should significantly cut database calls without hurting your messaging system much or requiring complicated rewrites.