dual network

aleksey.m.taleksey.m.t Member Aleksey TanyukhinOrganization: NITAProject: air traffic control systems, flight simulation
I'm developing data exchange system based on ICE via multicast. I wanna use it in dual network to provide extra stability.
On server side I create 2 object adapters with endpoints relating to addresses of different network interfaces. It looks like so:
createObjectAdapterWithEndpoints( "channel01_adapter", "udp -h 234.0.1.0 -p 13004 --interface 192.168.1.2" );
createObjectAdapterWithEndpoints( "channel011_adapter", "udp -h 234.0.1.0 -p 13004 --interface 192.168.2.2" );

Then I create a single servant(1. with the same id; 2.with different ids) which is added to both adapters.
On the client side I get 2 proxies:
stringToProxy( "channel01:udp -h 234.0.1.0 -p 13000 --interface 192.168.1.2" );
stringToProxy( "channel01:udp -h 234.0.1.0 -p 13000 --interface 192.168.2.2" );

In the message there is a counter which helps to discard duplicated messages. I run client and server on the same host and everything looks fine - server receives messages on both interfaces. But when I drop down one of the connections server stops receiving messages on both interfaces. After caught exception WSAEADDRNOTAVAIL on the client side server begins to get messages again. After it it's possible to drop and restore connections - server will not stop. So this problem occurs only for the first time of dropping the connection.
Why it is so? What I'm doing wrong? And maybe there are any other ways to
obtain what I want?
Another strange thing that I saw is that when I use only single proxy with "--interface --interface 192.168.1.2" on the client side and single servant with "--interface --interface 192.168.2.2" on the server side it receives messages! Maybe problem is here, in my local networks configuration...
Thanks!

My configuration:

Ice version: Ice 3.4.1
Compiler version: Visual Studio 2010
Operating system: Windows XP, SP3

Comments

  • aleksey.m.taleksey.m.t Member Aleksey TanyukhinOrganization: NITAProject: air traffic control systems, flight simulation
    Addition

    I'm still trying to resolve this problem and found another strange thing that can possibly help.
    I have 2 network interfaces: 192.168.2.77 and 192.168.22.77. In this test I create an object adapter with "--interface 192.168.2.77". On client side I create proxy with the same interface. Server receives nothing. Ice.Trace.Network for the server is:

    server.exe: Network: starting to send udp packets
    local address = 192.168.22.77:2877
    remote address = 233.0.1.0:13000


    for client:

    client.exe: Network: starting to receive udp packets
    local address = 0.0.0.0:13000
    multicast address = 233.0.1.0:13000
    local interfaces: 192.168.2.77, 192.168.22.77, 127.0.0.1


    Now I unplug network cable for 192.168.22.77 and run this test again. Server receives messages! And Ice.Trace.Network for the server became:

    server.exe: Network: starting to send udp packets
    local address = 192.168.2.77:2890
    remote address = 233.0.1.0:13000


    So the problem is that when server's "--interface" and client's "local address" are mismatched no packages are delivered to server. It seems to me that problem shown in my first post is pointed from this.
    How can I resolve it?
  • aleksey.m.taleksey.m.t Member Aleksey TanyukhinOrganization: NITAProject: air traffic control systems, flight simulation
    Problem resolved!

    Here is a short description of the problem:
    No matter what existing network interface for "--interface" parameter you select. The default interface will be returned for proxy. So if your default interface is "192.168.1.1" and you want to send packages via "192.168.2.2" they will be never delivered.
    Solution: in command window type "route -p ADD 233.0.1.0 192.168.1.1" for the first network interface and "route -p ADD 234.0.1.0 192.168.1.2" for the second.
    Now you can create object adapters "-h 233.0.1.0 -p 13000 --interface 192.168.1.1" and "-h 234.0.1.0 -p 13000 --interface 192.168.1.2" on the server side and create appropriate proxies on the client one.
    P.S. The limitation is that you need to use 2 multicast groups. In winsock it can be easily done for 1 group without adding entries to routing table, so I hope that in future releases it will be implemented.
  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff
    Hi,

    I'm glad you figured it out.

    It sounds like the UDP packets are sent with the wrong source address in the client even though you do specify --interface, we will look into this for a future release.

    Cheers,
    Benoit.
  • aleksey.m.taleksey.m.t Member Aleksey TanyukhinOrganization: NITAProject: air traffic control systems, flight simulation
    Hi,

    As I saw in debug getaddrinfo returns default network interface for the given multicast address if routing table does't contains a route for it. And later this interface is used for setsockopt(.., IP_MULTICAST_IF, ..) It seems to me that it is the point, which causes incorrect behaviour.
  • jwarnerjwarner Member John WarnerOrganization: JBRProject: C# - C++ interprocess communication
    Can you specify the network adapter for TCP?

    From reading this thread, I see there is an issue specifying which local network adapter to bind to.
    In the latest version, am I able to specify which network adapter to bind to yet, or is this still an issue?

    Thanks
    benoit wrote: »
    Hi,

    I'm glad you figured it out.

    It sounds like the UDP packets are sent with the wrong source address in the client even though you do specify --interface, we will look into this for a future release.

    Cheers,
    Benoit.
Sign In or Register to comment.