Nt1310 Unit 7 Gdp

There are a few problems I would anticipate with using this combination of protocols. The first is if there is some sort of failure with the delivery of the sequence of data packets. As UDP is connectionless there isn’t a reliable order that the packets will arrive, one would assume this is why they are using stop and wait, to try and compensate for this issue. As a result, you may get some packets timing out and being resent by the server causing duplicate packets to be sent, all while awaiting ACK arrival even though there may not have actually been any failure. Then there are extra packets on the network trying to arrive while this is occurring. These duplicate packets, or duplicate ACKs, need to be handled in order to keep the file transfer from becoming exponentially larger each time there was some sort of issue.
As UDP doesn’t implement any error control the file could potentially be corrupted when it arrives and be accepted, or just discarded. Using stop and wait, if the packet is discarded, it could be resubmitted by the server when it times out causing an issue similar to the one noted above. However, as the data isn’t sequenced, if it is accepted, this could potentially cause unintended results in the file being read correctly. This sequencing issue could also be an issue if there are multiple “sets” of packets arriving at intermittent intervals. Some sort of protocol would need to be used to either correctly sequence packets as they leave and arrive and handle any errors correctly.
It would seem like the ideal thing to do for a file transfer would be to instead use TCP to remove several of the issues that you’re trying to compensate for by using the stop and wait with