• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 379
  • Last Modified:

packets over the network

When sending data in a  form of packets over the network. Does the sequence matters during the transfer?
3 Solutions
You will have to be a lot more specific about what you mean by 'network'. Is it Ethernet, IP, HTTP all of the above etc. Probably better if you explain what you are trying to do. A more generic answer:

Nearly all networking protcocols allow for the concept that packets sent will not necessarily arrive at the destination in the order that they were sent. Each packet contains sequence information that tells the remote end the order of the packet in the overall network conversation. E.g. packet 1 of 20, packet 5 of 20, packet 2 of 20 etc. Knowing this teh remote end can re-assemble in the correct order.

Packet re-assembly occurs at different networking levels depending on what you are sending. If you send a web page over Ethernet the Ethernet (physical) layer doesn't give two hoots about the order of delivery, nor does it understand the contents of the packets it is sending, so somewhere higher up the network levels something had better care about re-assembly in the correct order or else you will get rubbish.

Think of it like a man at a depot checking boxes off a lorry. He has a list of what he expects, and can tick them off as they are unloaded, until he has the full delivery. The order the come off the lorry is not important, just so long as it all arrives safely, and matches what he expects, so that he can deliver it to its final destination. The final destination may care about the order of the boxes (e.g. if they were to build a car) or may not.
As others have mentioned it all depends on what protocals are being used at what layers.  If TCP (probably one of the most used protocals) is being used then the order does not matter, it will be reassembled into the correct order, and any packets that don't make it through will be retransmitted.  On the other had when using UDP (another very popular protocal) any packets arriving out of order are simply dropped, and any packets that don't make it simply don't make it.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

mhhoAuthor Commented:
What if a packet hasn't arrived to its destination? When do you know if you need to retransmit or not ...
At the application level you should never need to deal with a retransmission, it should all be handled at the transport (TCP) layer.  If you are trying to develop your own transport layer for some reason the way this is normally handled is that when the receiving device gets a packet is sends an acknowledgement to the sending device that the packet was successfully received.  If the sending device hasn't gotten this acknowledgement after a certain amount of time then it retransmits that packet.  In a "guaranteed delivery" environment such as TCP (as opposed to an environment where delivery is not guaranteed like UDP) the sending device must keep track of what was in each packet until it receives acknowledgement that the packet was received.
It depends on the type of packets. For example voice packets really need sequence and this is what Qos is for. Most of the data packets doesn't need sequence because during the encapsulation process all devices are capable to ask for retransmission. The worst thing that can happen to you is to have delays because of the often retransmissions. It would be much better if you send as details about the applications you are using , the type of packets and what makes you thing that there is a problem regarding the sequence of the packets.It is not up to you to ask for retransmition. At the lower layers network devices and protocols are respnsible for error correction. Usually the applications have error correction too
Jut to clarify, QoS doesn't do anything to make sure that the packets are in sequence.  Essentially it just tells the networking gear which packets need to go "right now" and which packets can wait until there is available bandwidth.  If there is a voice conversation and a file transfer traveling over the same wire in order for there to be a clear conversation without gaps and choppy audio then it is important that the packets get there without any undue delay.  On the other hand the file transfer can reassemble the packets as they get there, so it is ok if some of the packets get delayed for a few seconds or have to be retransmitted because what you really care about is the finished product of the file, not the consistent stream of audio packets.

Most voice protcals actually drop packets that arrive out of sequence and don't bother with having missing packets retransmitted, but the audio codecs can put these partial streams back together again and kind of smooth over any gaps.  Live audio and video streaming from the internet work in a similar way.

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now