I can imagine dozens of different network configurations that the system might need to support[1]. But the OT container shouldn't have to care about the network topology.
Instead the application should give the OT container a stream. The container is responsible for sending & receiving messages through the stream. Making the stream (and delivering messages) is the responsibility of a different part of the application. -J [1] Off the top of my head: - Web client <-> web server over websockets - WebRTC - TCP stream over a LAN - Mobile device over TCP over the internet - IPC between processes on my computer - Server-to-server over SSL - Server-to-server over protobufs over an XMPP extension - Server to server over http (like the http-based federation proposal) On Wed, Jun 19, 2013 at 2:04 PM, Pratik Paranjape <pratikparanj...@gmail.com> wrote: > I am still not sure how you are thinking of managing a persistent > connection between two nodes on the internet though. > Without the presence of at least one tracker to keep a registry of peers, > the model is very fragile. Consider two vim instances > on two different machines. How will they initially pair up without > knowledge of each other's IPs? If they somehow do, what happens > when DHCP abruptly changes the IP address of one of the nodes?
