Messages in this thread | | | From | thospel@mail ... | Date | 1 Oct 1997 20:46:35 -0000 | Subject | Re: Process Migration on Linux - Impossible? |
| |
In article <3.0.3.32.19971001124846.009161e0@pop.gate.net>, "David Schwartz" <djls@gate.net> writes: > At 11:05 AM 10/1/97 -0500, Tall cool one wrote: >>Victor Yodaiken <yodaiken@chelm.cs.nmt.edu> writes: >>> On Tue, Sep 30, 1997 at 10:06:25PM -0500, Tall cool one wrote: >>> > Personally, I don't have a real need for process migration, but I'd > like >>> > to see it because of what process migration would allow. The ability of >>> >>> So you want fault tolerance, not process migration. Don't confuse the >>> technique with the result. >> >> That's an odd thing to say, isn't it? Re-read my first sentence again, >>carefully this time. If one can throw a process on another machine at will, >>it becomes trivial to checkpoint, yes? Fault tolerance for free. > > Nope. Not so. You can't migrate a TCP/IP connection between machines even
I've been wondering about that. It would seem possible if the machine that receives the proces (let's call it B) is on the same net with ethernet. B would put it's card in promiscuous mode, and listen for packets that are meant for the port/ip adress of the application. The machine the process comes from (A) would stop responding to packets for that process. As long as the router accepts answers coming from the ethernet-adress of B (encapsulating perfectly good IP packets that are ok for the rest), it would seem that in fact B could take over A's network connection. A and B can compare notes ever so often to see whose card can best be put in promiscuous mode (maybe even both if there's also processes from B on A).
And for disks you could share a SCSI-bus, but that's a whole other can of worms.
Ton .
| |