Hi Johnny,

This sounds like a reasonable goal, and separating out cache lookup from connection establishment is a good idea. I've got a couple of comments to add to the record.

I'm not sure what you mean by a "lack of the forth (first lookup, parallel connect if non existent)." The parallel connect strategy performs exactly this behavior, but limited to multiple endpoints within a profile. This constraint was necessary to ensure that aggregate (or group) IORs are not inappropriately mixed.

Also, in tao/strategies there is yet another "Optimized Connect" strategy which aggregates all the endpoints from all the profiles for the cache lookup, then does a traditional sequencial connect attempt, but with a strategy-defined connection timeout.

And don't forget the IPv6 preferred/exclusive options adding yet another configuration dimension!

> I'm not sure what you mean by a "lack of the forth (first lookup, parallel
> connect if non existent)." The parallel connect strategy performs exactly this
> behavior, but limited to multiple endpoints within a profile. This constraint
> was necessary to ensure that aggregate (or group) IORs are not inappropriately
> mixed.

We did some testing and couldn't get this working, we had a server with 3 endpoints, the first two where not reachable from a specific client, the 3rd one was. The server has no clue which client is using which interface so can't filter them out. Each object reference passed to the client now has 2 not usable endpoints, it took windows 22 seconds to determine that the ip address wasn't usable, so it took each time 44 seconds of delay when the object reference was used. With parallel connect at least we did reduce this time, but we couldn't get tao so far that it first looked in the cache and then used parallel connect.

> Also, in tao/strategies there is yet another "Optimized Connect" strategy which
> aggregates all the endpoints from all the profiles for the cache lookup, then
> does a traditional sequencial connect attempt, but with a strategy-defined
> connection timeout.
> 
> And don't forget the IPv6 preferred/exclusive options adding yet another
> configuration dimension!

Yes, another set of dimensions would make this more interesting 

The parallel connect strategy requires -ORBUseSharedProfiles 1 to generate a profile with TAG_ALTERNATE_IIOP_ENDPOINT components. Otherwise parallel connect doesn't buy you anything. Historically, -ORBUseShareProfiles is defaulted to 0.

If you were using shared profiles, I wonder if there is a problem with windows and asynch connects? How did you generate your unreachable endpoints? I assume you used a -ORBEndpoint with some alias, but was that a bogus host name, or a bogus address?

There is a tests/Parallel_Connect_Strategy. Does that run for you?

> If you were using shared profiles, I wonder if there is a problem with windows
> and asynch connects? How did you generate your unreachable endpoints? I assume
> you used a -ORBEndpoint with some alias, but was that a bogus host name, or a
> bogus address?
> 
> There is a tests/Parallel_Connect_Strategy. Does that run for you?

I am not sure about which options we all tried, but one didn't work and after thinking about what we did I made this entry to store some refactoring ideas. The system has some interfaces that where on a different network then this specific client, by default we get all endpoints of all interfaces and the order was just a bad one 

Please try tests/Parallel_Connect_Strategy/run_test.pl. I just tried it on windows XP and got the expected results. This test runs several configuration combinations, the first few run fast the last couple take 20+ seconds to run.

I will try to do that next week, the trick seems to be having multiple endpoints, the first ones with ip addresses that don't get resolved. The server should create a stringified ior, the client then uses that, uses parallel connect and gets a connection, it invokes an operation which returns a different object reference which also contains the unreachable ip addresses, the orb then just should get the existing connection from the cache (for the 3rd valid endpoint) and not do a parallel connect. Independent whether it makes a connection or not, it will be fast, but it looked a waste of resources to try to make a parallel connect