[ http://jira.jboss.com/jira/browse/JGRP-20?page=history ]
Bela Ban updated JGRP-20:
-------------------------
Summary: Address translation in transport (NAT support) (was: Address
translation in transport)
> Address translation in transport (NAT support)
> ----------------------------------------------
>
> Key: JGRP-20
> URL: http://jira.jboss.com/jira/browse/JGRP-20
> Project: JGroups
> Type: Feature Request
> Versions: 2.2.8
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 2.2.9
>
> Original Estimate: 1 week
> Remaining: 1 week
>
> 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
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development
