Just one note:
try
{
}
catch (Exception e)
{
throw;
}
is strictly equivalent to having no exception handling in this fragment, logically, but it just wastes resources. Not having exception handling in this fragment would be the best option. If you are going to write the rest of you code in such a manner, the rest of it presents no interest to me: I would not bet a cent for your project.
Besides, what's the idea: a thread per client (sorry for asking, I want to make sure)? This would be a bad idea, not scalable. The number of threads should not depend on the number of clients.
The question on "client to client" does not make much sense. Let's put it this way: forget client-server model, it's too limiting. Any part of the application can play the role of a server and a client at the same time, in relations to some other parts. However, a TCP channel is asymmetric, it terms of establishing of a connection: one side is a listener and accepts a connection, another part connects. When a connection is established, both parts can read and write to a socket, according to some
application-level protocol you can devise. Start from this point. I don't want to give you further recommendation, because I don't know what kind of communication scenario do you have in mind.
—SA