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

Discussion in 'Java' started by Alexander N. Spitzer, Jul 25, 2004.

  1. 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.setProperty("java.rmi.server.hostname","<IPADDR>");
    but had no luck


    current code looks something like this:

    /******* server side *********/
    System.getProperties().setProperty("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=LocateRegistry.getRegistry(serverip,serverport);
    RMITestInterface rmit=(RMITestInterface)(registry.lookup("RMITest"));
    rmit.dosomethingcool();


    second instance (even though serverip is different) complains
    java.rmi.server.ExportException: Port already in use:1234; nested
    exception is: java.net.BindException: 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
     
    Alexander N. Spitzer, Jul 25, 2004
    #1
    1. Advertising

  2. "Alexander N. Spitzer" <> wrote in message
    news:mNEMc.1658$A%...
    [snipped]
    > I guess I am looking for something like:
    > Registry registry = LocateRegistry.createRegistry(<IPADDR>,<PORT>);


    There is no method in LocateRegistry with this signature. You can create a
    Registry object bound to a specific IP address using this form of the
    method:

    public static Registry createRegistry(int port, RMIClientSocketFactory csf,
    RMIServerSocketFactory ssf) throws RemoteException

    You will have to provide a class that implements the RMIServerSocketFactory
    interface (the RMIClientSocketFactory parm can be null); this class will
    create a ServerSocket that you will have to bind to the desired IP address.
    Here is an example:

    import java.rmi.server.*;
    import java.io.*;
    import java.net.*;
    public class AnchorSocketFactory extends RMISocketFactory implements
    Serializable
    {
    private InetAddress ipInterface = null;
    public AnchorSocketFactory() {}
    public AnchorSocketFactory(InetAddress ipInterface)
    {
    this.ipInterface = ipInterface;
    }
    public ServerSocket createServerSocket(int port)
    {
    ServerSocket serverSocket = null;
    try
    {
    serverSocket = new ServerSocket(port, 50, ipInterface);
    }
    catch (Exception e)
    {
    System.out.println(e);
    }
    return (serverSocket);
    }
    public Socket createSocket(String dummy, int port) throws IOException
    {
    return (new Socket(ipInterface, port));
    }
    public boolean equals(Object that)
    {
    return (that != null && that.getClass() == this.getClass());
    }
    }

    In your code do this:

    AnchorSocketFactory sf = new AnchorSocketFactory(<your InetAddress>);
    LocateRegistry.createRegistry(port, null, sf);

    HTH

    Alex Molochnikov
    Gestalt Corporation
    www.gestalt.com
     
    Alex Molochnikov, Jul 25, 2004
    #2
    1. Advertising

  3. Alexander N. Spitzer

    Sam Guest

    "Alexander N. Spitzer" <> wrote in message news:<mNEMc.1658$A%>...
    > 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.setProperty("java.rmi.server.hostname","<IPADDR>");
    > but had no luck
    >
    >
    > current code looks something like this:
    >
    > /******* server side *********/
    > System.getProperties().setProperty("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=LocateRegistry.getRegistry(serverip,serverport);
    > RMITestInterface rmit=(RMITestInterface)(registry.lookup("RMITest"));
    > rmit.dosomethingcool();
    >
    >
    > second instance (even though serverip is different) complains
    > java.rmi.server.ExportException: Port already in use:1234; nested
    > exception is: java.net.BindException: 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



    Alex,

    I doubt an end host keeps multiple ports for each active ip address.
    Data from a nic card is passed up the protocol stack, and the source
    ip address has been discarded by the time it reaches the port.

    You might try a single RMI server listening on a single port, passing
    data to a given instance of a jvm based on customer id.

    Sam90
     
    Sam, Jul 26, 2004
    #3
  4. > Alex,
    >
    > I doubt an end host keeps multiple ports for each active ip address.
    > Data from a nic card is passed up the protocol stack, and the source
    > ip address has been discarded by the time it reaches the port.
    >
    > You might try a single RMI server listening on a single port, passing
    > data to a given instance of a jvm based on customer id.
    >
    > Sam90


    Sam, in an ASP environment, it is a requirement to have seperate
    instances for each client.

    Alex Molochnikov gave me the answer I was looking for, which was:

    There is no method in LocateRegistry with this signature. You can create
    a Registry object bound to a specific IP address using this form of the
    method:

    public static Registry createRegistry(int port, RMIClientSocketFactory
    csf,RMIServerSocketFactory ssf) throws RemoteException

    Thanks Alex M. et al.!
     
    Alexander N. Spitzer, Jul 26, 2004
    #4
  5. Alexander N. Spitzer

    Esmond Pitt Guest

    Sam wrote:
    >
    > I doubt an end host keeps multiple ports for each active ip address.
    > Data from a nic card is passed up the protocol stack, and the source
    > ip address has been discarded by the time it reaches the port.


    Sam, none of this guesswork is true.
     
    Esmond Pitt, Jul 26, 2004
    #5
  6. Alexander N. Spitzer

    Sam Guest

    "Alexander N. Spitzer" <> wrote in message news:<>...
    > > Alex,
    > >
    > > I doubt an end host keeps multiple ports for each active ip address.
    > > Data from a nic card is passed up the protocol stack, and the source
    > > ip address has been discarded by the time it reaches the port.
    > >
    > > You might try a single RMI server listening on a single port, passing
    > > data to a given instance of a jvm based on customer id.
    > >
    > > Sam90


    > Sam, in an ASP environment, it is a requirement to have seperate
    > instances for each client.


    That actually is what I was proposing - but that's a moot point, since
    you got Alex's correct answer.

    >
    > Alex Molochnikov gave me the answer I was looking for, which was:



    > There is no method in LocateRegistry with this signature. You can create
    > a Registry object bound to a specific IP address using this form of the
    > method:
    >
    > public static Registry createRegistry(int port, RMIClientSocketFactory
    > csf,RMIServerSocketFactory ssf) throws RemoteException


    My bad - I did some speculation which I didn't check, and now see what
    happened. Alex's answer didn't make to Google by the time I made my
    post


    > Thanks Alex M. et al.!


    Agreed.

    Regards,
    Sam90
     
    Sam, Jul 26, 2004
    #6
  7. Alexander N. Spitzer

    Sam Guest

    Esmond Pitt <> wrote in message news:<DtZMc.16813$>...
    > Sam wrote:
    > >
    > > I doubt an end host keeps multiple ports for each active ip address.
    > > Data from a nic card is passed up the protocol stack, and the source
    > > ip address has been discarded by the time it reaches the port.

    >
    > Sam, none of this guesswork is true.


    It isn't? How so?

    Regards,
    Sam90
     
    Sam, Jul 26, 2004
    #7
  8. Alexander N. Spitzer

    Esmond Pitt Guest

    Sam wrote:
    >>>I doubt an end host keeps multiple ports for each active ip address.
    >>>Data from a nic card is passed up the protocol stack, and the source
    >>>ip address has been discarded by the time it reaches the port.

    >>
    >>Sam, none of this guesswork is true.

    >
    >
    > It isn't? How so?


    Because what the OP described is perfectly possible, despite your doubts
    and speculations. See ServerSocket(port,backlog,bindAddress). If you
    don't know the answer please don't guess, it only confuses others.
     
    Esmond Pitt, Jul 27, 2004
    #8
  9. Alexander N. Spitzer

    Sam Guest

    Esmond Pitt <> wrote in message news:<8AkNc.18448$>...
    > Sam wrote:
    > >>>I doubt an end host keeps multiple ports for each active ip address.
    > >>>Data from a nic card is passed up the protocol stack, and the source
    > >>>ip address has been discarded by the time it reaches the port.
    > >>
    > >>Sam, none of this guesswork is true.

    > >
    > >
    > > It isn't? How so?

    >
    > Because what the OP described is perfectly possible, despite your doubts
    > and speculations.


    I agree my speculation was incorrect, and I admit it and I'm not happy
    about it. However, I did qualify it, that is I didn't say "this is the
    gospel truth" or anything like that. I said "I doubt it", which
    liberally translated means, "I'm shooting from the hip, beware".
    Besides, nothing I said was actually false. I just want to clarify
    that. Specifically, an end host doesn't track mutliple ports per ip -
    does it? When data is passed up the protocol stack, the IP address is
    discarded by the time it reaches

    >See ServerSocket(port,backlog,bindAddress).


    I have, and I'm pretty sure I figured out where I went wrong.

    > If you
    > don't know the answer please don't guess, it only confuses others.


    I did get sloppy, and I admit it. Oh well, no harm done, luckily
    someone came along with the correct answer, actually even before I
    posted my poor one. I'll be more careful next time.

    Regards,
    Sam90
     
    Sam, Jul 27, 2004
    #9
  10. Alexander N. Spitzer

    Esmond Pitt Guest

    Sam

    I don't really know what you mean by 'tracks multiple ports per IP',
    which TCP certainly does otherwise nothing would work at all. Maybe you
    mean 'multiple IP addresses per port'? in which case the answer is
    certainly 'yes' as well, hence the ServerSocket constructor I referred
    you to. The local IP address by which incoming data came in is not
    reliable due to the 'weak end system model' described in the RFC, maybe
    this is what you are referring to, but the IP address to which the
    reading socket is bound is always available via Socket.getLocalAddress().

    EJP
     
    Esmond Pitt, Jul 28, 2004
    #10
  11. Alexander N. Spitzer

    Sam Guest

    Esmond Pitt <> wrote in message news:<W6FNc.19902$>...
    > Sam
    >
    > I don't really know what you mean by 'tracks multiple ports per IP',
    > which TCP certainly does otherwise nothing would work at all. Maybe you
    > mean 'multiple IP addresses per port'? in which case the answer is
    > certainly 'yes' as well, hence the ServerSocket constructor I referred
    > you to. The local IP address by which incoming data came in is not
    > reliable due to the 'weak end system model' described in the RFC, maybe
    > this is what you are referring to, but the IP address to which the
    > reading socket is bound is always available via Socket.getLocalAddress().
    >
    > EJP


    Esmond,

    My thinking was: whatever OS routine is responsible for delivering
    payload data to a listening application over a specific port doesn't
    need to know what IP address the data came over, it only needs to
    deliver it to the correct port. The IP address doesn't even exist at
    the transport layer. So to my mind the only the way the requirement
    could be achieved was to somehow set up separate ports with the same
    port number for each listening interface, which seemed unlikely.

    However, what I failed to account for is that Java Sockets speak with
    IP at some level, because for example they can specify the remote IP
    in the Socket class. So, from there it's not much of a jump to realize
    it probably has a way to understand the local IP address, as well.

    I'm still unclear as to the mechanics of it, though. I'm pretty sure
    that on Windows Jave uses JNI to interact with the WinSock API to
    handle it's network functionality. But, my real question is, what
    exactly is a "port" anyway, except a numeric label which has a
    constraint that it can't be re-used within a single IP address? In the
    end, it may be that it's simply a question of processes - the Winsock
    API or corresponding OS module probably tracks some internal table
    which matches a port to a specific interface, and as long the
    combination of the two is different from all other entries in its
    table, no problem. In the end, what I thought was "unlikely" is
    probably what actually occurs - the OS tracks a separate port for each
    interface, or at least has the capability of doing so. (DISCLAIMER:
    the preceding is pure speculation...)

    Regards,
    Sam90
     
    Sam, Jul 29, 2004
    #11
  12. Alexander N. Spitzer

    Esmond Pitt Guest

    Sam

    IP delivers data via sockets. That's what it does, it can't do anything
    else. A socket is identified by its IP address, its port number, and its
    protocol number. In the case of TCP, the socket is one end of a
    connection whose other end is defined by *its* IP address and port
    number. So, for the data to go anywhere at all IP has to know the local
    address and port number *first*, i.e. it scans the table of sockets
    somehow to find one with the target IP address/port/protocol no.
    specified in the incoming IP packet. Then, the data is passed to that
    socket, and the local IP address (& port) of any socket can be retrieved
    via the Sockets API. This is nothing to do with Java, it all happens at
    the IP layer. See W R Stevens 'TCP/IP Illustrated' for details. The only
    time Java comes into it is by mapping the Sockets API into methods of
    the Socket/ServerSocket classes, e.g. Socket.getLocalXXX().

    EJP

    Sam wrote:
    > Esmond Pitt <> wrote in message news:<W6FNc.19902$>...
    >
    >>Sam
    >>
    >>I don't really know what you mean by 'tracks multiple ports per IP',
    >>which TCP certainly does otherwise nothing would work at all. Maybe you
    >>mean 'multiple IP addresses per port'? in which case the answer is
    >>certainly 'yes' as well, hence the ServerSocket constructor I referred
    >>you to. The local IP address by which incoming data came in is not
    >>reliable due to the 'weak end system model' described in the RFC, maybe
    >>this is what you are referring to, but the IP address to which the
    >>reading socket is bound is always available via Socket.getLocalAddress().
    >>
    >>EJP

    >
    >
    > Esmond,
    >
    > My thinking was: whatever OS routine is responsible for delivering
    > payload data to a listening application over a specific port doesn't
    > need to know what IP address the data came over, it only needs to
    > deliver it to the correct port. The IP address doesn't even exist at
    > the transport layer. So to my mind the only the way the requirement
    > could be achieved was to somehow set up separate ports with the same
    > port number for each listening interface, which seemed unlikely.
    >
    > However, what I failed to account for is that Java Sockets speak with
    > IP at some level, because for example they can specify the remote IP
    > in the Socket class. So, from there it's not much of a jump to realize
    > it probably has a way to understand the local IP address, as well.
    >
    > I'm still unclear as to the mechanics of it, though. I'm pretty sure
    > that on Windows Jave uses JNI to interact with the WinSock API to
    > handle it's network functionality. But, my real question is, what
    > exactly is a "port" anyway, except a numeric label which has a
    > constraint that it can't be re-used within a single IP address? In the
    > end, it may be that it's simply a question of processes - the Winsock
    > API or corresponding OS module probably tracks some internal table
    > which matches a port to a specific interface, and as long the
    > combination of the two is different from all other entries in its
    > table, no problem. In the end, what I thought was "unlikely" is
    > probably what actually occurs - the OS tracks a separate port for each
    > interface, or at least has the capability of doing so. (DISCLAIMER:
    > the preceding is pure speculation...)
    >
    > Regards,
    > Sam90
     
    Esmond Pitt, Jul 29, 2004
    #12
  13. Alexander N. Spitzer

    Roedy Green Guest

    On Thu, 29 Jul 2004 06:43:46 GMT, Esmond Pitt
    <> wrote or quoted :

    >hat's what it does, it can't do anything
    >else. A socket is identified by its IP address, its port number, and its
    >protocol number.


    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.

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
     
    Roedy Green, Jul 29, 2004
    #13
  14. Alexander N. Spitzer

    Esmond Pitt Guest

    Roedy

    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.

    EJP

    Roedy Green wrote:
    > On Thu, 29 Jul 2004 06:43:46 GMT, Esmond Pitt
    > <> wrote or quoted :
    >
    >
    >>hat's what it does, it can't do anything
    >>else. A socket is identified by its IP address, its port number, and its
    >>protocol number.

    >
    >
    > 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.
    >
     
    Esmond Pitt, Jul 29, 2004
    #14
  15. Alexander N. Spitzer

    Sam Guest

    Esmond Pitt <> wrote in message news:<>...
    > Sam
    >
    > IP delivers data via sockets. That's what it does, it can't do anything
    > else. A socket is identified by its IP address, its port number, and its
    > protocol number. In the case of TCP, the socket is one end of a
    > connection whose other end is defined by *its* IP address and port
    > number. So, for the data to go anywhere at all IP has to know the local
    > address and port number *first*, i.e. it scans the table of sockets
    > somehow to find one with the target IP address/port/protocol no.


    Esmond,

    If it does it this processing all in one go based on a single match of
    ip address/port, then what's the point of having a layered protocol
    stack? i.e, the link layer checks if the mac address is correct for
    the current host, and if so passes the data upward to the IP module.
    The IP module assures that the packet is intended for the current host
    based on its IP address, and if so passes it up to the transport
    module - regardless of port. Then the transport module looks for a
    listening process on the destination port in its process/port table,
    and if it finds one, then it passes the data to that process - if not
    listening process is found, an ICMP error message is sent back to the
    originating host. Isn't this the fundamental flow of a packet up the
    tcp/ip protocol stack? If so, it seems to differ from the process you
    describe, which seems to describe a single process for matching
    ip/port.

    Regards,
    Sam90



    > specified in the incoming IP packet. Then, the data is passed to that
    > socket, and the local IP address (& port) of any socket can be retrieved
    > via the Sockets API.





    This is nothing to do with Java, it all happens at
    > the IP layer. See W R Stevens 'TCP/IP Illustrated' for details. The only
    > time Java comes into it is by mapping the Sockets API into methods of
    > the Socket/ServerSocket classes, e.g. Socket.getLocalXXX().
    >
    > EJP
    >
    > Sam wrote:
    > > Esmond Pitt <> wrote in message news:<W6FNc.19902$>...
    > >
    > >>Sam
    > >>
    > >>I don't really know what you mean by 'tracks multiple ports per IP',
    > >>which TCP certainly does otherwise nothing would work at all. Maybe you
    > >>mean 'multiple IP addresses per port'? in which case the answer is
    > >>certainly 'yes' as well, hence the ServerSocket constructor I referred
    > >>you to. The local IP address by which incoming data came in is not
    > >>reliable due to the 'weak end system model' described in the RFC, maybe
    > >>this is what you are referring to, but the IP address to which the
    > >>reading socket is bound is always available via Socket.getLocalAddress().
    > >>
    > >>EJP

    > >
    > >
    > > Esmond,
    > >
    > > My thinking was: whatever OS routine is responsible for delivering
    > > payload data to a listening application over a specific port doesn't
    > > need to know what IP address the data came over, it only needs to
    > > deliver it to the correct port. The IP address doesn't even exist at
    > > the transport layer. So to my mind the only the way the requirement
    > > could be achieved was to somehow set up separate ports with the same
    > > port number for each listening interface, which seemed unlikely.
    > >
    > > However, what I failed to account for is that Java Sockets speak with
    > > IP at some level, because for example they can specify the remote IP
    > > in the Socket class. So, from there it's not much of a jump to realize
    > > it probably has a way to understand the local IP address, as well.
    > >
    > > I'm still unclear as to the mechanics of it, though. I'm pretty sure
    > > that on Windows Jave uses JNI to interact with the WinSock API to
    > > handle it's network functionality. But, my real question is, what
    > > exactly is a "port" anyway, except a numeric label which has a
    > > constraint that it can't be re-used within a single IP address? In the
    > > end, it may be that it's simply a question of processes - the Winsock
    > > API or corresponding OS module probably tracks some internal table
    > > which matches a port to a specific interface, and as long the
    > > combination of the two is different from all other entries in its
    > > table, no problem. In the end, what I thought was "unlikely" is
    > > probably what actually occurs - the OS tracks a separate port for each
    > > interface, or at least has the capability of doing so. (DISCLAIMER:
    > > the preceding is pure speculation...)
    > >
    > > Regards,
    > > Sam90
     
    Sam, Jul 29, 2004
    #15
  16. Alexander N. Spitzer

    Esmond Pitt Guest

    Sam wrote:
    >
    > If it does it this processing all in one go based on a single match of
    > ip address/port,


    Sam

    If you want to know how TCP works please read the reference I mentioned
    before. I didn't say say anything about everything happening in one go,
    this is more guesswork on your part. Obviously the data is passed from
    the NIC to IP to TCP and obviously lots of processing happens on the
    way, but an IP socket is *defined* by its protocol number, an IP
    address, and a port number, and these socket attributes are available
    all the way up the stack and indeed to the application.

    EJP
     
    Esmond Pitt, Jul 30, 2004
    #16
  17. Alexander N. Spitzer

    Sam Guest

    Esmond Pitt <> wrote in message news:<>...
    > Sam wrote:
    > >
    > > If it does it this processing all in one go based on a single match of
    > > ip address/port,

    >
    > Sam
    >
    > If you want to know how TCP works please read the reference I mentioned
    > before. I didn't say say anything about everything happening in one go,
    > this is more guesswork on your part. Obviously the data is passed from
    > the NIC to IP to TCP and obviously lots of processing happens on the
    > way, but an IP socket is *defined* by its protocol number, an IP
    > address, and a port number, and these socket attributes are available
    > all the way up the stack and indeed to the application.
    >
    > EJP


    EJP,

    I'm not convinced what you've been saying is entirely accurate. For
    example, you previously mentioned that data doesn't go anywhere unless
    there is a socket available. You also state that socket attributes are
    available all the way up the stack.

    I've just reviewed pp. 19-21 of Steven's TCP Illustrated, Volume II.
    He describes the progress of a UDP packet up the protocol stack, from
    the hardware interrupt which launches the nic driver, to the passing
    of the data by the driver to the IP layer, which in turn passes it to
    the UDP input routine.

    The first mention of sockets is made in the description of the UDP
    input routine. It uses the port on the UDP header to locate a PCB
    Control block, and when it finds a match "This will be the PCB created
    by our call to socket, and the inp_socket member of this PCB points to
    the corresponding socket structure, allowing the received data to be
    received by the correct socket". My reading this has the data going
    as least as far as the UDP (transport) layer, and no socket available
    to the stack until then.

    This appears to contradict your assertion about the packets not going
    anywhere without a socket - it gets as far as the transport layer -
    and about the socket being available throughout the protocol stack -
    it's only looked up at the transport layer.

    The whole point of the layered architecture is to prevent one layer
    from having to contend with data that belongs in another layer, and
    that's been cited as one of the main reason for TCP/IP's great
    success.

    Regards,
    Sam90
     
    Sam, Jul 31, 2004
    #17
  18. Alexander N. Spitzer

    Tony Morris Guest

    This thread is somewhat difficult to follow, so I'll assume the question is
    the typical, "how do I have an RMI server bind to a specific network
    interface?"

    The answer is you use java.rmi.registry.LocateRegistry, create a
    RMIServerSocketFactory that is bound to a specific interface using
    java.net.NetworkInterface.

    If my assumption is incorrect, please ignore.

    --
    Tony Morris
    http://xdweb.net/~dibblego/
     
    Tony Morris, Jul 31, 2004
    #18
  19. Alexander N. Spitzer

    Esmond Pitt Guest

    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?

    This also means that TCP, UDP, ICMP &c do 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 *would* be infeasible is the
    implementation you seem to keep imagining where TCP can't access the IP
    header or the local IP address: otherwise the OP's situation wouldn't
    work, and it does; also Socket.getLocalAddress() == getsockname()
    couldn't work either.

    Anyway basta cosi.

    EJP
     
    Esmond Pitt, Aug 2, 2004
    #19
  20. Alexander N. Spitzer

    Esmond Pitt Guest

    Tony Morris wrote:

    > This thread is somewhat difficult to follow, so I'll assume the question is
    > the typical, "how do I have an RMI server bind to a specific network
    > interface?"
    >
    > The answer is you use java.rmi.registry.LocateRegistry, create a
    > RMIServerSocketFactory that is bound to a specific interface using
    > java.net.NetworkInterface.
    >
    > If my assumption is incorrect, please ignore.


    That works for the registry itself, but for specific RMI servers you
    also have to provide *them* with a ServerSocketFactory, probably the
    same one, and you have to use the appropriate IP address or interface
    name when binding them to the registry.
     
    Esmond Pitt, Aug 2, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    1
    Views:
    4,979
    Esmond Pitt
    Jul 28, 2005
  2. zxo102
    Replies:
    5
    Views:
    399
    zxo102
    Aug 15, 2006
  3. G
    Replies:
    2
    Views:
    512
    Tom Hawtin
    Jun 18, 2007
  4. Replies:
    1
    Views:
    669
    Toni Erdmann
    Mar 2, 2005
  5. Andreea
    Replies:
    0
    Views:
    540
    Andreea
    Apr 21, 2012
Loading...

Share This Page