Contributed by grey on from the don't-lose-the-story-in-the-move dept.
See the complete KernelTrap interview here: http://kerneltrap.org/node/view/2873
This is a week late, and was posted on the obsdj.baselabs.org site as a news story while it lasted, but we didn't want it forgotten to undeadly amidst all the shuffling around.
(Comments are closed)
By Anonymous Coward (67.70.165.105) on
Comments
By Dunceor (130.243.30.36) on
By grey (207.215.223.2) on
This was however posted to obsdj.baselabs.org while it was running for the past week or two, and I made note of that in the full story post (though not in the headline).
After combing over undeadly, I didn't see it here either. I realize it's a repost after a fashion if you've been keeping up with OpenBSD forums of the past couple of weeks, but with the baselabs.org site gone, and deadly.org in stasis, I thought it would be good to give it a point of exposure where it will have more of a shelf life (short of the already mentioned openbsd.org/press.html page).
Comments
By Anonymous Coward (67.70.164.193) on
By Anonymous Cheese (207.215.253.53) on
By Anthony (192.208.10.217) on
The tricky part would be setting it up so that reading and writing to the socket would update the state atomically in such a way that connections could be picked up by another host at any time without missing a beat. I can't think of a way to do that without quite a bit of overhead.
I'd like to fool around with that this summer if I have time. Even if it's an idiotic idea, I'll probably learn enough to contribute with something else. And I'd like to do that.
Comments
By Peter Hessler (66.243.2.34) spambox@theapt.org on
Comments
By Anthony (68.145.159.179) on
1-when a socket to be made redundant across hosts is opened, it's opened atomically on all the CARP hosts
2-when a packet comes in, the CARP master node mirrors the packet to the other hosts, by wrapping it in a pfsync packet. This would have to be atomic too.
3-the other hosts use the packet to maintain their mirror of the socket in an identical state, including all the buffering and so forth in the network stack. It could be in the kernel but I think there are advantages to doing it in user space... it could be done by something like inetd, it would only need a call similar to listen() and a few other things to get all the information.
4-The process dealing with the socket on the master host would do everything normally, but whenever it does anything that could touch the outside, it updates the state on all the other machines. So everything needed can be redone from existing states and buffers at all times.
5-If the master host goes down, the process in charge of maintaining the state of the socket in step 3 would fork a new process, like inetd would, giving the new process a file descriptor(s). The new process could look up the state information, and pick up where the other one left off.
You wouldn't even need to use the same program binary for resumed connections.
The network used for pfsync stuff would have to be FAST
There'd clearly be other issues, but for something like the ftp proxy that doesn't need to touch anything on the host machine, it makes sense. Having a single API for it would make it easier to add failover to other programs.
By Brian P. (4.15.55.79) on