How design tcp communication with different design patterns?

Question

I am actually planning a small tcp client/server. In the architecture I would like implement design pattern as many as possible.

At the moment I have a architecture like this: The Client send a packet to the server. In this packet, there is a header with information like username, password, packet type, identifier and other stuff like this. They're also a body (it's only a array of bytes)

If the server retrieve a packet from the client it will be parsed. For each package type exist only one parser. Each parser handle different with the body/content.

For example the Client sends a packet with the packet type register to the server. The server select the "register parser" and handling with the information in the body. In this for example are strings like username, password, email and some thing else for registration...

Each packet can have a response. For example if the client sends a packet for registration he should be notified if the registration was successfully or not.

If I would create a packet I have packet composers for each packet type which will be create a packet for me.

So now to my problem. I would implement design patterns as many as possible but which?

For the packet parser I think I'll choose a factory which will give me the right parser for the actually packet type.

For the parsing it self I've thought about the command pattern which will give me optionally a call back for creating a response packet.

What do you think about this. Is my architecture crap? Which design pattern can I choose?

Answer 1

About the part with the

The Client send a packet to the server.

you can use Command design pattern, as you suggested for

a call back for creating a response packet.

but this is not the only thing you can use it. Actually the entire communication in your case can gain profit from the concept. Since common use is to encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support various operations. You can consider also the Chain of responsibility regarding your way of passing a request between a chain of objects. It'll help you to avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Good solution can also be the Observer design pattern. It will provide a way of notifying change to a number of classes for

if the client sends a packet for registration he should be notified if the registration was successfully or not.

and define a dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

I think that Decorator design pattern can be used for

If I would create a packet I have packet composers for each packet type which will be create a packet for me.

since it can add responsibilities to objects dynamically and provide a flexible alternative to subclassing for extending functionality.