Question

Q # 1: Is it is possible for an application on top UDP to have a reliable data transfer? explain?

Q # 2: Suppose you open a startup company “foo” and want to set up your company network. Your network has the following servers:

• DNS server: “dns.foo.com” with IP as “140.111.30.40”
• Web server: “foo.com” with two IP as “140.111.30.55” and “140.111.30.52”.
• The web server also has a name as “www.foo.com”.
• Email server: “galaxy.foo.com” with IP as “140.111.30.6”
• Your company’s email address is “[email protected]”.

a) What resource records (RRs) do you need to provide to the upper-level “.com” Registrar?

b) What RRs do you need to put in your company’s DNS server?

Q #3: What are the two layers the run exclusively at the network edges?

Q #4: What are the differences between GET and GET conditional Http Requests?

Q #5: Would the DNS protocol work if IP addresses are not hierarchical? Explain why?

Q # 6: in P2P, each peer only upload chunks to a limited number of peers? Why is the Bit torrent designed in such a way?

****************** Please give me all answers *************

Answer 1

1.The UDP does not have a specific protocol layer that validates about the completion of transfer. UDP as a protocol is not meant for reliability. It is designed to develop applications which need speed rather than reliability. But its possible to add reliability at the application layer. If any packets have not received the application can send message to lower UDP layer and to other end need to re-transmit the packet.

There is nothing to stop the process of transferring a file by UDP and also it provides  a sum check on the source machine and its also possible to compute a sum check on the destination machine. It helps in recursive repeating of the file transfer until the source and destination matches.
  A minimum of three transfers can be done to separate destination files and compare the results. If the three files are different, but the differences are in different places of the  files, we can try creating a new file based on the majority verdict. However UDP does not guarantee delivery ,the three files can be of different lengths which can make matching up the good segments of the files tricky and can even  still leave errors.
   This approach has other overheads like managing sequence number of each packet on both client and server side and so on.

If we have a suitable application for both  sending and receiving, then these could provide their own verification on to the UDP layer.

UDP works well for streaming webcam or other similar devices, where it's probably more desirable to keep the stream flowing rather than waiting for TCP to sort out any missing packets. The problem with using TCP for this sort of application is that the transport service normally has to wait several seconds, when a packet is lost it can initiate a retry in order to prevent excessive duplication of packets when the original packet arrives slightly late. If we stream a webcam on occasional frame jumps, we probably won’t notice and we would simply accept it. Missing bytes in a data file will be unacceptable.
So eventually it is ease to use TCP rather than UDP, if reliability carries more importance.