[jboss-jira] [JBoss JIRA] (JGRP-2080) New Address which contains IP address and port

[Neal Dillman (JIRA)]

    [ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272547#comment-13272547 ] 

Neal Dillman commented on JGRP-2080:
------------------------------------

These changes can and probably should affect various parts of the system.  We are doing what we can in our stack to minimize additional discovery traffic, but there is only so much that can be done without major overhaul (ie: 4.0).  We did implement a new version of PING called LESS_PING that extends PING as we no longer need to have discovery run other than initial_discovery.  It might also be good to get discovery our of MERGE[N], as that appears to be duplication (with PING/Discovery) and should not be needed for Merger.  

> New Address which contains IP address and port
> ----------------------------------------------
>
>                 Key: JGRP-2080
>                 URL: https://issues.jboss.org/browse/JGRP-2080
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0
>
>
> Currently, UUIDs are mapped to IpAddresses (InetAddress and port). The mappings are maintained in logical_address_cache in TP and populated via the discovery protocol.
> If we encoded the IP address and port (6 bytes in IPv4, 18 bytes in IPv6) directly into the UUID, we would not have to maintain this cache anymore. At least not for IpAddresses, but still for UUID/logical_name mappings.
> An {{IPv4UUID}} (credits to Neal Dillman) would look like this:
> * 4 bytes: IPv4 address
> * 2 bytes: port
> * 12 bytes: random data (rest of the UUID)
> When joining a cluster, the joiner would only need to discover the address of the coordinator and send a JOIN-REQ to it. The JOIN-RSP would contain the view, which contains all members, so the joiner has all addresses. Plus, the coord would also send a VIEW-CHANGE to all existing members, so they have the address of the new member, too.
> When sending a unicast, the transport could simply extract the IpAddress from the first 6 bytes of the IPv4UUID to know the destination address. For multicasts, UDP is not an issue, and TCP would simply iterate over the current view and send the message to each member separately.
> An IPv6UUID would need more than 16 bytes as it already needs 18 bytes for the address and the port. We might add another 6 bytes for uniqueness, to have a nice padding at 24 bytes.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)