Multi-threaded server design question

I have a primitive, in-the-works, IM server/client. The underlying principles:

-Server has support for multiple client connections.

-Currently, server only supports receiving usenames/passwords.

-Clients send a message category (mCat) to the server, and the server acts accordingly (actAccordingly()), calling specific functions.

-Server has a thread to accept connections from clients, and creates threads for each one.

-Each of these threads runs a main loop;

Code:

---

//Psuedo-code
void clientsThread(int* s)
{
 while(1)
 {
  int mCat = getmCat(s);
  [Check for any errors and deal with them (break, or continue)]

  actAccordingly(mCat);
  [Check for any errors and deal with them (break, or continue)]
 }
 [Remove any handles associated with this thread/socket]
 CloseThread(handle_to_this_thread);
 closesocket(s);
}

---

-The server does not use any mutex's, and doesn't use a FD_SET of all the clients connected(Should I need these?). I have arrays of index's of the clients, usernames associated with the sockets, handle to thread associated with the socket, etc.

The problem I'm experiencing (if it's at all evident in the information I've supplied), is that clients' requests seem to get mixed up serverside, and undesireable effects happen, such as incorrect logins with correctly supplied un/pw's.

I'm perplexed by this, as each client's request should be sovereignly handled with each of the correspondly threads, correct? Each thread should be able to invoke multiple instances of the same functions... They don't share any cross-thread/cross-socket data members... :(

Any comments?

In regard to your design, how do you destinguish among different clients?

Kuphryn

I just used the computers integer value of the socket connection stored in an array.

But alas, I've gotten it workinga few days before. I'm ashamed to admit it was a flaw (a very simple one at that!) in my design and nothing else. But throughout all the debugging, I did manage to finally make each client have it's own thread, and I now use the mutex's..