Why would an application use UDP instead
of TCP? Also, explain how can TCP handle
urgent data?
Ans :
n situations where your really want to get a simple answer to
another server quickly, UDP works best. In general, you want the answer to be
in one response packet, and you are prepared to implement your own protocol for
reliability or resends. DNS is the perfect description of this use case. The
costs of connection setups are way to high (yet, DNS does support a TCP mode as
well).
Another case is when you are delivering data that can be lost
because newer data coming in will replace that previous data/state. Weather
data, video streaming, a stock quotation service (not used for actual trading),
or gaming data come to mind.
Another case is when you are managing a tremendous amount of
state and you want to avoid using TCP because the OS cannot handle that many
sessions. This is a rare case today. In fact, there are now user-land TCP
stacks that can be used so that the application writer may have finer grained
control over the resources needed for that TCP state. Prior to 2003, UDP was
really the only game in town.
One other case is for multicast traffic. UDP can be
multicasted to multiple hosts whereas TCP cannot do this at al
A computer may send UDP packets without first establishing a
connection to a recipient. The computer completes the appropriate fields in the
UDP header (PCI) and forwards the data together with the header for
transmission by the IP network layer.
Typically, use UDP in applications where speed is more critical than reliability. For example, it may be better to use UDP in an application sending data from a fast acquisition where it is acceptable to lose some data points. You can also use UDP to broadcast to any machine(s) listening to the server.
In general:
- TCP is for high-reliability data transmissions
- UDP is for low-overhead transmissions
- Connections
Two computers set up a connection to exchange data. The systems
synchronize with one another to manage packet flows and adapt to
congestion in the network.
- Full-duplex
operation
A TCP connection is a pair of virtual circuits (one in each direction).
Only the two end systems can use the connection.
- Error
checking A checksum technique is used to
verify that packets are not corrupted.
- Sequencing
Packets are numbered so that the destination can reorder packets and
determine if a packet is missing.
- Acknowledgements
Upon receipt of one or more packets, the receiver returns an
acknowledgement (called an "ACK") to the sender indicating that
it received the packets. If packets are not ACKed, the sender may
retransmit the packets (or terminate the connection if it thinks the
receiver has crashed).
- Flow
control
If the sender is overflowing the receiver by transmitting too quickly, the
receiver drops packets. Failed ACKs alert the sender to slow down or stop
sending.
- Packet
recovery services The receiver can request
retransmission of a packet. Also, if packet receipt is not ACKed, the
sender will resend the packets.
In LabVIEW 8.0 or later, refer to the Using LabVIEW with
TCP/IP and UDP document in the LabVIEW Help (linked below) for more
information. In LabVIEW 7.1 or earlier, refer to the Using LabVIEW with TCP/IP
and UDP Application Note by clicking Help»Search the LabVIEW Bookshelf in
LabVIEW for more information.
TCP is a connection-oriented protocol that provides the flow
controls and reliable data delivery services listed next. These services run in
the host computers at either end of a connection, not in the network itself.
Therefore, TCP is a protocol for managing end-to-end connections, as shown in
Figure T-2. Since end-to-end connections may exist across a series of
point-to-point connections, they are often called virtual circuits.
Reliable data delivery services are critical for applications
such as file transfers, database services, transaction processing, and other
mission-critical applications in which every packet must be
delivered-guaranteed. See "Reliable Data Delivery Services" for a
general overview of reliable services.
While TCP provides these reliable services, it depends on IP
to delivery packets. IP is often referred to as an unreliable or best
effort service. While it seems odd to build a network that is
unreliable, the original Internet architects wanted to remove as many services
from the network itself to support fast packet delivery rather than
reliability. Routers do not keep track of packets or do anything to ensure
delivery. They just forward packets.
The assumption was that end systems would be relatively smart
devices with memory and processors. The end devices could handle all the
reliability functions rather than the network. This was actually a radical
approach at the time, but the implications have been profound. It meant that
end systems would become the focus of application development for the Internet,
not the network.
In contrast, the telephone network implements an architecture
in which end devices (phones) are dumb and the network is supposedly
"smart." The only problem with this model is that you can't run
applications on your phone that take advantage of the network. In fact, you are
totally dependent on the phone company to deploy new applications (call waiting
and caller ID are examples). Compared to the Internet, the phone system is a
dinosaur. Consider that the user interface for the Web is a full-color
graphical browser, while the interface for the telephone network is a 12-key
pad!
While end-systems provide TCP's reliability functions, not
all applications need them. For example, there is no need to recover lost packets
in a live video stream. By the time they are recovered, the viewer has will
have already seen the barely visible glitch caused by the missing packet. These
applications just need speed. So UDP was created to provide an application
interface to the network for real-time applications that don't need TCP's extra
services. UDP provides a very simple port connection between applications and
IP.
No comments:
Post a Comment