Connection delay for service endpoins in IcGridRegistry with a multihomed network interface

aiksonaikson Aikson VirtanenOrganization: A+WProject: Designing a SOA ArchitectureMember

Hello,

on some of our servers we configured a second IP on the normal eth0 interface. A so called multihoming/multihome.
In our example there is one IP for the LAN (10.13.0.67) and one for a RS232-IP-Bridge (192.168.1.67).

We did not configure any explicit endpoints in our adapters (just plain default or tcp), so the registry is answering calls for the services with two possible endpoints.
endpoints = tcp -h 10.13.0.67 -p 65230 -t 60000:tcp -h 192.168.1.67 -p 65230 -t 60000
After receiving a ObjectPrx from the registry query and try to cast it (checkedCast) there is a 20 seconds delay in establishing the connection to the LAN endpoint.
2018-03-21 14:33:15.563 | "'retrieved endpoints from locator,...
2018-06-21 14:33:36.583 | "'established tcp connection …

Is there a possibility to Wildcard the LAN IP address so only this one would be used as endpoint address, without configuring all of our services with the correct IP from the server? Or what is possible to causing the delay?

Best Regards
Aikson

Best Answer

  • benoitbenoit Rennes, FranceBenoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Accepted Answer

    Hi Aikson,

    I'm afraid it's not easily possible right now to filter out some IP addresses.

    The easiest to not run into this hang would be to configure explicitly the IP address in the object adapter endpoint with the -h option. Note that you can also provide a name that resolves to the IP address. Can't you easily provide this through the XML deployment descriptor of the server? I understand this would make your configuration slightly more complicated.

    Another option would be for you to do the filtering in the server implementation. For example, after creating the object adapter in the server and before activating it, you could add the following code:

    // C#
    var adapter = communicator.createObjectAdapter(...);
    var endpoints = adapter.getPublishedEndpoints();
    var valid = new List<Ice.Endpoint>();
    foreach(var endpoint in endpoints)
    {
        if(endpoint.getInfo() is Ice.TCPEndpointInfo)
        {
            var tcpEndpointInfo = (Ice.TCPEndpointInfo)endpoint.getInfo();
            if(tcpEndpointInfo.host.StartsWith("192.168."))
            {
                valid.Add(endpoint);
            }
        }
    }
    adapter.setPublishedEndpoints(valid.ToArray());
    

    Note that this requires to run the IceGrid node with an additional property to allow the setPublishedEndpoints call to work: IceGrid.Node.AllowEndpointsOverride=1.

    Let us know if you need additional information on this!

    Cheers,
    Benoit.

Answers

  • benoitbenoit Rennes, FranceBenoit FoucherOrganization: ZeroC, Inc.Project: IceAdministrators, ZeroC Staff ZeroC Staff
    Accepted Answer

    Hi Aikson,

    I'm afraid it's not easily possible right now to filter out some IP addresses.

    The easiest to not run into this hang would be to configure explicitly the IP address in the object adapter endpoint with the -h option. Note that you can also provide a name that resolves to the IP address. Can't you easily provide this through the XML deployment descriptor of the server? I understand this would make your configuration slightly more complicated.

    Another option would be for you to do the filtering in the server implementation. For example, after creating the object adapter in the server and before activating it, you could add the following code:

    // C#
    var adapter = communicator.createObjectAdapter(...);
    var endpoints = adapter.getPublishedEndpoints();
    var valid = new List<Ice.Endpoint>();
    foreach(var endpoint in endpoints)
    {
        if(endpoint.getInfo() is Ice.TCPEndpointInfo)
        {
            var tcpEndpointInfo = (Ice.TCPEndpointInfo)endpoint.getInfo();
            if(tcpEndpointInfo.host.StartsWith("192.168."))
            {
                valid.Add(endpoint);
            }
        }
    }
    adapter.setPublishedEndpoints(valid.ToArray());
    

    Note that this requires to run the IceGrid node with an additional property to allow the setPublishedEndpoints call to work: IceGrid.Node.AllowEndpointsOverride=1.

    Let us know if you need additional information on this!

    Cheers,
    Benoit.

  • aiksonaikson Aikson VirtanenOrganization: A+WProject: Designing a SOA ArchitectureMember

    Hi Benoit,

    thanks for your answer. Yes it would be possible to specify the hostname, but I'm must check if the hostname not resolves both IP addresses for the DNS request.
    I think I will try to implement your solution and establish a IP-Range "blacklist" for our servers in the registry. It fits for this kind of problem and sometime in bigger companies there are several "admin" network, which could be excluded also.

    Best Regards
    Aikson

  • aiksonaikson Aikson VirtanenOrganization: A+WProject: Designing a SOA ArchitectureMember

    Hi Benoit,

    I was just trying to implement your solution in our code, but could it be, that the
    adapter.setPublishedEndpoints(valid.ToArray());
    functionality is a new one? We are still on 3.6.2 and it seems, the adapter has no such function.

    Would be a good reason to update to 3.7. Is it possible to mix 3.6 and 3.7 services in one Registry?

    Best Regards,
    Aikson

  • benoitbenoit Rennes, FranceBenoit FoucherOrganization: ZeroC, Inc.Project: IceAdministrators, ZeroC Staff ZeroC Staff

    Hi,

    Yes, setPublishedEndpoints was added in Ice 3.7.1. The IceGrid registry can indeed handle fine a mix of 3.6 and 3.7 servers/services.

    Cheers,
    Benoit.

  • aiksonaikson Aikson VirtanenOrganization: A+WProject: Designing a SOA ArchitectureMember

    Hi,

    one other question from our C++ server guys.
    With version 3.7.1, will we be able to compile a Visual Studio project including Ice

    #include <Ice/Ice.h>;
    #include <IceGrid/IceGrid.h>;
    #include <IceStorm/IceStorm.h>;
    #include <IceUtil/IceUtil.h>;
    etc.

    with the /std:c++17 flag using the new C++11 mapping or could this fail because of the use of removed functions like binary_function?

    Cheers
    Aikson

  • benoitbenoit Rennes, FranceBenoit FoucherOrganization: ZeroC, Inc.Project: IceAdministrators, ZeroC Staff ZeroC Staff

    Hi Aikson,

    It will indeed be a problem with Ice 3.7.1. We committed a fix recently for this that will be included in the next Ice minor version, see https://github.com/zeroc-ice/ice/commit/8cddd264e57ab89fc4c6952b2b390457a4bfbedf

    Cheers,
    Benoit.

Sign In or Register to comment.