Go through this link:
http://www.iana.org/assignments/port-numbers



ankitjain.bvcoe@gmail.com wrote:
> Hi all ,
> I am new to this group .
> A basic question.I want to know what is a difference b/w TCP and UDP
> packet i.e how will u know that the data which u are receiving is
> travelling via a UDP/TCP packet without using any sniffer.
>
> ankit

In article <1149664377.664911.123520@g10g2000cwb.googlegroups. com>,
ankitjain.bvcoe@gmail.com wrote:

> Hi all ,
> I am new to this group .
> A basic question.I want to know what is a difference b/w TCP and UDP
> packet i.e how will u know that the data which u are receiving is
> travelling via a UDP/TCP packet without using any sniffer.

When an application opens a network socket, it has to specify whether
it's using TCP or UDP (or something else). So it won't get a TCP packet
if it's listening for UDP, and vice versa. So the problem you describe
doesn't exist unless you're using raw sockets. If that's the case, you
look at the protocol field in the IP header -- if it's 6 then it's TCP,
if it's 17 it's UDP.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

ankitjain.bvcoe@gmail.com wrote:
> Hi all ,
> I am new to this group .
> A basic question.I want to know what is a difference b/w TCP and UDP
> packet i.e how will u know that the data which u are receiving is
> travelling via a UDP/TCP packet without using any sniffer.
>
> ankit

The command: netstat -a
Shows you the current TCP connections (and its corresponding state) and
also UDP ports that your computer is listening to.
It is clear that, since UDP does not stablish a connection (since it is
not connection oriented) it is not possible to detect "open
connections" in an UDP transmission.

So mainly, TCP will send syncs to inform that a connection is required,
and given that TCP provides reliability, its packets will be larger due
to the information included in the headers. UDP packets are smaller
since its objective is efficiency, which can be achieved by reducing
the overhead of the information transported by TCP.

wrote in message
news:1149664377.664911.123520@g10g2000cwb.googlegr oups.com...
> Hi all ,
> I am new to this group .
> A basic question.I want to know what is a difference b/w TCP and UDP
> packet i.e how will u know that the data which u are receiving is
> travelling via a UDP/TCP packet without using any sniffer.
>
> ankit
>

As you know, TCP uses 3-way handshake and it's connection oriented; TCP
gives guarenteed delivery, flow control and windowing. That's why TCP
packets use sequence numbers, acknowledge numbers, etc.; UDP packets don't
use sequence numbers. UDP is connectionless, which means best effort
delievery. Some of TCP protocols are POP3, SMTP, FTP, HTTP etc. whereas some
of UDP protocols are TFTP, DHCP, SNMP etc.

new guy

new guy wrote:
> wrote in message
> news:1149664377.664911.123520@g10g2000cwb.googlegr oups.com...
>> Hi all ,
>> I am new to this group .
>> A basic question.I want to know what is a difference b/w TCP and UDP
>> packet i.e how will u know that the data which u are receiving is
>> travelling via a UDP/TCP packet without using any sniffer.
>>
>> ankit
>>
>
> As you know, TCP uses 3-way handshake and it's connection oriented; TCP
> gives guarenteed delivery, flow control and windowing. That's why TCP
> packets use sequence numbers, acknowledge numbers, etc.; UDP packets don't
> use sequence numbers. UDP is connectionless, which means best effort
> delievery. Some of TCP protocols are POP3, SMTP, FTP, HTTP etc. whereas some
> of UDP protocols are TFTP, DHCP, SNMP etc.
>
> new guy
>
>

UDP is definitely not best effort delivery. That would be TCP. UDP is
minimal effort delivery. With UDP the packet is sent once and if it
doesn't make, UDP couldn't care less.

NM

In article <_MWdncduPKGgXxXZnZ2dnUVZ_u2dnZ2d@comcast.com>,
News 2 Me wrote:

> new guy wrote:
> > wrote in message
> > news:1149664377.664911.123520@g10g2000cwb.googlegr oups.com...
> >> Hi all ,
> >> I am new to this group .
> >> A basic question.I want to know what is a difference b/w TCP and UDP
> >> packet i.e how will u know that the data which u are receiving is
> >> travelling via a UDP/TCP packet without using any sniffer.
> >>
> >> ankit
> >>
> >
> > As you know, TCP uses 3-way handshake and it's connection oriented; TCP
> > gives guarenteed delivery, flow control and windowing. That's why TCP
> > packets use sequence numbers, acknowledge numbers, etc.; UDP packets don't
> > use sequence numbers. UDP is connectionless, which means best effort
> > delievery. Some of TCP protocols are POP3, SMTP, FTP, HTTP etc. whereas
> > some
> > of UDP protocols are TFTP, DHCP, SNMP etc.
> >
> > new guy
> >
> >
>
> UDP is definitely not best effort delivery. That would be TCP. UDP is
> minimal effort delivery. With UDP the packet is sent once and if it
> doesn't make, UDP couldn't care less.

That's not how the term "best effort" is normally defined. IP and UDP
provide best-effort delivery, while TCP provides guaranteed delivery.

See for a good
description of these terms.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

"Barry Margolin" wrote:

> News 2 Me wrote:
>> UDP is definitely not best effort delivery. That would be TCP. UDP
>> is
>> minimal effort delivery. With UDP the packet is sent once and if it
>> doesn't make, UDP couldn't care less.
>
> That's not how the term "best effort" is normally defined. IP and UDP
> provide best-effort delivery, while TCP provides guaranteed delivery.
>
> See for a good
> description of these terms.

I know people who insist on redefining "best effort" as "worst effort."

The term "guaranteed delivery" is also misleading, unfortunately, as it
implies to the clue-challenged that TCP will always get the message
across. In truth, all TCP can do is keep retrying something that is
having problems getting across.

UDP, in certain applications, such as streaming media, actually does
this far better than TCP can. Because the very nature of streaming media
is that packets are sent continuously, and it's far better (in this
streaming media case) to allow an occasional packet to be dropped than
to back up the entire queue with TCP retries.

If the link is so bad that many UDP datagrams are dropped, then a TCP
connection for this stream would be even worse. And, too, one can always
build in forward error correction in the UDP datagrams, to alleviate any
data corruption problem, potentially making this streaming connection a
lot better with UDP than TCP.

I think whenever packets are to be sent frequently and periodically, and
stale packets are of no use, then UDP is a better choice than TCP, even
if errors occur. If messages are only sent "by exception," then TCP is
the better choice.

Bert

Barry Margolin wrote:
> In article <_MWdncduPKGgXxXZnZ2dnUVZ_u2dnZ2d@comcast.com>,
> News 2 Me wrote:
>> UDP is definitely not best effort delivery. That would be TCP. UDP is
>> minimal effort delivery. With UDP the packet is sent once and if it
>> doesn't make, UDP couldn't care less.
>
> That's not how the term "best effort" is normally defined. IP and UDP
> provide best-effort delivery, while TCP provides guaranteed delivery.
>
> See for a good
> description of these terms.
>

But both terms are misnomers, which is why you had to provide a link to
explain how the terms are to be interpreted. When one thinks of the
phrase "best effort," they usually are not thinking along the lines of
UDP's delivery mechanism. The same is true of TCP and "guaranteed."
TCP cannot and does not "guarantee" delivery.

NM

In article ,
News 2 Me wrote:

> Barry Margolin wrote:
> > In article <_MWdncduPKGgXxXZnZ2dnUVZ_u2dnZ2d@comcast.com>,
> > News 2 Me wrote:
> >> UDP is definitely not best effort delivery. That would be TCP. UDP is
> >> minimal effort delivery. With UDP the packet is sent once and if it
> >> doesn't make, UDP couldn't care less.
> >
> > That's not how the term "best effort" is normally defined. IP and UDP
> > provide best-effort delivery, while TCP provides guaranteed delivery.
> >
> > See for a good
> > description of these terms.
> >
>
> But both terms are misnomers, which is why you had to provide a link to
> explain how the terms are to be interpreted. When one thinks of the
> phrase "best effort," they usually are not thinking along the lines of
> UDP's delivery mechanism. The same is true of TCP and "guaranteed."
> TCP cannot and does not "guarantee" delivery.

Everything you say is true. But these are the ways the terms are
defined and used in networking, and if you invert the meanings you're
just going to cause more confusion because many will continue to use
them in the old ways.

The term "guaranteed" is not to be taken literally, but interpreted in
context -- IP and UDP do not make any attempt to confirm receipt or
proper ordering, while TCP tries as much as possible to do this.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

In article ,
News 2 Me wrote:

>But both terms are misnomers, which is why you had to provide a link to
>explain how the terms are to be interpreted.

That is silly. They are decades old "terms of the art" or "jargon."
That their meanings are not what the willfully uninformed might guess is
as irrelevant for network terms like "best effort" as they are for the
terms of any field. Demanding that a "box end wrench" involve something
shaped like a box intead of a circle at best won't get respect from the
millions of people who have used those tools in the last 100 years. See
http://www.google.com/search?q="box+end+wrench"

See the many definitions Google finds in
http://www.google.com/search?q="best+effort"
Then see
http://www.google.com/search?q="best+effort+contract"+legal
for precedent for "best effort" not implying much of a guarantee.


Vernon Schryver vjs@rhyolite.com