[jboss-jira] [JBoss JIRA] Updated: (JGRP-20) Address translation in transport (NAT support)

[Bela Ban (JIRA)]

     [ http://jira.jboss.com/jira/browse/JGRP-20?page=all ]

Bela Ban updated JGRP-20:
-------------------------

    Fix Version/s: 2.6
                       (was: 2.5)

> Address translation in transport (NAT support)
> ----------------------------------------------
>
>                 Key: JGRP-20
>                 URL: http://jira.jboss.com/jira/browse/JGRP-20
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 2.2.8
>            Reporter: Bela Ban
>         Assigned To: Bela Ban
>             Fix For: 2.6
>
>   Original Estimate: 2 weeks
>  Remaining Estimate: 2 weeks
>
> On multi-homed systems, the identity of a member is bound to a NIC (either chosen by the OS, or by the
> user through bind_addr): Address. When a message is sent, the msg contains this address as the sender's
> address. Responses go to the same address.
> However, if that NIC breaks, and the sender's OS chooses a different NIC for the datagram packets, the
> receiver will still send the response back to the old address (the identity of the sender cannot
> change).
> If we set the sender's address in any Message on *reception* of the message, we would be able to send
> the response back to a valid NIC in the above case. However, this means the *identity* of the sender
> changes, which JGroups cannot handle.
> SOLUTION I: we could introduce a logical address, which contains the physical address of the NIC
> through which it was sent. Problem: a lot of code would have to change.
> SOLUTION II: we maintain, in each transport, a table of sender's address as defined in the Message, and
> physical address of the {Datagram,Multicast}Packet received. Whenever we send a unicast message, we get
> the destination address from this table through a lookup in which dest_msg.dest_addr is the key.
> We need to reap the table every now and then to purge old addresses, we could use view changes to do
> so.
> Example for SOLUTION II:
> - Member P: address=1.2.3.4:5555
> - P's box has 2 NICs: 1.2.3.4 and 5.6.7.8
> - Receiver R receives a message from P: P.src_addr=1.2.3.4:5555, datagram's address is 1234:5555
> - R doesn't add an entry to the translation table, because the addresses are the same
> - R sends a response: it looks up 1.2.3.4:5555 (dst) in the translation table
> - There is no entry, therefore R sends the response to 1.2.3.4:5555
> - P's NIC 1.2.3.4 is unplugged
> - P sends a message through NIC 5.6.7.8
> - R receives a message M.src_addr=1.2.3.4:5555, datagram's address is 5.6.7.8:5555
> - R adds an entry to its translation table: 1.2.3.4:5555 --> 5.6.7.8:5555
> - R sends a response to 1.2.3.4:5555, since there is an entry for 1.2.3.4:5555, it uses 5.6.7.8:5555 
>   as the destination address of the datagram packet
> SOLUTION II allows us to reuse the existing code, but provides for changing underlying IP addresses.

-- 
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