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