tags:

views:

373

answers:

1

Hi, I'm trying to do an Omegle.com clone script, basically for learning purposes. I'm doing it in PHP/MySQL/AJAX.

I'm having problems finding two users and connecting them. The purpose of omegle is connecting two users "randomly".

What I'm doing right now is the following:

  • When a user enters the website a session is assigned.
  • There are 3 states for each session/user (Normal,Waiting,Chatting)
  • At first the user has state Normal and a field "connected_to" = NULL
  • If the users clicks the START button, a state of "Waiting" is assigned. Then it looks for another user with state Waiting, if doesn't find one then it keeps looping, waiting for the "connected_to" to change. The "connected_to" will change when other user click START and then find another user waiting and updates the sessions accordingly.

Now this have several problems, like:

  • A user only can be connected to one user at a time. In omegle you can open more than one chat simultaneously.
  • I don't know if this is the best way.

About the chat, each user is polling the events from the server with AJAX calls, I saw that omegle, instead of several HTTP requests each second (let's say), does ONE request and wait for an answer, that means that the PHP script is looping indefinitely until gets an answer.I did this using set_time_limit(30) each time the loop is started. Then when the Ajax call is done start over again. Is this approach correct?

I will appreciate a LOT your answers, Thank you,

Carlos

+1  A: 

I personally don't see much of a difference between polling the server and leaving the request open indefinitely, as they both have obvious pros and cons. Try both and see which one costs more. If having the server busy handling several clients ends up causing timeout errors for new visitors, then that's not really a good situation for a chat room like yours.

You might, once you have more things worked out, also want to look into a comet server or even web sockets, but I'd focus on making the chat/match features work first.

So, if user's can have multiple chats, but they still are paired one-to-one per chat, I'd personally think about a solution where, if a user wants a new chat (assuming it's voluntary), they actually start a new session. Make it so that each user object, can have multiple (or infinite) chat sessions, each one like you described: "normal; waiting; chatting". So that if user A enters a room, he taps the "ready" button and this changes his initial session from normal to waiting. Once he meets up with someone, a new "normal" session gets tacked on, and he can change that one to "waiting" by hitting some button, etc.

One thing that might make the constant looping go down a bit is to simply query how many available or "waiting" users there are. If it's 0, keep checking until it's higher than 0, rather than looping through all members in the room to see if they are waiting or not.

On second thought, instead of 0, make it greater than 1, because if you have a method that counts the total, your guy waiting will be counted.

Anthony
Thanks. You gave me an idea of how to proceed. But you didn't say your opinion about the procedure I'm using to match the users. Do you know of a better way, like a classic way of doing this? I don't want to reinvent the wheel. Thanks man.
Carlos Dubus
Additionally, you could test the result of your UPDATE to see if the query took. So, say you have a user that is in "waiting" status and another user that is initiating a chat. You run: UPDATE sessions SET status = 'chatting' WHERE userid = ? AND status = 'waiting'. Then if that UPDATE affected 1 row you *know* that the user went from waiting to chatting and is thus good to go. (I tried to separate this content out in to paragraphs but stackoverflow's javascript is obnoxious).
dpk