This preview shows page 1. Sign up to view the full content.
Unformatted text preview: bsequent reads. The application is not notified that multiple reads
are being fulfilled from a single UDP datagram.
The TLI API does not discard the data. Instead a flag is returned indicating that more data is
available, and subsequent reads by the application return the rest of the datagram.
When we discuss TCP we'll see that it provides a continuous stream of bytes to the application,
without any message boundaries. TCP passes the data to the application in whatever size reads
the application asks for-there is never any data loss across this interface. 11.11 ICMP Source Quench Error
Using UDP we are also able to generate the ICMP "source quench" error. This is an error that
may be generated by a system (router or host) when it receives datagrams at a rate that is too
fast to be processed. Note the qualifier "may." A system is not required to send a source quench,
even if it runs out of buffers and throws datagrams away.
Figure 11.18 shows the format of the ICMP source quench error. We have a perfect scenario
with our test network for generating this error. We can send datagrams from bsdi to the router
sun across the Ethernet that must be routed across the dialup SLIP link. Since the SLIP link is
about 1000 times slower than the Ethernet, we should easily be able to overrun its buffer space.
The following command sends 100 1024-byte datagrams from the host bsdi through the router
sun to solaris. We send the datagrams to the standard discard service, where they'll be ignored:
bsdi % sock -u -i -w1024 -n100 solaris discard Figure 11.18 ICMP source quench error.
Figure 11.19 shows the tcpdump output corresponding to this command.
1 0.0 bsdi .1403 > solaris.discard: udp 1024
26 lines that we don't show file:///D|/Documents%20and%20Settings/bigini/Doc...omenet2run/tcpip/tcp-ip-illustrated/udp_user.htm (20 of 29) [12/09/2001 14.46.58] Chapter 11. UDP: User Datagram Protocol 27
View Full Document
- Spring '12