Extras din laborator
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
Preview document
Conținut arhivă zip
- scd-L01-Network Protocol Design.pdf
- scd-L01-Networking Basics.pdf