Protocol design for an application

0
votes

I am writing an client server application. In this I will have to transfer packets of size 1024 bytes from the client to server. If the packet size is more it must divided into two packets. The server has to understand if the received packet is a new packet or continuation of the old packet. Then it should contain version number of the protocol. This protocol can be used by multiple application so the packet should also contain the application identifier to determine which application. The packet should also contain the crc info to check the error in the packet. Can any one suggest me a design for the above protocol to communicate between client and server. Can any one suggest me some tutorials which would explain how data will be encrypted and sent from the client and then received and decoded in server.

2
client-serverprotocols
Is this homework? You can use already-implemented (and well-made) protocols, as you won't be reinventing the wheel. – Blender
Are you building this from scratch as an excercise/class project? If not, then you should use an off the shelf protocol like TCP/IP. – Sky Kelsey
The client has huge amount of messages to be sent to server. A single message can be greater than 1024 bytes which will be receiving at the server. So if the client m/c is fast, the previous message size is greater than 1024 bytes, the next message is getting intermixed with the previous message. So what i did is after each message i gave a delay in client so that server has time to receive all the bytes of current message. This is not the correct way so i wanted to design some standard way to do this. i wanted a frame based protocol where each frame size is less than equal to 1024 in length. – Shrikanth Kalluraya

2 Answers

0
votes

A protocol is something which is exchanged on mutual understanding. The details of the protocol defines how reliable and mission critical your application is.

The way of implementing a simple protocol is simply embed the frame size in the beginning of the packet. Also the data can be async received as chunk of files. It's simple logic to seperate them and add to the processing queue. If you've a fixed size, rather sharing the size, simply read each 1024 frames and consider it as your frames. A simple counter will help for this right?

0
votes

Apart from the basic info you would need to introduce some sort of sequence numbering scheme indicating the continuation number (0 for the first packet) so that the server can understand the difference between a new stream of packets and data from the previous stream and also reorder them if there is out of order delivery.

Now you don't have to do all this if you are designing a real world application since you would just pick TCP/IP for a reliable transaction and if you check the details of that it handles all the cases you are talking about. But incase you do have to design a smaller protocol what I recommend would be create a small state diagram of your protocol to check whether all paths lead to some final states (a protocol state machine), it is easy to miss some cases otherwise