Ports and Protocols

• Previous message: Celtic Leroy: "Re: Ports and Protocols"
• In reply to: Celtic Leroy: "Re: Ports and Protocols"
• Next in thread: Moe Trin: "Re: Ports and Protocols"
• Reply: Moe Trin: "Re: Ports and Protocols"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: 18 Nov 2004 22:46:36 GMT

>>>The answer is No! You cannot have 2 different programs using the same
>>>port number with different protocols. Once a program begins using, or
>>>"listening", on a port, that port is considered "in use" and you'll
>>>get an error if you try to connect with another program.

A TCP or UDP connection is defined by the 4-tuple (source IP, source
port, destination IP, destination port).

At any given instant of time, only a single program can be listening
on a given (destination IP, destination port) combination. However,
once it receives a connection, the same program, a new instance of the
same program, or a completely different program can listen for the
next connection request on the pair.

Even with a completly different program listening for the new
connection, many existing programs can be using the same (destination
IP, destination port) pair, so long as either the source IP or the
source port differ.

This model is out of TCP itself and has nothing to do with the
underlying operating system, although the underlying implementation
may impose limits.

To the best of my knowledge, both Windows and Unix offer full support
for this model.

        ...
>>This might be true of some versions of windoze - and if so, it's another
>
>The OP is using Windoze (check the headers of his post)...so the
>answer was given in kind. I don't dispute that MS has done some
>pretty bad (incompetent) programming. I also know that Windows will
>not...I repeat WILL NOT allow 2 different processes to use the same
>port number, regardless of whether they use different protocols or
>not.

If you mean "listen on the same (IP, port) number pair," correct.
Neither will Unix.

Note that the (IP, port) pairs are separate for TCP and UDP stacks.
So, I can readily have one application listening on port P for TCP and
a different applicatoin listening on port P for UDP. Works just fine.

Note that when setting up a socket, you not only define the IP and
port, but also the address family and protocol family (e.g., IPv4
vs. IPv6 and TCP, UDP, or ICMP). So it is easy for the networking
code to keep separate tables of listeners and >appear to< re-use
ports.

It is the _convention_ that, where both TCP and UDP versions of a
given protocol are meaningful (e.g. DNS), to support both on the same
numeric port value. But that is a convention and not a requirement.

        ..
>>>Effectively, TCP and UDP are very different and would never normally
>>>be used within the same application. UDP is connectionless and TCP is
>>>an acknowledged connection protocol.

These are the essential differences, but it is quite common for a
single application to use both. Each to its strength. For example,
Telnet normally uses UDP for DNS lookups and TCP for its connection.

        ...
>>So, DNS uses both protocols, but the same port AT THE SAME TIME. UDP is
>>used for replies that are 512 octets or less - TCP is 513 octets or more
>>and zone transfers.

Close, but not quite. If I do a DNS request on UDP, the server must
respond using UDP: it can't decide to respond using TCP, regardless of
the response size. As a client, if I think the response might be
large (e.g., the UDP response was "too big to fit"), I might try a TCP
request.

For overhead reasons, many DNS servers do not reply to TCP requests.

Craig

• Previous message: Celtic Leroy: "Re: Ports and Protocols"
• In reply to: Celtic Leroy: "Re: Ports and Protocols"
• Next in thread: Moe Trin: "Re: Ports and Protocols"
• Reply: Moe Trin: "Re: Ports and Protocols"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]