
Signature
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
Interesting...I thought the idea of a port was to disambiguate between
multiple destinations for a packet in a single machine.
In other words, IP disambiguates the node (among other nodes in the
network), but IP is not sufficient when there are multiple processes
that can receive packets in any given machine (eg, a machine that has
processes listening on port 25, 80 and 110). It is the port that
identifies the ultimate destination.
However if a port is attached to multiple threads as in this case, how
does the disambiguation work? Is there a still lower-level mechanism
that is used to do this?
best
satish
> Your observation is correct. Your intuition is not. There is no
> temporary port involved (a common misconception).
[quoted text clipped - 18 lines]
> [ do not email me copies of your followups ]
> g o r d o n + n e w s @ b a l d e r 1 3 . s e
Gordon Beaton - 18 Oct 2005 12:36 GMT
> Interesting...I thought the idea of a port was to disambiguate
> between multiple destinations for a packet in a single machine.
[quoted text clipped - 4 lines]
> processes listening on port 25, 80 and 110). It is the port that
> identifies the ultimate destination.
The port number is only one of several attributes used to identify the
connection.
> However if a port is attached to multiple threads as in this case,
> how does the disambiguation work? Is there a still lower-level
> mechanism that is used to do this?
Port numbers are defined by TCP (and UDP). IP does not know about port
numbers, it only knows about IP addresses.
IP passes incoming packets to TCP (or UDP), where the recipient is
determined based on this 4-tuple:
{ local address, local port, remote address, remote port }
Any two connections will differ in at least one of the four fields, so
they are distinct and there is no ambiguity. TCP must examine all four
fields in order to dispatch incoming packets to the right destination.
A "connection" for a typical ServerSocket might look like this:
{ *, 80, *, * }
where * represent any address or port number.
When a client connects, the listening socket is cloned and the
wildcard fields are bound, resulting in a connection that looks like
this:
{ Server_IP, 80, HostA_IP, Client1_Port }
A second client connecting from the same host would result in this
connection:
{ Server_IP, 80, HostA_IP, Client2_Port }
A third client connecting, this time from a different host:
{ Server_IP, 80, HostB_IP, Client3_Port }
/gordon

Signature
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e
Matt Humphrey - 18 Oct 2005 12:39 GMT
> Interesting...I thought the idea of a port was to disambiguate between
> multiple destinations for a packet in a single machine.
[quoted text clipped - 8 lines]
> does the disambiguation work? Is there a still lower-level mechanism
> that is used to do this?
This really doesn't have anything to do with threads although it is common
(but not required) for each connection to be serviced by its own thread. The
full connection between one machine and another is uniquely identified by
the client IP, client port, server IP and server port. Multiple connections
to the same service (server IP & port) are disambiguated by the fact that
the come from different clients (client IP-port pairs) Each connection
end-point receives its own stream from its corresponding client.
Cheers,
Thomas Weidenfeller - 18 Oct 2005 13:01 GMT
> Interesting...I thought the idea of a port was to disambiguate between
> multiple destinations for a packet in a single machine.
>
> In other words, IP disambiguates the node (among other nodes in the
> network),
Not exactly. IP is not centered around hosts or nodes, but interfaces.
The host ID part of an IP address does not address that particular host
as a whole, but an IP interface at that host. A single machine can have
multiple interfaces, each with an own IP address.
> but IP is not sufficient when there are multiple processes
It doesn't have to be multiple processes. A single process can listen to
multiple ports. The common usage for ports is to differentiate between
services - services which can, but don't need to, be provided by
different processes.
> that can receive packets in any given machine (eg, a machine that has
> processes listening on port 25, 80 and 110). It is the port that
> identifies the ultimate destination.
No, it is the so called "half association", aka "socket", aka "transport
address" which determines the ultimate destination.
A "half association" consists of
- protocol designation (e.g. TCP or UDP)
- IP address (to identify the host's interface)
- port
The port alone is not sufficient. E.g. TCP port 1234 and UDP port 1234
are different ports. And TCP port 9876 on the host's IP address
192.168.1.1 is different from TCP port 9876 on the host's IP address
192.168.1.2.
/Thomas

Signature
The comp.lang.java.gui FAQ:
ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
Roedy Green - 19 Oct 2005 10:01 GMT
>Not exactly. IP is not centered around hosts or nodes, but interfaces.
>The host ID part of an IP address does not address that particular host
>as a whole, but an IP interface at that host. A single machine can have
>multiple interfaces, each with an own IP address.
He means interface in the general sense, nothing to do with Java
interafaces.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.
Alan Krueger - 19 Oct 2005 03:46 GMT
> Interesting...I thought the idea of a port was to disambiguate between
> multiple destinations for a packet in a single machine.
[quoted text clipped - 8 lines]
> does the disambiguation work? Is there a still lower-level mechanism
> that is used to do this?
There are two sides to every connection, so there are two IP addresses
and TWO port numbers. The connection is identified by the tuple
including both pairs of address:port endpoints.
Thus, (10.0.0.1:12345,10.0.0.2:80) and (10.0.0.1:12346,10.0.0.2:80) are
two separate connections between the same two machines with the same
server port, but because the client port is different, the connections
are distinct.
sierra1bravo@gmail.com - 19 Oct 2005 04:13 GMT
Dear all
Thanks to Gordon, Matt, Thomas, Alan, for taking time off to clarify
what was (for me) a very vexing issue...the discussion has been most
illuminating.
Sierra Bravo
Roedy Green - 19 Oct 2005 09:59 GMT
>Interesting...I thought the idea of a port was to disambiguate between
>multiple destinations for a packet in a single machine.
it is, but many clients can share it.
See http://mindprod.com/jgloss/port.html
Please see http://mindprod.com/jgloss/tcpip.html
It will should clear up your various misconceptions.

Signature
Canadian Mind Products, Roedy Green.
http://mindprod.com Again taking new Java programming contracts.