From owner-failsafe@oss.sgi.com Sun Jun 3 21:12:38 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f544Ccb19782 for failsafe-outgoing; Sun, 3 Jun 2001 21:12:38 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f544Cbh19777 for ; Sun, 3 Jun 2001 21:12:37 -0700 Received: from hindon.hss.co.in ([202.54.26.202]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA03094 for ; Sun, 3 Jun 2001 21:11:44 -0700 (PDT) mail_from (sndtrn27@hss.hns.com) From: sndtrn27@hss.hns.com Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f5445e119043 for ; Mon, 4 Jun 2001 09:35:41 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256A61.0014FE90 ; Mon, 4 Jun 2001 09:19:18 +0530 X-Lotus-FromDomain: HSS To: failsafe@oss.sgi.com Message-ID: <65256A61.0014C7B5.00@sandesh.hss.hns.com> Date: Mon, 4 Jun 2001 09:24:34 +0530 Subject: regarding Redundancy in TCP/IP Stack Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-failsafe@oss.sgi.com Precedence: bulk hi all , list We am novice to the Linux TCP / IP stack arch, At present i want to implement redundancy at socket level in the Stack.. Can you please help me with some docs, information in this regards we want to know 1. The Data structures that are kept by the system for maintaining the Connection. 2. Kernel related data structures that are part of the TCP / IP stack. 3. Any Documents, Links that can help us in getting with the procedure .as to how it can be implemeted efficiently. 4. Pros & cons in implementing such redundancy. 5. kernel related other information as to which modules are interdependent to this (If any). 6. If any work is going in this regards, then what is the present status. & for more detail whom shall then we refer to. regards Rajiv From owner-failsafe@oss.sgi.com Sun Jun 3 22:45:56 2001 Received: (from majordomo@localhost) by oss.sgi.com (8.11.3/8.11.3) id f545juG01455 for failsafe-outgoing; Sun, 3 Jun 2001 22:45:56 -0700 Received: from femail19.sdc1.sfba.home.com (femail19.sdc1.sfba.home.com [24.0.95.128]) by oss.sgi.com (8.11.3/8.11.3) with SMTP id f545jth01452 for ; Sun, 3 Jun 2001 22:45:55 -0700 Received: from ehome.inhouse ([24.14.22.157]) by femail19.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010604054555.SMCC12680.femail19.sdc1.sfba.home.com@ehome.inhouse>; Sun, 3 Jun 2001 22:45:55 -0700 Date: Sun, 3 Jun 2001 22:35:33 -0700 (MST) From: Eric Lee Green X-X-Sender: To: cc: Subject: Re: [LinuxFailSafe] regarding Redundancy in TCP/IP Stack In-Reply-To: <65256A61.0014C7B5.00@sandesh.hss.hns.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-failsafe@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 4 Jun 2001 sndtrn27@hss.hns.com wrote: > hi all , list > We am novice to the Linux TCP / IP stack arch, > At present i want to implement redundancy > at socket level in the Stack.. Can you please > help me with some docs, information in this regards > > we want to know > 1. The Data structures that are kept by the system for maintaining the > Connection. > 2. Kernel related data structures that are part of the TCP / IP stack. > 3. Any Documents, Links that can help us in getting with the procedure .as to > how it can be implemeted efficiently. > 4. Pros & cons in implementing such redundancy. > 5. kernel related other information as to which modules are interdependent to > this (If any). > 6. If any work is going in this regards, then what is the present > status. & for more detail whom shall then we refer to. This is an interesting topic and subject. My gut feel is that the current design of the network stack is not conducive to redundancy, but I don't have anything behind that gut feel other than a general knowledge of how monolithic operating systems behave and how the Linux network stack has become intertangled with various other pieces of the system such as the disk buffer cache (part of the optimizations for web serving so that the Linux guys can now claim to have the world's fastest web server, sigh). This doesn't bode well for the notion of either doing a seamless replacement of the network stack with one which incorporates socket migration and redundancy, or patching the current network stack to incorporate socket migration and redundancy. In any event, this is more of an issue for fault-tolerate systems than for high-availability systems, in my opinion. Note that FailSafe is a high-availability system, not a fault-tolerant system. The difference is that high-availability systems tolerate momentary disruptions of service during the failover process. Most modern-day protocols are fairly tolerant of random disconnects, and most people are not going to get upset if they have to click on a "Try Again?" button once or twice a year when hardware fails and the failover takes place. Similarly, if a web page display gets interrupted due to a server falling over, most people are fine with hitting the "Refresh" button to get the whole page again. I'm personally more interested in redundant distributed filesystems, and especially filesystems that can handle the case of multiple master-slave relationships. DRBD is a nice proof of concept but it is much too low-level for what is needed, what is needed is something like what CODA does, which incorporates versioning in order to do faster syncs after a reconnect. Unfortunately CODA is very, very far away from being a production-quality system, with some serious design limitations (like utter lack of any kind of locking protocol). Of course, file locking on distributed filesystems is itself a research topic :-}. And without the low-level socket migration stuff that you're talking about, file locking is only useful with connectionless protocols such as NFS anyhow. - -- Eric Lee Green mailto:eric@badtux.org GnuPG public key at http://badtux.org/eric/eric.gpg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7Gx4q3DrrK1kMA04RAvwzAKCNbkBmi0iTQL8yHfuLSAwlGeViAgCfUv1/ dFK31ZOtdY9/2iT07v82sss= =jI+3 -----END PGP SIGNATURE-----