User Datagram Protocol (UDP) is essentially a scaled-down economy model of TCP, which is why UDP is sometimes referred to as a thin protocol. UDP does not require much bandwidth on a network.
UDP does not offer all the bells and whistles of TCP but it does a fabulous job of transporting information that does not require reliable delivery, using far less network resources.
Clearly, there are times when it is wise for developers to opt for UDP rather than TCP, one of them being when reliability is already taken care of at the Process/Application layer. Network File System (NFS) handles its own reliability issues, making the case for TCP both impractical and redundant. But ultimately it's up to the application developer to opt for using UDP or TCP, not the user who wants to transfer data faster !!
UDP does not sequence the segments and does not care about the order in which the segments arrive at the destination. UDP just sends the segments off and forgets about them. It does not follow through, check up on them, or even allow for an acknowledgement of safe arrival --- complete abandonment. Because of this, it's referred to as an unreliable protocol. This does not mean UDP is ineffective, only that it doesn't deal with reliability issues at all.
Furthermore, UDP doesn't create a virtual circuit, nor does it contact the destination before delivering information to it. Because of this, it's also considered a connectionless protocol. Since UDP assumes that the application will use its own reliability method, it doesn't use any itself. This presents an application developer with a choice when running the Internet Protocol stack: TCP for reliability or UDP for faster transfers.
It's important to know how this process works because if the segments arrive out of order, which is commonplace in IP networks, they will simply be passed up to the next layer in whatever order they were received. This can result in some seriously garbled data !! On the other hand, TCP sequences the segments so they get put back together in exactly the right order, which is something UDP just cannot do.
UDP does not offer all the bells and whistles of TCP but it does a fabulous job of transporting information that does not require reliable delivery, using far less network resources.
Clearly, there are times when it is wise for developers to opt for UDP rather than TCP, one of them being when reliability is already taken care of at the Process/Application layer. Network File System (NFS) handles its own reliability issues, making the case for TCP both impractical and redundant. But ultimately it's up to the application developer to opt for using UDP or TCP, not the user who wants to transfer data faster !!
UDP does not sequence the segments and does not care about the order in which the segments arrive at the destination. UDP just sends the segments off and forgets about them. It does not follow through, check up on them, or even allow for an acknowledgement of safe arrival --- complete abandonment. Because of this, it's referred to as an unreliable protocol. This does not mean UDP is ineffective, only that it doesn't deal with reliability issues at all.
Furthermore, UDP doesn't create a virtual circuit, nor does it contact the destination before delivering information to it. Because of this, it's also considered a connectionless protocol. Since UDP assumes that the application will use its own reliability method, it doesn't use any itself. This presents an application developer with a choice when running the Internet Protocol stack: TCP for reliability or UDP for faster transfers.
It's important to know how this process works because if the segments arrive out of order, which is commonplace in IP networks, they will simply be passed up to the next layer in whatever order they were received. This can result in some seriously garbled data !! On the other hand, TCP sequences the segments so they get put back together in exactly the right order, which is something UDP just cannot do.
No comments:
Post a Comment