Re: [jgroups-dev] TreeMesh progress and questions

I have skimmed this, but will need to look at it in more detail later.  
I just wanted to ask a few small questions, and make sure I understand 
you correctly:

Bela Ban wrote:
>
>
> Mike Jensen wrote:
>> I am casting almost all addresses now to UUID's for safety (exceptions
>> include things like FIND_INITIAL_MBRS). And things seem to be working
>> much better now.
>
> I hope this is guarded by an instanceof check; should we ever decide 
> to replace UUIDs with something else, your code will break.
>
I have actually been thinking that I may stop doing this.  I would like 
your input....

The question is, are using these as UUID's getting me any benefit.  
After much consideration, I have decided that the address in this tree 
mesh don't need to span data centers.  Instead I should put that 
functionality in a different protocol (probably something based off 
relay, but I don't think it can be relay because I actually want 
multiple relay nodes to exist and function, so there are duplicate 
connections between data centers.  The primary reason for this is to 
ensure at least one connection exists, while still not having a 
guaranteed view....So is there any value in making these casts or should 
I just store it as an Address?
>> But I have a weird situation in connecting I am not sure how to 
>> solve. Basically the situation is like this:
>>
>> 1) We get an up event of MeshHandshakeHeader from a node wishing to 
>> establish a connection to us
>> 2) We read the information they provided, all is good, and we decide to
>> accept the connection. So we then try to reply with our own information
>> for the connecting node.
>> 3) In pseudo code it looks like this:
>>
>> if (hdr instanceof MeshHandshakeHeader) {
>> newConnectionAttempt((String)msg.getObject(), (UUID)msg.getSrc(), 
>> <boolean::IsResponse>);
>> }
>
>
>
>> newConnectionAttempt(String data, UUID source, boolean isResponse) {
>> // parse data
>> // check if we want to keep this connection
>> if (keepConnection && !isResponse) {
>> // send response
>> Message msg = new Message(source, local_addr,
>> createHandshakeData(conType));
>> msg.putHeaderIfAbsent(getID(), new MeshHandshakeHeader(true));
>> down_prot.down(new Event(Event.MSG, msg));
>> }
>> }
>>
>> The issue is that even though I am using the UUID that was the source of
>> the incoming connection request, when I try to send using this UUID as
>> the destination I get the following:
>>
>> WARNING: <local hostname>: no physical address for <UUID of remote 
>> node>, dropping message
>
> Aha, I think I know what the issue is !
>
> As part of the discovery process, a joining node sends its physical 
> address and logical name (if set) along with the discovery request. 
> The discovery response(s) also contain physical address information 
> about their senders.
>
> However, if A gets a connection request from B, A might not have any 
> idea of the physical address of B, because B was not involved in the 
> discovery address.
I don't understand why this is.  We have a TCP connection directly to 
this nodes socket, why can't we easily determine the address without 
having more back & forth communication?  Or am I misunderstanding?
>
> There are 2 ways of correcting this issue:
>
> #1 When B sends its connection request to A, it also includes physical 
> address information. When A receives the request, it'll add B's 
> information to its local cache. Take a look at how this is done in 
> Discovery.
If we do that can we just use this address for the duration of our 
communication with this node?  How can I be sure I am getting the 
physical address and not just another UUID?
>
> #2 (In addition or instead of #1) When A wants to send a request to B, 
> but doesn't have B's information (e.g. physical address), it sends a 
> GET_PHYSICAL_ADDRESS event up the stack. The default is to run the 
> discovery process again (this event is caught and processed by 
> Discovery). But you could have a protocol, which catches this event 
> and fetches the physical address, too.
>
>
> I definitely think #1 should fix the issue, and I would actually not 
> implement #2 here, as it might prove problematic to fetch the physical 
> address, as your mesh doesn't have a 'broadcast' mode. Or maybe you 
> could ask the parents of the connecting node for physical node 
> information ?
>
>> Why would it be unable to look up the UUID of the source of a message we
>> just received? What ends up happening is that the connection attempt
>> ends up timing out, since the response was never received. After the
>> connection times out, the node will try to establish another
>> connection.
>
> To the same node it tried to connect before ?
>
>> Then on the second try it ALWAYS works, it works if it is
>> connecting to the same node, or a different node. Why would it always
>> work on the second try but not the first when the code paths are the 
>> same?
>
> It should fail the 2nd time, too, unless the discovery mechanism for 
> some reason suddenly has B's physical address. You can dump A's 
> physical address cache to see if this is true.
>
I will try dumping the cache, but I am positive it always works on the 
second try.
>> As for having another demo/phone call. That sounds good, I am always
>> willing to talk and explain where I am. I just am trying to be
>> sensitive to your time. Now that I am making progress again, I don't
>> feel that there is an urgent need for this. But maybe we will want to
>> do this later this week (like maybe Thursday morning for me).
>
> OK. Just ping me on #jgroups. Note that I'll be here next week, then 
> I'm gone for 2 weeks.
>
Sounds good.  I will make sure to get on there in this next week.  I 
will try to give you some forewarning though (once I look at my schedule).

Tomorrow I will look at this email more thoroughly, I just thought I 
would get a reply in now with a few of the basic questions.  Thanks for 
your time, it has been a pleasure to work on this with your help!

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Javagroups-development mailing list