[
http://jira.jboss.com/jira/browse/JGRP-129?page=comments#action_12370883 ]
Bela Ban commented on JGRP-129:
-------------------------------
I'm not sure I want to introduce logical addresses. This is regarding
JGRP-129 (logical addresses) and JGRP-130 (problems with reincarnation).
JGRP-130 is about a member that leaves and rejoins *under the same IP address and port
(using bind/start_port)* before failure detection kicks it out. I implemented a fix for
this, which won't allow a member into the group that's already in the group. In
the above case, with A and B, B would have to wait until the cluster is {A} before it can
rejoin.
JGRP-129 is about providing a logical address (possibly host + system time in ms (plus 1
for same system times) for a member, which can be mapped to a physical host/port combo. It
would add 4 bytes/address, and I don't see the benefits of this.
The original motivation was that when a member gets shunned, it rejoins under a new
identity. Sacha didn't like this and therefore added 'logical addresses' in
JBoss, which creates a logical address for a member. So when that member is shunned and
rejoins under a *new* JGroups address, it would still keep the *old* JBoss logical
address.
I tend to leave it this way, as I don't want to add something which
- adds clutter (Host:26634425614 looks less readable than Host:4536)
- adds 4 bytes / IpAddress
- has some additional lookup in the transport to find the real physical address to which
the logical address maps
- needs some ARP-like traffic for establishing local tables which map logical to physical
addresses
What do people think ?
Logical addresses
-----------------
Key: JGRP-129
URL:
http://jira.jboss.com/jira/browse/JGRP-129
Project: JGroups
Issue Type: Feature Request
Affects Versions: 2.2.9
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6
The address chosen by each node is essentially the IP address and port of the receiver
socket. However, for the following reasons, this is not good enough:
- The node is shunned (excluded) and re-joins after leaving. We'd like to have the
same logical address, although the physical address changed. This is already done in JBoss
code, should be available in JGroups proper
- NIC failover: a NIC goes down, we want to continue sending/receiving on a different
NIC
- The sender sends on all available NICs (send_on_all_interfaces="true"). This
means that -if we take the receiver's datagram packet's address to be the identity
of the sender - we get N different identities; 1 for each interface the message is sent
on
- Network Address Translation: the sender's address might get changed by the NAT
DESIGN:
- A logical address is picked, either by JGroups, or set by a user on channel creation.
The lifetime of this address is the lifetime of the process in which the channel is
created, or until channel.close() or disconnect() is called.
- Each member as a small cache, in which it associates the logical addresses for messages
received with the sender's address. When a message is to be sent to a logical address
(unicast message), the corresponding physical address is looked up from the cache. Note
that there maybe multiple physical addresses if the same message was sent on different
interfaces (send_on_all_interfaces="true").
- The logical addresses must be picked such that they cannot be reused after
disconnect()/close().
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira