You are not logged in.
Downloading the linux kernel via tftp what happens if the data packet becomes corrupted.
As i know tftp uses UDP which does not do things like handshaking, error correction and leaves it to higher protocols assuming there are any in use. UDP uses a simple transmission model without implicit handshaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level.
Lacking reliability, UDP applications must generally be willing to accept some loss, errors or duplication. Some applications such as TFTP may add rudimentary reliability mechanisms into the application layer as needed. Most often, UDP applications do not employ reliability mechanisms and may even be hindered by them. In TFTP loss of packets is not usually a fatal problem. If an application requires a high degree of reliability, a protocol such as the Transmission Control Protocol or erasure codes may be used instead.
I am still bit confused how it handle the corrupted packet, resend the packet request in TFTP and carry on with rest of file or wait for packet to received.
TFTP - lost packets?
Timeout and retransmit
Block number in data packets
is that ?
any advised would be helpful. if you cant that's ok thanks for reading.
Last edited by newbee1985 (2013-01-31 06:29 PM)
It basically adds its own minimalist TCP-like sequence numbers and ACKs on top of UDP... So, it can detect a missing packet, and request a resend (by re-ACK'ing the last packet it did receive)... Here's Wikipedia's description:
Each data packet contains one block of data, and must be acknowledged by an acknowledgment packet before the next packet can be sent. A data packet of less than 512 bytes signals termination of a transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit his last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet. The sender has to keep just one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been received.
As for received, but corrupted packets, that's presumably just left up to the network stack to handle via the normal header checksums... If a packet fails the checksum check, it is just discarded, so it'll be like it never arrived...