You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
So, please be patient with me as I try to fully understand the picture. I went through a related discussion with GSI some time ago. They had a similar issue and it took a while to understand the network topology before we could solve their data routing requirements without inflicting pain on people who didn't have their issue. The end result was an additional configuration option that described the topology so that xrootd could choose the appropriate interface. Most sites don't need to do that so it worked out fine; they just ignore the option.
So, in the xrootd case, data channels are established using the same IP address that was used for the control channel. That isn't a requirement. The only requirement is that the data connection is made to the same host as the control connection because data follows control. So, is it the case that the initial login will always be to the host sending or receiving data? If so, the only thing you are requesting is that a different interface be used for the actual data. Is that correct?
Next, so assume that data and control will always be to the same host. Is it the case that the two interfaces are visible via DNS? That's not always the case, so that is why I ask. It's not a requirement but it makes life easier and a tad more secure if that is the case.
Once I get the above information, there are likely several ways this can be accomplished without disrupting the common case scenario. For instance, one possibility is for an xrootd server to advertise the preferred data path so that data channels can use it; if it's accessible from the client's perspective. We did that some time ago for different reasons but no one used the feature so we killed it. We can always bring it back. Another, perhaps simpler, solution is to redirect the data channel to the interface you would prefer to use for data.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1