Possible to open more than one connection on same port?

I am wondering if it is possible to (open/bind/send on etc.) to the
same port more than once?

For example:
Can I have both UDP and TCP going through the same port?
Can I bind two UDP sockets to the same local port on the server side
and two UDP sockets on the same port on the client side and keep thier
individuality?
Can I send TCP and SSL/TCP on the same port?

Trying to look ahead at problems for design phase of C++
implementation.

brekehan <(E-Mail Removed)> wrote:
> I am wondering if it is possible to (open/bind/send on etc.) to the
> same port more than once?

Sometimes. Keep in mind that a TCP connection, or UDP flow is "named"
by the five-tuple of protocol (TCP, UDP etc) local/remote IP and
local/remote port. So long as at least one of those five things
differs, you have a different connection/flow.

> For example:
> Can I have both UDP and TCP going through the same port?

In theory. The port address spaces are (theoretically) per-protocol.
Some APIs/stacks may not fully support the theory.

> Can I bind two UDP sockets to the same local port on the server side
> and two UDP sockets on the same port on the client side and keep thier
> individuality?

Nope - in that case, the five-tuples are exactly the same.

> Can I send TCP and SSL/TCP on the same port?

The same "port" - sure, if it happens to be different connection - but
perhaps not the same "connection" (that will depend on the SSL library
I suspect) - remember a connection is identified by more than just one
port number.

> Trying to look ahead at problems for design phase of C++
> implementation.

Some of the works of W. Richard Stevens and/or Richard Stallings might
be good to have on your bookshelf...

rick jones
--
web2.0 n, the dot.com reunion tour...
these opinions are mine, all mine; HP might not want them anyway...
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

On Mar 10, 3:05 am, "brekehan" <c...@austin.rr.com> wrote:
> I am wondering if it is possible to (open/bind/send on etc.) to the
> same port more than once?
>
> For example:
> Can I have both UDP and TCP going through the same port?
> Can I bind two UDP sockets to the same local port on the server side
> and two UDP sockets on the same port on the client side and keep thier
> individuality?
> Can I send TCP and SSL/TCP on the same port?
>
> Trying to look ahead at problems for design phase of C++
> implementation.

Your ideas are good, but just in theory. The port number is an
identifier of a process in OS.
Packets received from a port are processed by the process listening on
that port.
Of course you can have two connections on the same port as long as the
two party have negotiated it previously. But it brings complexity to
implementation as well as confusion. You want both UDP and TCP for the
same port, which brings only efforts with nothing good.

>>>>> "brekehan" == brekehan <(E-Mail Removed)> writes:

brekehan> I am wondering if it is possible to (open/bind/send on
brekehan> etc.) to the same port more than once?

connect/send: yes; bind: no.


brekehan> For example: Can I have both UDP and TCP going through
brekehan> the same port?

Short answer: yes.

Longer answer: Bad question. UDP port numbers and TCP port numbers
are two separate address spaces. They don't interfere each other.
UDP port 1234 has completely nothing to do with TCP port 1234 (other
than looking alike). They're 2 separate entities.


brekehan> Can I bind two UDP sockets to the same local port on the
brekehan> server side and two UDP sockets on the same port on the
brekehan> client side and keep thier individuality?

I cannot understand your question.

Let's put it this way:

A server process wants to _listen_ to a TCP/UDP port. It has to
"bind" to that port. The OS then associates that port with the
process. Much like how your mobile phone number is associated to your
mobile phone. The OS forwards incoming packets addressed to that port
to the server process -- after packet sequencing (TCP), reassembly and
header stripping. Since one port can only be associated with one
process, you cannot have 2 such server processes binding to the same
port. Otherwise, if you're to write the OS, how would you decide
which process to forward the received packet to? Similarly, you
cannot have 2 separate mobile phones that ring when a single number is
called.

Now, for client processes, this is a slightly different story. When
it needs to contact a server, it "sends" or "connects" to a certain
port (determined by the server) on a remote machine. This is like
making an outgoing call to mobile phones. Different people can call
the same number. It is possible for 2 client processes to be sending
to the same server port. (Each client process actually has its own
local port number, usually an arbitrary one assigned by the OS. This
is used when the server sends replies to the client. This is
different from mobile phones, where the caller's number is not
assigned arbitrarily.)

All in all, the port number (together with IP address) is a number for
addressing the recipient. For each address, only recipient can be
associated. (Otherwise, how should the ambiguity be resolved). But
one address can be utilized by many senders at once.


brekehan> Can I send TCP and SSL/TCP on the same port?

Yes. TCP port numbers are a separate address space from UDP.


brekehan> Trying to look ahead at problems for design phase of C++
brekehan> implementation.

You should make it flexible. Have the programs read the port numbers
from a config file, rather than hardcoding the values.

If parsing config files seem complicated, then you should at least
define symbolic constants (either via #define or simply "const int" in
some header files) for the port numbers. Use a different number for
different components. And refrain from *deriving* the port number
used by one component from another.

With these measures, you can defer the decision on the port number to
a later stage of your project. With #define (or const int), you defer
it to pre-build time. With config files, you further defer it to
post-build time.


--
Lee Sau Dan §õ¦u´° ~{@nJX6X~}

E-mail: (E-Mail Removed)
Home page: http://www.informatik.uni-freiburg.de/~danlee

LEE Sau Dan <(E-Mail Removed)> writes:

>>>>>> "brekehan" =3D=3D brekehan <(E-Mail Removed)> writes:

> brekehan> I am wondering if it is possible to (open/bind/send on
> brekehan> etc.) to the same port more than once?

>connect/send: yes; bind: no.


> brekehan> For example: Can I have both UDP and TCP going through
> brekehan> the same port?=20=20

>Short answer: yes.

>Longer answer: Bad question. UDP port numbers and TCP port numbers
>are two separate address spaces. They don't interfere each other.
>UDP port 1234 has completely nothing to do with TCP port 1234 (other
>than looking alike). They're 2 separate entities.


> brekehan> Can I bind two UDP sockets to the same local port on the
> brekehan> server side and two UDP sockets on the same port on the
> brekehan> client side and keep thier individuality?=20=20

>I cannot understand your question.

>Let's put it this way:

>A server process wants to _listen_ to a TCP/UDP port. It has to
>"bind" to that port. The OS then associates that port with the
>process. Much like how your mobile phone number is associated to your
>mobile phone. The OS forwards incoming packets addressed to that port
>to the server process -- after packet sequencing (TCP), reassembly and
>header stripping. Since one port can only be associated with one
>process, you cannot have 2 such server processes binding to the same
>port. Otherwise, if you're to write the OS, how would you decide
>which process to forward the received packet to? Similarly, you
>cannot have 2 separate mobile phones that ring when a single number is
>called.


Well, it could. In my house, both phones upstairs and downstairs ring when
a call comes in and both can be answered and in fact both can be answered
at the same time. The OS could deliver the same packet to two different
processes. I believe that it does not, but it could. It might of course
confuse the other end when it got two different replies, and sometimes
happens with my phones. But for example, one could be a recording machine
(like tcpdump) while the other is something with actually answers the
packets.

But your analogy is good.

>Now, for client processes, this is a slightly different story. When
>it needs to contact a server, it "sends" or "connects" to a certain
>port (determined by the server) on a remote machine. This is like
>making an outgoing call to mobile phones. Different people can call
>the same number. It is possible for 2 client processes to be sending
>to the same server port. (Each client process actually has its own
>local port number, usually an arbitrary one assigned by the OS. This
>is used when the server sends replies to the client. This is
>different from mobile phones, where the caller's number is not
>assigned arbitrarily.)

>All in all, the port number (together with IP address) is a number for
>addressing the recipient. For each address, only recipient can be
>associated. (Otherwise, how should the ambiguity be resolved). But
>one address can be utilized by many senders at once.

That of course depends on the program servicing that port. It could well
also just service one connection at a time, and refuse all others.




> brekehan> Can I send TCP and SSL/TCP on the same port?

>Yes. TCP port numbers are a separate address space from UDP.


> brekehan> Trying to look ahead at problems for design phase of C++
> brekehan> implementation.

>You should make it flexible. Have the programs read the port numbers
>from a config file, rather than hardcoding the values.

>If parsing config files seem complicated, then you should at least
>define symbolic constants (either via #define or simply "const int" in
>some header files) for the port numbers. Use a different number for
>different components. And refrain from *deriving* the port number
>used by one component from another.

>With these measures, you can defer the decision on the port number to
>a later stage of your project. With #define (or const int), you defer
>it to pre-build time. With config files, you further defer it to
>post-build time.


>--=20
>Lee Sau Dan =A7=F5=A6u=B4=B0 ~=
>{@nJX6X~}

>E-mail: (E-Mail Removed)
>Home page: http://www.informatik.uni-freiburg.de/~danlee