Sisteme cu Control Distribuit

If you are designing a client-server system you may also have to design a communication

protocol between the client and the server. Of course, sometimes this protocol is already

have been decided for you, e.g. HTTP, XML-RPC (XML over HTTP), or SOAP (also

XML over HTTP). But once in a while the protocol decision is open, so let's look at a

few issued you may want to think about when designing your client - server protocol:

1. Client - Server Roundtrips

2. Demarcating the end of requests and responses

3. Penetrating Firewalls

Client - Server Roundtrips

When a client and server communicates to perform some operation they exchange

information. For instance, the client will ask for a service to be performed, and the server

will attempt to perform it, and send back a response telling the client of the result. Such

an exchange of information between the client and server is called a roundtrip.

When a computer (client or server) sends data to another computer over the internet it

takes some time from the time the data is sent, to the data is received at the other end.

This is the time it takes the data to travel over the internet. This time is called latency.

The more roundtrips you have in your protocol, the slower the protocol becomes,

especially if latency is high. The HTTP protocol consists of only a single request and a

single response to perform its service. A single roundtrip in other words. The SMTP

protocol on the other hand, consists of several roundtrips between the client and the

server before an email is sent.

The only reason to break your protocol up into multiple roundtrips is, if you have a large

amount of data to send from the client to the server. You have two options in this case:

1. Send the header information in a separate roundtrip.

2. Break the message body up into smaller chunks.

Sending the header in a separate roundtrip (the first) can be smart if the server can do

some initial pre-validation of e.g. header information. If that header information is

invalid, sending the large body of data would have been a waste anyways.

If the network connection fails while you are transfering a large amount of data, you may

have to resend all that data from scratch. By breaking the data up into smaller chunks you

only have to resend the chunks from the chunk where the network connection failed and

onwards. The successfully transfered chunks do not have be resent