In the referenced message, Rodney Joffe said:
Just as a guess, Marshall is probably thinking of using anycast for
something other than DNS, like http, or ftp, or telnet. And he's
wondering about state
If you don't use per-packet type load-sharing, but something like
per-flow, or per-src/dst-hash, then you can use anycast for protocols
which require state (including tcp or other connection-oriented protocols,
for that matter).
Worst-case when the server you are communicating with fails, the
connection is broken, much as it would had anycast not been in use.
A resilient protocol/application could then reestablish the connection
somewhat quickly. Actually, I guess the worst-case would be when the
original machine came back online, the connection would once again
be broken, but not due to a failure. This would probably require
people to set things up (if they are smart) not to _automatically_
return to service. That way, the previously failed box could be
re-inserted during a maintenance, for least detrimental effect.
This type of thing would be most useful for read operations, and becomes
somewhat of a problem for write operations, due to synchronization.
Therefore, it might be useful for a web server, but not so for ftp
(unless, you had a separate master machine for folks/customers to
do put operations, which is then synchonized and pushed to the
anycast read boxes).
Of course, this would only be relevant/useful within your own enterprise,
since others may be using per-packet load-sharing (which comes with
a host of problems as it is, like the high potential for out of order packets.)
Whether doing this is practical is an exercise for the reader, but it
certainly is possible. Presently, I think most folks doing anycast
take the easy stance and just use it for non-stateful connectionless
protocols (esp. dns).
