RMI binding to SAME port but DIFFERENT IP address on SAME host

[Sam]

Sam

OK, if UDP or TCP or ICMP or whatever transport layer matches the socket
to the inbound IP packet, instead of IP, the local IP address *still*
doesn't get 'thrown away as the data goes up the protocol stack',
because it must still be there in the IP packet for TCP or UDP to do
this matching, and it must also available be in the socket descriptor to
be matched. Can we agree on that?

Now, that I can agree with. In fact, the "table" which matches ip and
port number to the socket turns out to be a linked series of data
blocks, each of which must contain at least a local port, but could
contain local ip, foriegn ip and foriegn port as well. These
eventuaully link back to the actual process via series of pointers,
according to Stevens' description of Berkely 4.x distributions.

This also means that TCP, UDP, ICMP &co indeed deal with IP data, &
just goes to show that TCP/IP implementation layering is not as clean as
you might like to think. Certainly IP doesn't have to deal with TCP
data, but the other way round does happen (no worse than a derived class
using methods from its base class really).

Of course Stevens vol II only describes one implementation. I don't know
that a 'cleaner' implementation where IP despatches packets to sockets
is infeasible either

What I learned was the traditional 5-layer model - App / Transport
(TCP,UDP)/ Ip / Link / Physical, is clarifed nicely in some key areas
by Steven's description of how the implementation itself is layered,
i.e:

Process / Socket Layer / Protocol Layer (TCP, UDP, IP, ICMP, IGMP) /
Interface layer.

So, here it becomes apparent that the "protocol layer" incorporates
both TCP and IP Data, assigning it to to the correct socket in the
end. This melds the transport and ip layer together in the
implementation stack, and there is clearly data overlap between the
two, specifically IP address. Nonetheless, the IP input and UDP and
TCP input routines and funtionality are clearly distinct.

Ca suffit,
Sam90

 

[Randolf Richardson]

[sNip]

I'm not sure if that is what you meant to imply, but there is no
"protocol number" field in a TCP/IP header.

see http://mindprod.com/jgloss/tcpip.html

The host computer simply knows which protocol it is hosting on each
port.

You can't have two different protocols hosted on the same port, e.g.
HTTP and FTP.

[sNip]
There is a protocol number field in an IP packet header, and I was
talking about IP at the time. Obviously in the case of TCP the protocol
number is the TCP protocol number, 6. BTW the statement that 'the host
computer simply knows which protocol it is hosting on each port' needs
further work. At the TCP level the host neither knows nor cares about
the protocol; at the IP level you *can* have several protocols on the
same port, e.g. ICMP, UDP, TCP.

An official list of all the protocols can be found here:

PROTOCOL NUMBERS
http://www.iana.org/assignments/protocol-numbers

Of those protocols, TCP and UDP tend to be the most interesting to
most people (probably with ICMP coming in at third place) since they are so
commonly used. Here's a list of all the port numbers used for TCP and UDP:

PORT NUMBERS
http://www.iana.org/assignments/port-numbers

Unfortunately it gets very confusing to describe these things because
the terminology is re-used. It might be easier to ask about an "IP
protocol" (e.g., TCP, UDP, ICMP, etc.), or a "TCP/IP protocol" (e.g., HTTP,
SMTP, POP3, FTP, etc.) or "UDP/IP protocol" (e.g., DNS) instead.

It's important to note that many of the protocols that are transacted
over TCP/IP and UDP/IP are sometimes supported (and recommended to be
supported) on both IP protocols. For example, you'll find that it's
possible to successfully run a DNS query over TCP/IP port 53 as well as the
usual UDP/IP port 53 on many DNS servers around the internet.

I hope this information will help to clear up some of the confusion.