[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2098 at 9/22/16 1:47 AM: --------------------------------------------------------- Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q. However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*! The naming cache would have to be populated via each member sending its name to a joiner, or the joiner fetching the 'state' from the coordinator. Since {{NAMING}} would sit below the discovery protocol, it is not reliable, so this would have to be done multiple times, or we'd have to use some homegrown reliability by e.g. resending the name until it has been acked yada yada yada... Not nice... was (Author: belaban): Hmm, a separate {{NAMING}} protocol might be difficult to write... When a member P joins, it runs the discovery protocol to (1) find the coordinator and (2) populate its (name and address mapping) caches. Coordinator Q can log the logical name of P when receiving a JOIN(P) request, as the previous discovery phase made the logical name of P known to Q. However, with a separate {{NAMING}} protocol, the logical name of P would somehow have to be shipped to Q separately. Piggy-backing on the discovery protocol entails {{NAMING}} having to intercept all messages and piggybacking on {{GET_MBRS_REQ}} and {{GET_MBRS_RSP}}. However, this slows things down as these message make up only a small part of the overall messages, but we have to inspect *every single message*! -- This message was sent by Atlassian JIRA (v6.4.11#64026)