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

[ https://issues.jboss.org/browse/JGRP-2080?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2080 at 9/1/16 5:48 AM: -------------------------------------------------------- Hmm... we could also start from the other end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}. The reason we abandoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}). Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness. The advantages of this over encoding the IP address in a UUID are: * To extract an {{IpAddress}} from a UUID when sending a message, we'd need to create a new {{IpAddress}} instance for every message (high allocation rate). When adding some randomness to {{IpAddress}}, we can directly use those * Encoding an IPv4 address in a UUID takes 6 bytes (4 for the address and 2 for the port), so we have 10 bytes left for randomness in the UUID. For IPv6, the required size is 18 bytes, so we'd need to make the UUID larger to have enough randomness. With the extension scheme, {{IpAddress}} would always contain the same amount of randomness. * No hashmap lookup from address to physical address would have to be done Disadvantages: * Addresses get bigger, both on the wire and in memory was (Author: belaban): Hmm... we could also start from the other end and add 'randomness' to an {{IpAddress}}; rather than encoding the IP address and port in the UUID, we could add a 16 byte (or smaller) UUID to {{IpAddress}}. The reason we abandoned IpAddress a long time ago is that - if the port was fixed - we could run into _reincarnation issues_: a member with address {{192.168.1.3:5000}} crashing and immediately restarting would have the same address {{192.168.1.3:5000}} but still have state from old members (e.g. in {{NAKACK2}}). Since the combination of IP address and port is pretty unique, we'd only have to add a small amount of randomness (perhaps even configurable) to an {{IpAddress}}. Currently, {{IpAddress}} uses 20 bytes in memory (JOL) and loses 4 due to mapping, so we could use 12 bytes for randomness. The advantages of this over encoding the IP address in a UUID are: * To extract an {{IpAddress}} from a UUID when sending a message, we'd need to create a new {{IpAddress}} instance for every message (high allocation rate). When adding some randomness to {{IpAddress}}, we can directly use those * Encoding an IPv4 address in a UUID takes 6 bytes (4 for the address and 2 for the port), so we have 10 bytes left for randomness in the UUID. For IPv6, the required size is 18 bytes, so we'd need to make the UUID larger to have enough randomness. With the extension scheme, {{IpAddress}} would always contain the same amount of randomness. -- This message was sent by Atlassian JIRA (v6.4.11#64026)