Susmita/Rajib wrote: > >> So what is essentially required is theoretically a list that keeps > >> record of time, order and port, of each of the packets requests made, > >> and rearrange the packets received from all ports according to that > >> list, to provide the system with a complete file. > > > > What happens is that the kernel keeps track of the sequence > > number embedded in each TCP packet, holds on to future packets, > > ignores repeated packets, and issues acknowledgements for each > > received packet. The sending side must detect a missing > > acknowledgement and resend the packet. > > Wow! Based upon your inputs, it is surprising for me to find that > specific drawbacks/benefits indeed exist in either of TCP/IP or UDP; > what exists in the former is absent in the latter, and vice versa.
This is because TCP is designed to be a reliable long-term transport over an unreliable medium, and UDP is designed to be an unreliable, short-term transport over the same unreliable medium. A web page is generally brought to you by TCP; a DNS request is usually handled with UDP. > It appears that we should indeed have a far tighter and elaborate, but > still compact, protocol and database/list for packet referencing, > i.e., port-number/packet-number/time/order, and have better chances of > improving upon data transfers and reducing packet losses. Sadly, this is not the case. A TCP session is identified by four parts: sender IP sender port receiver IP receiver port and sequence numbers are maintained for each session. There is no confusion involved. There are two primary sources of packet loss. The first is ordinary signal decay. This does not happen much over local wired or optic connections, but happens relatively often over long wire connections, and happens appallingly frequently over any radio connection, such as WiFi, GSM, or LTE. There's not much we can do about this other than note that it exists and plan for it. The second source of packet loss is an overloaded forwarding device - a switch, router, or media converter with mismatched speeds - and here a useful analogy may be employed: The Internet is a series of railroad tracks. For the purposes of this analogy we will pretend that they are flawless transports: whatever you load in at one end will be received at the other end. Each packet you put in is whisked along the track to the next station, where the inspector reads the destination address and determines what to do with it: put it on the best available path, put it on a siding waiting for the best available path to be ready, or destroy it. If the packet goes to the best available path, it is now the next inspector's problem. If the packet goes to a siding, it may be put on the right path soon, but if the siding fills up, it will be destroyed. The destruction of the packet is the second source of packet loss. > Also, with a > tight referencing, the problems in combining multiple ISPs bandwidth > to improve upon overall bandwidth shall disappear. I'm afraid not. The packets will take different paths to get to you, causing retransmissions and losses that will bring the system to a much lower bandwidth than a single link. As I said, you can use multiple ISPs to gain bandwidth for multiple uses, but not for a single TCP session. > An invitation could well be: Inventors and program writers, the arena > is yours to take over and innovate for a better protocol than TCP/IP > or UDP, having the best of either, but the worst of none. What we have actually works very well, and is frequently updated; your specific use case is not supported. Sorry. -dsr-
