Re: UDP vs TCP

From: kelly (kelly_at_discussions.microsoft.com)
Date: 07/23/04 

Date: Fri, 23 Jul 2004 11:02:01 -0700

Thanks a lot for your detailed info.

I understand that UDP doesn't guarantee proper delivery of the message, that's why we have to add the CRC to the message to check if the message received is correct. Here's what I don't understand:

For example, I have two messages:
"3XYZ5"
"4ABCD9"
in which:
"3" is the length of the first message content, "XYZ" is the first message content, "5" is the CRC of the first message.
"4" is the length of the second message content, "ABCD" is the second message content, "9" is the CRC of the second message.

If I receive the two messages (concatenated) in one single receive event, and if the first message was screwed up, I might receive something like:

"3XZ54ABCD9"

which is incorrect ("Y" is missing in the first message). When I parse this received message, I would interpret:

"3XZ54" as the first message (because length is "3")
"ABCD9....." as the second message (because length is "A")

The CRC of the first message indicates that it's delivered improperly. Same for the second one. HOWEVER, the fact is, only the first message was screwed up, the second message was actually delivered properly.

Is the above case possible? If EACH receive event only receives ONE message, then the above scenario wouldn't exist. The first mesage would have been discarded after CRC check, and the second message would have been kept. If there is a chance that the messages are concatenated (or broken up), then the screwed up message might impact the OK messages.

Could anybody clarify this? THanks so much!

"Jim Carlock" wrote:

> Networking typically won't allow a packet over a certain size to
> be sent. TCP for instance will break up a large packet into smaller
> packets. This is different for different protocols.
>
> TCP establishes a connection and manages flow control and
> provides some guarantees. UDP on the other hand, is generally a
> little quicker, sends the information out in a "best effort" attempt, and
> I would describe it as throwing a paper airplane off the side of a cliff
> and hoping your friend is at the bottom to catch it. :-) Of course,
> YOU could look down and maybe double-check that he or
> she is there, but it is up to YOU to do this checking. It is up to YOU
> to guarantee the airplane lands in your friends hands. :-) And it is up
> to you to make sure that if the airplane has enough weight in it to
> make sure the wind doesn't carry it away. :-)
>
> With UDP, it is up to YOU to make the guarantees that the
> message gets delivered and then there are no guarantees that it
> is delivered properly. It is up to YOU to encode CRC or whatnot
> into the packets and then the receiving app would have to read
> and interpret the message received, and YOU would have to
> put the encoding in to ask for the sender to send the message
> again. YOU (your program) must do some extra packaging and
> must maintain the size of the packets in a packet-sized fashion.
>
> In using the example above, TCP would be like dropping the
> message into a bucket that hangs on a wire that goes down
> to a defined drop location. The wire being in place guarantees
> that it gets sent to the predefined location, much like a TCP
> connection guarantees that receiver is there.
>
> Generally if you send a packet over a certain size, let's say
> bigger than 4k in size, Ethernet may silently break up the
> message into corresponding Ethernet packets. There is a
> maximum size to Ethernet packets. There is a maximum
> size to TCP/IP packets.
>
> There are seven layers to networking...
> Application Layer -> your program (ftp, telnet, snmp, dns)
> Presentation Layer -> TCP
> Session Layer -> TCP
> Transport Layer -> TCP/UDP
> Network Layer -> ethernet (arp, ip, icmp, igmp)
> Data-Link Layer -> ethernet
> Physical Layer -> the wires and hardware
>
> It is interesting to note that Microsoft makes up their own layers:
> 1) Application (topmost)
> 2) Transport (TCP/UDP)
> 3) Internet (IP, ARP)
> 4) Network
>
> I had to pull out my NT 4 networking book to look some of those
> things up. The NT 4 book doesn't deal with anything below the
> Network Layer and the protocols listed (arp, ip, icmp, igmp) probably
> co-exist on the Data-Link layer as well. I couldn't find my Cisco
> book.
>
> TCP uses a 3-way handshake to make to make a connection.
> UDP just sends information out to a destination. TCP is used to
> transfer larger amounts of data, UDP is used for rapid transport
> of smaller amounts of data. TCP breaks up the packets for you.
> With UDP, I believe it is 100% completely up to you to manage
> the size of the packets. Someone else will have comment on this
> though so keep your mind open in this regard.
>
> Some protocols that send information over UDP include:
> NETSTAT over port 15
> DOMAIN (DNS) over port 53
> TFTP (Trivial File Transfer Protocol) over port 69
> NETBIOS-NS (NetBIOS Name Service) over port 137
> NETBIOS-DGM (NetBIOS Datagram Service) over port 138
> SNMP (Simple Network Management Protocol) over port 161
>
> Some TCP protocols:
> FTP (File Transfer Protocol) over ports 20, 21
> Telnet over port 23
> Domain Name Service (DNS) over port 53
> NetBIOS Session Service over port 139
> WebServer (HTTP) over port 80
>
> Hope that helps.
>
> --
> Jim Carlock
> http://www.911forthetruth.com/
> Post replies to the newsgroup.
>
>
> "kelly" wrote:
> I am aware that if the network connection is established via
> TCP, there is a chance that the messages received are chopped
> up or concatenated. I have seen that happened.
>
> What about UDP? Does it guarantee that each time the
> messages you receive are not chopped up or concatenated
> (assuming that the transmission is ok, no lost packet)? That is,
> each time the receive event is triggered, exactly one (not half,
> not two, but exactly one) message is received?
>
> Thanks!
>
>
>

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Old SUN NFS performance papers.
    ... > also just generally a good idea, since UDP frags act as a fixed ... > you may be copying all your packets over again ), ... With TCP, you ... >> FreeBSD NFS servers, and therefore always looking for tweaks and nobs ...
    (freebsd-performance)
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: dsnetwork
    ... It is true that TCP has no respect for the timeliness of delivery, ... UDP has neither--it's just a best effort delivery. ...
    (microsoft.public.win32.programmer.directx.video)