I know what TCP implements in-order data transmission,but does it actually validates the data that arrived from A to B is the actual data that was sent from A ?
If it does , how exactly does it happen?
does it actually validates the data that arrived from A to B is the actual data that was sent from A ?
Frankly, no.
It tries to make sure receiver gets the same number of bytes sender sent during session (using ack and syn numbers). It also makes sure every segment has correct checksum, which, I think doesn't guarantee much. If your host has faulty memory, it could be that you send one stream of bytes, then, a few buffers later some another stream of bytes (due to bit-flapping) is used to calculate checksum. The checksum will be correct, but the sent and received messages will differ. If you want reliability, always implement your own checksumming/hashing/signing of application-level messages.
Some relevant reading explaining a cost of a single bit error: http://status.aws.amazon.com/s3-20080720.html.
I believe this excert from RFC 793 answers your question:
The TCP must recover from data that is damaged, lost, duplicated, or
delivered out of order by the internet communication system. This
is achieved by assigning a sequence number to each octet
transmitted, and requiring a positive acknowledgment (ACK) from the
receiving TCP. If the ACK is not received within a timeout
interval, the data is retransmitted. At the receiver, the sequence
numbers are used to correctly order segments that may be received
out of order and to eliminate duplicates. Damage is handled by
adding a checksum to each segment transmitted, checking it at the
receiver, and discarding damaged segments.
Related
I should find a combination of the lenght of a packet, bandwidth and the link lenght and then find out if there is a combination for which transmitting time of a packet finishes before the first bit of the packet has reached the receiver. Is this even possible?
TCP or UDP?
TCP will require to receive a response from the destination before it actually starts sending the packet thus it won't be possible here.
UDP has no concept of knowing whether or not the packet got received, which means that as soon as the packet has left the sender there is no further communication between the two.
Your question is worded ambiguously though: how can you talk about 'transmission time' (which implies the time between sending and receiving) while comparing that to the 'receiving time' (which is already part of the transmission time).?
I have been studying a book on Computer Networking (this is not a homework question)
One of the questions compares ACK and NAK based data transfer protocols, with the emphasis being that for a NAK based protocol, packet loss can for packet x can be detected by the received when the (x + 1)th packet is received.
However, my issue is that what happens if the NAK sent by the receiver is lost before it gets to the sender? The sender will not be aware of errors and will not retransmit. Furthermore, what if the packet is the last one in the sequence? (there is no subsequent packet to test with)
I do not see how a NAK-only protocol can be reliable (delivers each packet in the correct order)
I suspect that the theoretical context described in the book assumes an infinite stream of packets and ignores conditions like the channel becoming completely disabled. In practice, there are other constructs defined as part of the ACK/NAK protocol or left up to higher or lower layer layer protocols to deal with. For instance, a physical layer would provide indications like "the channel is broken", and perhaps a protocol above sends/receives "end-of-stream" packets, with a timer detect the case where the NAK for the last packet is lost. These are just hypothetical examples, but are the types of things real-life protocols do.
I do not see how a NAK-only protocol can be reliable (delivers each
packet in the correct order)
I'm sure the book is implying there is some sort of mechanism for identifying packets in order. Otherwise, there would be no way for the receiver to indicate which packet it is NAK'ing, i.e., most protocols use a sequence number in each packet/ack/nak.
A NAK-only protocol can achieve reliability by having the receiver start a timer when sending a NAK and retransmit the NAK when the timer times out before the missing packet was retransmitted.
How do TCP knows which is the last packet of a large file (that was segmented by tcp) in the scenario that the connection is kept-established. (like ftp or sending mp3 on yahoo messenger)
I mean how does it know which packet carries data of one.mp3 and which packet carries data of another.mp3 ??
Anyone ?
Thank you
There are at least 2 possible approaches.
Declare upfront how much data you're going to send. Something like a packet that declares Sending a message that's 4008 bytes long
The second approach is to use a terminating sequence (nastier to process)
So the receiver:
Tries to read the declared amount or
Scans for the terminating sequence
TCP is a stream protocol and fragmentation should be transparent to a TCP application. It operates on streams of data, never packets. A stream is assembled to its intended order using the sequence numbers. The sequence of bytes send by application is encapsulated in tcp segments. The stream is recreated on the receiver side before data is delivered to the application.
The IP protocol can do fragmentation.
Each TCP segment goes to the IP layer and may be fragmented there. Segment is reassembled by collecting all of the packets and offset field from the header is used to put it in the right place.
Can anybody explain how does the receiver know if two nonconsecutive TCP segments belong to the same or different packets ? And how does it know if the next segment is the last segments in the packet ?
The receiver doesn't assemble TCP segments into packets, it assembles them into streams. The receiver knows the location, in the stream, of its received segment by its sequence number.
Is it possible that you are expecting the count result of the receiving application's read() system call to conform to the sending application's write() system call? If so, you will be disappointed. TCP streams are byte-wise, not packet-wise, streams. They neither preserve nor honor the boundaries of the sending system calls.
TCP does not deal with fragmentation. That's an IP problem. Packets arrive at the TCP level only when complete. IP uses special fields in the header that indicates whether the packet is fragmented or not, and, if yes, whether the fragment received is the last one or not.
You may take a look :
Transmission Control Protocol
Internet Protocol
I know the protocol doesn't support this but is it common for clients that require some level of reliability to build into their application a method for requesting retransmission of a packet if found to be corrupt?
It is common for clients to implement reliability on top of UDP if they need reliability (or sometimes just some reliability) but not any of the other things that TCP offers, for example strict in-order delivery, and if they want, at the same time, low latency (or multicast, where it works).
In general, you will only want to use reliable UDP if there are urgent reasons (very low latency and high speed needed, e.g. for a twitch game). In every "normal" case, simply using TCP will serve you equally well or better.
Also note that it is easy to implement your own stack on top of UDP that performs worse than TCP.
See enet for an example of a library that implements reliability (and some other features) on top of UDP (Raknet or HawkNL would be other examples).
You might want to look at the answers to this question: What do you use when you need reliable UDP?
Of course. You can build a reliable protocol (like TCP) on top of UDP.
Example
Imagine you are building a fileserver:
* read the file using blocks of 1024 bytes
* construct an UDP packet with payload: 4 bytes for the "position" in the file, 4 bytes for the "length" of the contents of the packet.
The receiver now receives UDP packets. If he gets following packets:
* 0-1024: DATA
* 1024-2048: DATA
* 3072-4096: DATA
it realises a packet got missing, and asks the sending application to resend the part between 2048 and 3072.
This is a very basic example to explain your application code needs to deal with the packet construction and payload interpretation. Don't use it, it does not take edge cases (last packet, checksums for corrupted packets, ...) into account.
Short answer: No.
Long answer: UDP doesn't care for packet loss. If an UDP packet arrives and has a bad checksum, it is simply dropped. Neither the sender of the packet is informed about this, nor the recipient is informed. It is only dropped, that's all that happens. Also UDP packets are not numbered, so if you send four packets and only three arrive at the recipient, the recipient cannot know that there used to be four and one is missing. Last but not least, packets are not acknowledged, so the sender will never know if a packet it was sending out ever made it to the recipient or not.
Contrary to this, TCP breaks data into segments, each segment is numbered, so the recipient can know if a segment is missing. Also all segments must be acknowledged to the sender. If the sender receives no acknowledgment for a segment after a certain period of time, it will assume the segment was lost and send it again.
Of course, you can add an own frame header on top of every data fragment you sent over UDP, that way your application code can number the sent fragments and you can implement an acknowledgement-resent strategy in your code but the question is: Will this really be better than what TCP is already offering for free? Even if it would be equally good, save yourself the time and just use TCP. A lot of people already thought they can do better than TCP and usually they realize in the end, actually they cannot. TCP has its weaknesses but in general it is pretty good at what it does.