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

[Alexander N. Spitzer]

If I have a machine with 3 virtual IP addresses (192.168.1.[5-7]), how
can I start 3 instances of the same RMI application (each started with
different properties/configs), each listening on the port 1234, but each
instance binds to a different ip address.

that is to say:
instance #1 binds to 192.168.1.5/port 1234
instance #2 binds to 192.168.1.6/port 1234
instance #3 binds to 192.168.1.7/port 1234

I guess I am looking for something like:
Registry registry = LocateRegistry. createRegistry( <IPADDR>,<PORT> );

I tried
System.setPrope rty("java.rmi.s erver.hostname" ,"<IPADDR>") ;
but had no luck
current code looks something like this:

/******* server side *********/
System.getPrope rties().setProp erty("java.rmi. server.hostname ",serverip) ;
Registry registry = LocateRegistry. createRegistry( serverport);
registry.rebind ("RMITest", this);

//serverip is the IP to bind to... server port is port 1234

/******* client side **********/
Registry registry=Locate Registry.getReg istry(serverip, serverport);
RMITestInterfac e rmit=(RMITestIn terface)(regist ry.lookup("RMIT est"));
rmit.dosomethin gcool();
second instance (even though serverip is different) complains
java.rmi.server .ExportExceptio n: Port already in use:1234; nested
exception is: java.net.BindEx ception: Address already in use

These have to be seperate instances of the application for each
customer... I know that it is possible to run them on different ports,
but this is really not acceptable in a large clustered environment. this
would become a complete nightmare very quickly.
what am I missing?!?! I have googled high and low, and looked through
all my java books, but see no mention of such a scenario! anyone?

TIA!

-alex

[Sam]

Esmond Pitt <es*********@no t.bigpond.com> wrote in message news:<6m******* ************@ne ws-server.bigpond. net.au>...

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]

"Esmond Pitt <es*********@no tatall.bigpond. com>" wrote in comp.lang.java:

[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.