Little bit of threads and little bit of instant messenger design

[ankursaxena]

OK! i have a small problem here, i am planning on making a instant messenger server and client, not compatible with any out there(as of yet) and not using any stansard protocols out there, just something i made on my own. ok now the problem i am trying to figure out is....i have a "Messaging Server" as the name suggests it sends messages from one client to the other, how it is setup is, client connects to this server, the server accepts and creates a new thread for this client and adds a message listener to this client handler thread. as and when the server creates this thread for the client, it puts it in a vector which is keeping track of every client connected to this server. so now when the client sends a message to another client, basically it goes through this server, the thread upon receiving this message, fires a method of the listener. this method takes the message, finds out who it is going to(therefore the userid) and seaches the threads vector to find the appropriate thread and then just creats another striped down message out of the received message and calls a method in that thread to send this newly created message and hence the message should be sent.(i am speculating, i still have not created this)

so the problem ia m logically facing is...at what point of time who is taking the load, what i mean by that is, when the thread receives the message, ofcourse it is this thread which is working is taking the load, but when the listener fucntion is fired which thread is handlign the call is it the client handler thread which fired the method or the messaging server thread which creates these threads?? now once that is solved, who(which thread) is doing the work when i call the fucntion in the other thread which i found aftre searching the vector. i mean i am thinking like this cuz i am not much in sink with the way threads work. i am also trying to figure out this to find out the load the server or the threads will be having.


algo example:

class messageServer
{
vector currentWorkingThreads;
messageListener listener;
...
main()
{
listener = new messageListener(); //should it be here or the other place i am mentioning below
while(true)
{
clientHandler = socket.accept();

listener = new messageListener(); //should it be here or the other place i am mentioning above

//create a thread and add this thread object to the vector
thread.addLisenter(listener);
}
}
}

class messageServerThread
{
string userid;
messageListener lis;
...
run()
{
object obj = in.readObject();
lis.sendMessage(obj);
...
}

sendMessage(obj)
{
out.writeObject(obj);
out.flush;
}
}

class messageListener
{
sendMessage(msSendMessage msg)
{
//find the appropriate user thread
loop(currentWorkingThread.next())
{
messageServerThread msgThread = (messageServerThread)currentWorkingThread.element();
if(msg.userid == msgThread.userid)
{
msReceiveMessage rcvMsg = msg.strip(); //dosent matter what this does, it just strips the unwanted info and returns the type msReceiveMessage
msgThread.sendMessage(rcvMsg);
}
}
}
}

and if this is something out of the line, or not a good way of doing it, can someone help me with the design it would be gr8.
thanx a lot
-Ankur
help would be greatly appreciated.
ankursaxena@hotmail.com

 

[Guest_imported]

It sound like a working solution but I suspect there may
be a simpler way. First if you use a server socket on both
client and server then part of the threading is solved for
you since the server socket maitains it's own thread while
listening. Then once a message comes in at the server you
can spawn one thread which would send updates to all the
appropriate clients. (If you maintain some type of
collection of conections that are left open or open new
ones each time is up to you.) On the client a similar
approach would be taken. When an update comes in the client
spawn a thread to update the screen. Sending messages to
the server could run on the main application thread from
the client. This approach will probubly not need any type
of synchronization.