Re: UDP vs TCP

From: Jim Carlock (anonymous_at_127.0.0.1)
Date: 07/23/04 

Date: Fri, 23 Jul 2004 12:49:42 -0400

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: Linux als Router
    ... # Enter all trusted network interfaces here. ... # which should be available to the internet and set FW_ROUTE to yes. ... space separated list of ports, ... # Packets to silently reject without log message. ...
    (de.comp.os.unix.linux.misc)
  • Re: Error 720 connecting to server via VPN
    ... By default the router's firewall is configured to drop ICMP packets ... Select WAN Setup> Advanced> Respond to Ping on Internet Port. ... server and the Internet allow GRE packets. ... routers on the user's network are also configured to allow GRE packets. ...
    (microsoft.public.windows.server.sbs)
  • RE: Mapping Class A network ( any easy trick?)
    ... and wondering how I can map the network ... packets per second rate to ask for. ... This will read the payloads.conf file which may have multiple payloads ... per port. ...
    (Pen-Test)
  • Re: Socket send blocking problem
    ... The network becomes congested, ... sending thus slows down dramatically and *thus* the buffer fills. ... TCP will packetise the data in buffer as suits the ... You have no direct control over what packets TCP will send ...
    (microsoft.public.win32.programmer.networks)
  • Re: Update: UDP 770 Potential Worm
    ... > I still believe that the packets may be the result ... with the goal of knocking machines ... the network immediately after the 'attack', ... destined to port if you haven't sniffed it somehow? ...
    (Incidents)