One Ice invocation --> Two simultaneous tcp connections.

[mario]

Hello, I'm fighting with the last (I hope ;-) demand for the prototipe with Ice I'm working on.

I have the following hardware configuration:

- Two computers with a couple of network interface cards.
- Two network switches.
- Two independent wired physical networks.
- All four nics are configured with ip addresses at the same ip subnet.

                            +----------+
                      +-----| Switch A |-----+
    +------+ nicA1    |     +----------+     |    nicB1 +------+
    |      |----------+                      +----------|      |
    | PC A |                                            | PC B |
    |      |----------+                      +----------|      |
    +------+ nicA2    |     +----------+     |    nicB2 +------+
                      +-----| Switch B |-----+
                            +----------+

Now, what I need is to dispatch one request, *at the same time*, from pc A to pc B across switch A and switch B. This is one rpc call, at the application level, but two network connections to send the same request making use of the two networks. Of course, when the packets arrive to the destination only the first must be processed by the Ice server; the second packet (if it arrives) must be discarded.

The rationale for this is to accomplish the processing of an Ice request with the lowest delay. Until now, I built my proxies with two target endpoints (i.e: TestObject:tcp -h nicB1:tcp -h nicB2). The problem with this approach can be viewed with an example:

- The first invocation create a connection from nicA1 to nicB1.
____- Source nicA1 is selected by the ip routing table.
____- Target nicB1 is selected randomly by the Ice core.
- I unplug the cable of nicB1.
- A second invocation is delayed because the Ice runtime must close the former connection and
make a new one to nicB2. The configured timeout for the proxy is the delay.

The solution for that is to send the same invocation twice, each in different networks, and process in pc B only the first one.

To accomplish this (uncommon?) task, I'm thinking in build a new protocol plugin with the following characteristics:

- One Ice invocation must be transformed in two simultaneous tcp sendings.
- On receive, only the former dispatch must be processed. The second must be discarded.
- Being configured the two NICs in the same ip subnet, there's the needed of bind the socket
to a specific local ip address to be able to select the desired source NIC.
I can't configure the NICs in pairs in different ip subnets because I want to be able to
communicate from nicA1 to nicB1.
(I posted a topic about this a short while ago at http://www.zeroc.com/vbulletin/showthread.php?t=1065)

What do you think about this plan? I began to study the Ice sources but I don't discover yet if this is a task I can accomplish for my own. What's your expert advice?

Thanks in advance,
Mario

[marc]

What you are trying to achieve is usually done in the domain of lower-level IP routing protocols, and not at the level of a distributed objects platform.

Writing a plain transport plug-in for such special routing will be difficult, because at the transport level, information about individual requests is not available. A transport plug-in only sees opaque messages. This means that you would have to interpret (unmarshal) this overwise opaque data.

I'm afraid any meaningful advice regarding this subject is way out of the scope of the free support that we can provide here in this newsgroup. If you would like us to provide consulting services, please contact us at info@zeroc.com.

[bernard]

Hi Mario,

Just out of curiosity, why do you use the same ip subnet for all your interfaces?

I suspect the only way to get this to work properly is through some special configuration of your OS (to let it know that PC-A needs to use nicA1 to reach nicB1's IP and nicA2 to reach nicB2's IP); with two separate ip subnets, the default routing would just work -- sounds simpler and more robust.

In any case, for your prototype, I recommend you stay at the "application level" rather write a new transport plugin.
To send requests in parallel, you could use two separate proxies, each with a single endpoint (nicB1 or nicB2's address or name); for true parallelism, you also need to use 2 separate threads to send these requests (AMI or oneway are not good alternatives since they can block). Of course your servant will be responsible to discard duplicate requests.

Cheers,
Bernard

[mario]

Hi Bernard,

Just out of curiosity, why do you use the same ip subnet for all your interfaces?
I suspect the only way to get this to work properly is through some special configuration of your OS (to let it know that PC-A needs to use nicA1 to reach nicB1's IP and nicA2 to reach nicB2's IP); with two separate ip subnets, the default routing would just work -- sounds simpler and more robust.

All my interfaces use the same ip subnet because I need all possible ways I can achieve with this hardware configuration. What I want is to send the same request twice, making use of different ways:

    nicA1 ----+-----> nicB1
              |
              +-----> nicB2

              +-----> nicB1
              |
    nicA2 ----+-----> nicB2

For example:

    If all interfaces are up: nicA1 -> nicB1
                              nicA2 -> nicB2
    
    If nicA2 is down:         nicA1 -> nicB1
                              nicA1 -> nicB2
    
    If nicB1 is down:         nicA1 -> nicB2
                              nicA2 -> nicB2
    etc...

To accomplish that think I need all interfaces in the same ip subnet, be able to bind the local socket (in the client side) to the ip I want and don't let the OS make the routing.

In any case, for your prototype, I recommend you stay at the "application level" rather write a new transport plugin.

Yes, after study hard the Ice sources (proxy, delegate, outgoing, connection, transceiver) and the comments from Marc, I realise that the transport plugin isn't a good idea. I think as well stay at the "application level" is the best approach.

Thanks for your comments and best regards,
Mario