Archived

This forum has been archived. Please start a new discussion on GitHub.

Problem with Endpoints

When I use

_ic->createObjectAdapterWithEndpoints

The Socket of the Endpoint is only bound to the local loopback device, making it impossible to call the Application from another machine?

What do I do wrong?

Thanx in advance

Gerald

Comments

  • Most likely your system is not configured properly.

    What does "hostname" return? And if you do an "nslookup <name>", with <name> being the result of "hostname", what do you get?
  • The IP-Adress (not loopback) as expected.

    if I omit "-h hostname" and only specify "-p port" in the Endpointdefinition it only binds to the loopback. Same happens if I use "-h hostname".

    I have to explicitly use "-h IP-Adress" to be able to use my application from a remote machine

    Thanx for your help
  • Then your hostname refers to your loopback address. Check your /etc/hosts file, or your DNS configuration. With a properly configured system, it is not necessary to explicitly set the IP address.

    Ice does the equivalent of looking up the hostname with "hostname", and then using "nslookup" (gethostbyname) with that name to find the IP address.
  • Just had a talk with our Admin...

    You were right, problem with SuseConfig... :(

    Thanx for your help

    Gerald
  • This might be a general issue with many linux configs; I know Red Hat's installer sticks the machine hostname as an alias for 127.0.0.1 in /etc/hosts as well. Any reason not to use INADDR_ANY for binding when no explicit hostnames are given?
  • We don't use INADDR_ANY, because this would really imply multiple endpoints. This leads to problem with detecting if for example an Ice object is collocated.
  • Originally posted by vukicevic
    This might be a general issue with many linux configs; I know Red Hat's installer sticks the machine hostname as an alias for 127.0.0.1 in /etc/hosts as well. Any reason not to use INADDR_ANY for binding when no explicit hostnames are given?

    The latest installer doesn't do that, and I don't think RH9 did either. Many things, in fact, will fail miserably if you have the machine's hostname pointed at 127.0.0.1, I believe. (Like GNOME, for starters.)

    [Edit: apparently I'm a liar, or on crack. Pls disregard.]

    Mike
  • Originally posted by marc
    We don't use INADDR_ANY, because this would really imply multiple endpoints. This leads to problem with detecting if for example an Ice object is collocated.

    Why? From application point of view, socket bound to INADDR_ANY and one bound to some specific address have no any visible difference beside ip addresses.
    On other hands, it is not a problem to get real local address of any established connection.
  • Originally posted by vukicevic
    This might be a general issue with many linux configs; I know Red Hat's installer sticks the machine hostname as an alias for 127.0.0.1 in /etc/hosts as well. Any reason not to use INADDR_ANY for binding when no explicit hostnames are given?

    It is not an issue as for host itself 127.0.0.1 is "the shortest and most reliable way". Imagine host which gets its ip address dynamically from, for instance, dhcp server. What ip address should one put in /etc/hosts in that case if not 127.0.0.1?
  • Let's assume you have a host with three interfaces, plus loopback, let's say host1, host2, host3, and localhost.

    Now you configure an OA with INADDR_ANY, meaning that it will accept requests from all these. But if you create a proxy to send to a client, which endpoints should it contain?

    I know there are some ways to look up all interfaces, but the code for this is pretty awkward and non-portable. The only portable way I can think of would be to use hostname() to look up the hostname, and then use gethostbyname() to find the IP address for this hostname. However, this would then only be one single IP address, not multiple.

    There is also a similar problem with finding out whether a proxy points to a collocated object. If you have a host in the proxy, you can compare them with all endpoints used by the object adapter, one by one. However, this doesn't work for INADDR_ANY, except if you would have a method that could iterate all interfaces covered by INADDR_ANY.

    So the problem boils down to, how can I get all interfaces for INADDR_ANY in a manner that doesn't force me to write special code for every supported platform? Perhaps there is a method I don't know of. If so, I would be happy to add it to Ice :)
  • Originally posted by marc
    Let's assume you have a host with three interfaces, plus loopback, let's say host1, host2, host3, and localhost.

    Now you configure an OA with INADDR_ANY, meaning that it will accept requests from all these. But if you create a proxy to send to a client, which endpoints should it contain?

    Client must establish connection in order to make request, right. You use client connection to determine to which ip address it connected and use that addres to construct proxy.
  • Originally posted by alexander
    Client must establish connection in order to make request, right. You use client connection to determine to which ip address it connected and use that addres to construct proxy.

    Sorry, I'm afraid I don't understand what you mean.

    The object adapter creates a proxy. Which endpoints with which IP addresses does it put into the proxy, if you use INADDR_ANY for the object adapter?

    Also, given a proxy, how can I find out if the proxy is local with respect to an object adapter, if the object adapter uses IPADDR_ANY?

    For both problems, I need a method to get all IP addresses of the server.
  • Originally posted by marc
    Also, given a proxy, how can I find out if the proxy is local with respect to an object adapter, if the object adapter uses IPADDR_ANY?
    How can you find that out if I have multiple interfaces on a given machine? A proxy to endpoint:127.0.0.1 is local (but possibly not in the same address space; I'm not sure if that's the sort of locality you're looking for), but a proxy to any number of other-addressed endpoints might also be. (v4/v6 issues alone are enough to make me nervous.)

    Is this just an issue of an optimization that's missed? If so, I think that you either need to tell people to use one address for all their endpoints if they can, or provide a way for administrators to configure a list of addresses that are "synonyms" for the local machine.

    If it's an issue of correctness, rather than just avoiding marshalling overhead, then I don't have any better suggestions, other than making the list of synonyms mandatory perhaps, to draw the administrator's attention more effectively to the issue.

    I guess one alternative is to use the sort of host-identifier present in class 1 (I think) UUIDs, and exchange that when connecting to a new endpoint. If you get your own identifier, that endpoint's proxies are local. (For address-space locality, you'd need to generate a UUID per invocation of the Ice runtime or something, I suppose.)

    Mike
  • Hmm, I think the other problem is more difficult to solve, as marc said.. for an adapter bound to INADDR_ANY, you have no way of creating a proxy identifier. I wasn't thinking of this when I brought up INADDR_ANY originally.

    Maybe emit a warning if it resolves to 127.0.0.1, or just require -h on endpoints? Having the same code bind to 127.0.0.1 on one machine and bind to a possibly public IP address on a different one (or even bind to a different address on the same machine, if the nameserver changes) could be confusing.
  • Originally posted by vukicevic
    Hmm, I think the other problem is more difficult to solve, as marc said.. for an adapter bound to INADDR_ANY, you have no way of creating a proxy identifier. I wasn't thinking of this when I brought up INADDR_ANY originally.
    Hrm, I suppose that's true. I should ask you about these things before I make a fool of myself on the forums. :o

    Time to print the chapter on the core runtime and re-read it, I think.

    Mike
  • Originally posted by marc
    Sorry, I'm afraid I don't understand what you mean.

    The object adapter creates a proxy. Which endpoints with which IP addresses does it put into the proxy, if you use INADDR_ANY for the object adapter?

    Also, given a proxy, how can I find out if the proxy is local with respect to an object adapter, if the object adapter uses IPADDR_ANY?

    For both problems, I need a method to get all IP addresses of the server.

    Well, create proxy with INADDR_ANY as its ip address. When proxy is about to be transferred to some client, ajust proxy address to one used by _this_ client to connect to the server.
    In that case, if proxy has INADDR_ANY as its ip address then it wasn't transferred and it's a local proxy. If proxy received from remote host, its ip address has alredy changed to some specific address and it is a remote proxy.
  • Originally posted by alexander
    Well, create proxy with INADDR_ANY as its ip address. When proxy is about to be transferred to some client, ajust proxy address to one used by _this_ client to connect to the server.
    In that case, if proxy has INADDR_ANY as its ip address then it wasn't transferred and it's a local proxy. If proxy received from remote host, its ip address has alredy changed to some specific address and it is a remote proxy.

    Sorry, but this does not work.

    There is no way to predict over which path a proxy will eventually make it to a client. It could be direct as the result of an operation call, it could be indirect over another service, and it could even be indirect using a lookup service, and then back to a client collocated to the server. You could even write the proxy to a database in string-form, and then read it back from the database from some other Ice client or server.

    The point is, you cannot modify any endpoint information in a proxy, because you don't know how, when, and by whom the proxy will be used.
  • You can associate all host addresses with endpoint so clients can choose one.
    List of all addresses can be obtained by the following code (JDK 1.4+):

    ArrayList l = new ArrayList();
    Enumeration i = NetworkInterface.getNetworkInterfaces();
    while (i.hasMoreElements()) {
    Enumeration a = (Enumeration) ((NetworkInterface)i.nextElement()).getInetAddresses();
    while (a.hasMoreElements())
    InetAddress addr = (InetAddress) a.nextElement();
    if (!addr.isLoopbackAddress()) l.add(addr);
    }
  • Right, that's what I was talking about, I need a method to get all interfaces. For Java, there is some portable code, but I know of none for C++. If anyone has such code, please give it to me :)
  • Originally posted by marc
    Sorry, but this does not work.

    There is no way to predict over which path a proxy will eventually make it to a client. It could be direct as the result of an operation call, it could be indirect over another service, and it could even be indirect using a lookup service, and then back to a client collocated to the server. You could even write the proxy to a database in string-form, and then read it back from the database from some other Ice client or server.

    The point is, you cannot modify any endpoint information in a proxy, because you don't know how, when, and by whom the proxy will be used.

    I think, the point is that endpiont either was or wasn't originally requested from server bound to INADDR_ANY no matter how long and complex the way. If it was transferred it was possible do determine server ip address from which endpoint was gotten.

    If endpoing was gotten by client directly from server it was possible to determine server ip address.
    If it was gooten from lookup service, it was possible to determine ip address at the time of registration.
    At the first endpoint transfer through a network endpoint gets server address and no matter where it goes next, directly to client, lookup service database, client database, whatever.
    Locally created string database of endpoints which have no associated host has no relation to server bound to INADDR_ANY but rather a client misconfiguration. But if endpoing originally requested from the server it has to be associated to some host.
  • I think this discussion is now exhausted ;)

    Feel free to modify Ice if you don't believe my arguments.
  • How can't I belive your arguments ;)

    I guess, I didn't explain my vision of the problem. And you're right that best way to explain is to provide working code. I'll try to do that.

    And thanks for your answers
  • marc wrote:
    Right, that's what I was talking about, I need a method to get all interfaces. For Java, there is some portable code, but I know of none for C++. If anyone has such code, please give it to me :)

    Hello marc, there's a multiplatform framework called ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) that have this functionality.

    In stable build (5.4.1): ACE_Sock_Connect.get_ip_interfaces()
    http://www.dre.vanderbilt.edu/Doxygen/Stable/ace/classACE__Sock__Connect.html

    In development build: ACE_Multihomed_INET_Addr class
    http://www.dre.vanderbilt.edu/Doxygen/Current/html/ace/classACE__Multihomed__INET__Addr.html

    I hope this can help you. :-)

    Regards,
    Mario