Avi Freedman <freedman@netaxs.com> writes:

...

The cyclic stuff in News recently has hammered home that the search for elegance pays off. I "initially" solved the problem of having multiple machines with the same IP by postulating IP-stack hackery involving forwarding any packets that come in for sockets that don't exist to a central database-forwarder machine that keeps track of all open tcp sessions on all replicated machines, but it turns out that there are some much easier non-stack-hackery-mandatory solutions.

Your approach also is not a neat solution for two further reasons. Firstly, it requires maintaining connection state for all connections on a central repository, and secondly, it requires that your network be stable at the point when a connection needs to migrate.

Sorry, I wasn't clear. The solution described above is NOT clean, neat, or elegant. The solution we've come up with in theory and will be testing shortly (before NANOG) is clean, neat, and elegant, and relies on things that things-without-hard-disks can do right now.

You should be able to deal with the case that during the lifetime of a TCP session something causes traffic that was hitting site A suddenly arrive at similarly-numbered site B at a time when connectivity within your network is unstable. (This likely can be done with tunnels, following the NAT approach, if synchronization is between things located at the edges of your network, rather than in a star pattern from something inside your network).

We can deal with that.

You should also avoid scaling limits inherent in dumping lots of traffic at some central host rather than doing content-driven fail-over checkpointing for bulk data transfers from "static" content.

We abandoned that approach as not "clean" enough a while ago, when I decided to search for a cyclic-level "elegance" to the solution.

Sean.

P.S.: do you go about guaranteeing that you have unique connection "names" across all your simliarly-numbered hosts?

Yes, that's (obviously) part of it... Avi