Sockets – Design Pattern: Client – Server

Architectureclient-servercommunicationdesign-patternssockets

i am going to implement a client – server application in java. Client and server communicate with each other via TCP. There is only one central server, who handles all Client messages.

I don't use RMI for the communication, they communicate with tcp-sockets and a client can communicate with another client through the server. That means that the server forwards messages from client A to client B.

Now im sitting here and try to figure out how to design the server application.

So the server is listen for incomming connections all the time. Thats fine. For every new client, that get connected to the server (dial-up), the server create a new Socket and i would use Threads to let them work concurrently.

Every User uses a client, and every client must be authenticated with a username and password.

Im searching for a design pattern to implement on the Server, that stores/handles the Socket connection to a client.

My first idea was to create a big Singleton object called ClientManager that contains a Map. So the Server could call something like ClientManger.getSocketBy(username) to get the Socket of the desired User (Client).

This could solve the "forwarding" of messages from Client A to Client B.

For expample:
User A (Client A) would like to send a message to User B (Client B). So the server receives the message from User A (Client A) and call ClientManager.getSocketBy(User B) to get the communication socket to the User B, and then send the message through this Socket.

But this "design" on the server side seems to me to simple as it could be a good design for such a thing, and im missing something like Events, Observer etc.

Another possibility could be to throw an Event to the Thread that handles the User B socket connection instad of calling the Socket.send() method directly.

But there must be a better way …

Is there a common way to implement something like this a design pattern that you can recommend? Im wondering how a instant messanger server would implement this?

By the way: im not implementing a instant messanger and the scalability is not the most important thing, since there are not 1000 of clients at the same time communicating with the server. A clean software design is more important for me.

Im implementing a own Protocol (xml based) for the communication. Is there a way/design pattern how to wrap a protocol in a object or is there nothing i could do (from the sofware architects view) excepted string / xml parsing?

Best Answer

You have two questions I think.

The first is in regard to what "design pattern" to use for your routing. You indicated what you were doing, but you didn't indicate what problem you are experiencing (or anticipate experiencing) other than to say it was too simple. Patterns are common ways to solve common problems, but a program being too simple is not one I've seen a pattern for :)

The second question is about separating the implementation of your protocol from the clients that use it. Now that is a good question and something you should definitely do. You are going to want to create a Message object that exposes the fields (like To, From, Content, etc). Your server needs to pass the raw xml data into some type of parser that acts as a Factory for the message objects.

Message msg = protocol.CreateMsg(byte[] xmlBuffer)

You can support additional protocols by assigning a different one to each TCP/IP Port or by starting with a default protocol and then having the client and server negotiate a different protocol.

EDIT1:

I would not map a socket to a User, to be honest. I would abstract the way you communicate with a User into an object, perhaps Connection or Channel. You would then subclass the Connection with TcpConnection or CorbaConnection or whatever. Ideally you are doing something like:

string destUserId = msg.To;
User destUser = UserManager.Find(destUserId);
Connection conn = destUser.Connection;
if (conn != null)
   conn.Send(msg);

Note that there is no mention of the connection or the protocol implementation details.

Related Topic