On Fri, 20 Oct 2017, Ricardo Dias wrote: > In the current messenger protocol, upon accepting a new connection, the > messenger sends it's address and the connecting peer address along with > the banner string. Why does the connecting peer need these addresses? > Moreover, the connecting peer uses the connecting peer address (sent > from the server) to set as it's own address. > > What happens if the network is rewriting addresses because of NAT, or > whatever other strange reasons? There are two cases: 1) client -> server connections. These always are initiated in one directly. The self address thing is included there partly so that the client can discover what its effective (public) address is. In the case of the OSD, the initial osd -> mon connection allows the osd to learn what it's public IP address will be (we advertise our address as the one that is used to connect to the mon). 2) server <-> server connections, e.g., mon<->mon, osd<->osd, mds<->mds. Here, connections can be opened in either direction. I believe here it is just used as a sanity check. > I also saw that the code that encodes these addresses have a comment > saying "// legacy". Should we remove these addresses from the new V2 > protocol, or do we still need them? I think we'll still need them, since new clients will still need to connect to old servers, and new servers will need to allow old clients to connect. HTH? sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
