Unfortunately I am having trouble understanding your question, but maybe the following provides an answer for you.
DDS provides an information-centric connectionless paradigm. This means communication takes place based on 'matching' information and not by addressing the physical location of a receiver by a sender (as it would in a connection-oriented environment).
Information is represented in DDS in the form of so-called Topics that are identified by a name, a type definition and a set of quality of service policies. Communication in DDS takes place between so-called Publishers and Subscribers. The matching between Publishers and Subscribers is transparently realized by the middleware itself based on Topics and independent of the physical location of these entities. To establish communication between a Publisher and a Subscriber, one only needs to create a DataWriter (sending) and a DataReader (receiving) for the same Topic (and make sure that their offered and requested quality of service policies match with each other).
This means that one can create any number of DataWriter and DataReader entities for one specific Topic independent of their physical location and they will communicate automatically (n-to-m).
If this does not answer your question, could you elaborate a bit more on it?
I don't know which DDS implementation you are using, but it sounds strange that you need to adapt a file to achieve communication between a specific Publisher and Subscriber, since it requires you to know the physical location of all participating entities on beforehand while the complete decoupling between publishers and subscribers is one of the most powerful features of DDS.