Question

Consider a simple application level protocol built on top of udp that allows a client to retrieve a file from a remote server residing at a well known address. the client first sends a request with file name, and the server responds with a sequence of data packets containing different parts of the requested file. to ensure reliability and sequenced delivery, client and server use a stop - and - wait protocol. ignoring the obvious performance issue, do you see a problem with this protocol? think carefully about the possibility of processes crashing.

Answer 1

This Wikipedia article has some useful information. It's good for a reference source. Hope it helps! https://en.wikipedia.org/wiki/Stop-and-wait_ARQ

Answer 2

Answer:

Explanation:

Let consider a simple application-level protocol is build on the top of the UDP that allows a client to retrieve a file from a remote server exist in a well-known address. Here, UDP is User Datagram Protocol.

• The client first sends with a file name and the server responds with a sequence of data packets that contain the requested file.

•To ensure reliability and sequenced delivery,here the client and server are using the stop-and-wait protocol.

Problems occur with this protocol:-

The given statement makes the possibility for a client system to get the wrong file.

Let us assume that there are two clients A and B available, and the client A sends a request for a file

"F1" and then it gets crashed.

The client B sends same protocol to request some other file "F2";

In this case, the client B is running on the same machine of where the client A is running and then both files F1 and F2 are using the same IP addresses.

The client B binds its User Datagram Protocol socket to the same port of the client A was using previously.

In case the client B's request is lost when the server's reply for the client A arrive.

And also, client B receives it and assumes that it is a reply for its own request.

Hence, the client system gets the wrong file, when using this approach.