Messages in this thread |  | | | Date | Sat, 26 Feb 2000 09:35:54 -0800 | | From | David Brower <> | | Subject | Re: Socket migration |
| |
FWIW, the SCO/Tandem "NonStop Cluster" product does do complete connected socket migration, I believe. This only works inside the very-tightly coupled cluster, which also allows process migration across hosts. (Sort of hard to migrate processes when you can't migrate the connections!). Conversely, keeping the tcp connection state doesn't do you much good if you can't move the application state as well, for any but the most trivial of application protocols. Anyway, SCO/Tandem show that it can be done for cooperative systems. The question for me is whether this is particularly useful. It seems easiest enough to move application programs when between transactions, and let some sort of application failover re-establish the connection. Where you really want transparency is in the case where there is a failure on the server, and you'd like to be able to failover the application and the connection. But doing so pretty much requires you to be checkpointing to independant storage after everything that is significant, and that seems extremely burdensome and inefficient. So, as of yet, I'm not particularly sold on the usefullness of socket migration as now conceived. What would be a compelling application for that feature?
I think the three-way messaging Alex suggests is very interesting, and of potentially more use.
ttfn,
-dB
> From: Alex Belits <abelits@phobos.illtel.denver.co.us> > Date: Fri, 25 Feb 2000 22:59:55 -0800 (PST) > Subject: Re: Socket migration > > On Sat, 26 Feb 2000, a9504915 wrote: > > > Hi, is there any information / projects that are about linux socket migration
> I assume, you are talking about connected TCP sockets. > > I have never heard about any implementation, but it can be a very > interesting thing to implement... > > ...performance of this thing will unlikely be > high enough (I assume, migration of sockets is supposed to be used to > solve performance problems, not to create additional ones).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |