UDP is the faster protocol as it doesn't wait for 
acknowledgement so it is not at all having reliability as 
compared to TCP.

tcp

udp is faster..mainly used for video and audio streaming ( 
Rstp)

tcp

UDP is faster then TCP in data transmission.

Compare 2 TCP , UDP is a faster & it is used for download 
uplooud vedio's ...... un reliable

UDP is faster than TCP because it is connectionless and need
not wait for connection setup  and ACK.

TCP is faster than UDP.

UDP is faster protocol since it has no acknowledgement 
signal.....

UDP is faster than TCP bcoz it is connection less protocol 
and it also does not wait for acknowledgement . Therefore 
it is specially used for video signals transmission .

how many protocals are there?give me(20)important protocals?
plz it is important to me plz plz.....

UDP is definitely faster than TCP. Thats why it is mainly 
used for video and streaming audio. Speed!

The reason UDP is fater than TCP is because UDP does not do 
error correction and flow control.

I only know about UDP is unreliable and connectionless 
protocol.And TCP/IP protocol is connection oriented and 
reliable.i want some more advantages and disadvantages and 
UDP where its used.

UDP: It doesn't wait for acknowledgement as like TCP/IP so 
it is unreliable protocol.

UDP is usually used in where communication needs to be fast 
like in DNS and DHCP.

The first thing is UDP is connection less where as TCP is 
connection  oriented.The broadcasting and multicasting 
software is available in the UDP only.Why because it is 
connection less hence we can broadcast the packets very 
easily,no need to wait for connection like in tcp,which 
takes more delay.

to implement the udp service we must creat socket by socket 
system call which takes argument as SOCK_DGRAM which is 
used for to pass the data in the form of datagrams.

by using Icmp protocol.

1.In IP Header Protocol field is available,it tells which 
protocol it is using as a transportlayer,if this field is 
having 6(in decimal)it indicates TCP,17(in decimal)it 
indicates UDP.

You have to design your protocol to expect a confirmation
back from
  the destination when a message is received.  Of course is the
  confirmation is sent by UDP, then it too is unreliable and
may not
  make it back to the sender.  If the sender does not get
confirmation
  back by a certain time, it will have to re-transmit the
message, maybe
  more than once.  Now the receiver has a problem because it
may have
  already received the message, so some way of dropping
duplicates is
  required.  Most protocols use a message numbering scheme
so that the
  receiver can tell that it has already processed this
message and
  return another confirmation.  Confirmations will also have to
  reference the message number so that the sender can tell
which message
  is being confirmed.  Confused?  That's why I stick with TCP.

You have to design your protocol to expect a confirmation 
back from   the destination when a message is received.  Of 
course is the  confirmation is sent by UDP, then it too is 
unreliable and may not  make it back to the sender.  If the 
sender does not get confirmation back by a certain time, it 
will have to re-transmit the message, may be   more than 
once.  Now the receiver has a problem because it may have  
already received the message, so some way of dropping 
duplicates is  required.  Most protocols use a message 
numbering scheme so that the  receiver can tell that it has 
already processed this message and  return another 
confirmation.  Confirmations will also have to  reference 
the message number so that the sender can tell which 
message  is being confirmed.  Confused?  That's why I stick 
with TCP.