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).