From owner-freebsd-hackers@FreeBSD.ORG Wed Sep 12 13:22:10 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2232B16A421 for ; Wed, 12 Sep 2007 13:22:10 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 999F613C480 for ; Wed, 12 Sep 2007 13:22:09 +0000 (UTC) (envelope-from max@love2party.net) Received: from dslb-088-066-037-076.pools.arcor-ip.net [88.66.37.76] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1IVSAR0TDs-000450; Wed, 12 Sep 2007 15:22:07 +0200 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Wed, 12 Sep 2007 15:21:58 +0200 User-Agent: KMail/1.9.7 References: In-Reply-To: X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1345745.cVBBstyyvz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200709121522.05049.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/2fcMf306+jmIio+Buy3MhCe+KQe00JqD6mJJ cu8z0icH/JfQD0JSN1yMnaAzF8nASmZb7ZTBuPA8yT7tBZIfae 6+hS9vpM5AYg5+gESjonn6QLICS/WsPE0IkOom/PFA= Cc: Artem Kazakov Subject: Re: TCP/IP redundant connections X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2007 13:22:10 -0000 --nextPart1345745.cVBBstyyvz Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 11 September 2007, Artem Kazakov wrote: > Hello Everyone! > > For my research project I'm working on making some network services > redundant. And I have one idea, but I'm not so good and operating > system > internals, so could you please tell what do you think. If it is > possible at all. > > So, I have two hosts, which are all the same and they have some > network service which I need to make available all the time. This > service has some internal state, which is synchronized over private > connection. And at one time only one of the servers actually works > with clients, the other on is just sitting there and kept > synchronized. > The clients have persistent TCP connections to the server, and in case > of failure they make UDP broadcasts searching for server and then > reconnect. So basically there is no need to use IP-sharing between two > of them. But if the server fails, the client usually notices that > after some time-out (tcp keep alive time out I suppose) which is not > very good in some cases. > So I want to utilize IP-sharing and TCP-connection synchronization > (which is not yet implemented by anyone as far as I know). I want it > in case of failure seamlessly to switch to the other machine. As far > as the internal state is synchronized, if it is possible to > synchronize open connections as well(and all the low level stuff as > packet sequence numbers and so on) it would allow to make switch-over > to the back-up server in a matter of seconds, and the clients would > stay connected. > Is is possible to do so ? And if yes, how difficult would it be for a > person who has solid background in general-tasks programming, but no > experience with low level system programming ? And what are the > possible cave-eats of this approach? TCP is a reliable protocol. That means once you ACK a segment the other=20 side assumes that you have actually received it. In your scenario, that=20 would mean to defer the ACK until the secondary box has received the copy=20 of the segment and acknowledged to the first one which then in turn will=20 acknowledge the client. As a result you are back to a single point of=20 failure and greatly diminished performance. If you try to do it=20 differently - e.g. have the second box just snoop in on the TCP state. =20 There is no guarantee that it has actually seen every packet and once a=20 segment (that the primary has ACKed) is lost, there's no way to get it=20 back. I think you should rather look at session management in the application=20 and move away from long-lived TCP connections for that purpose. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1345745.cVBBstyyvz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBG5+f9XyyEoT62BG0RAh2ZAJ4pzpwFTG7jWWIn4fJmx7vHmwQeSQCePg1/ DMgrklhdEdlbpG3dHGqfYII= =BqlM -----END PGP SIGNATURE----- --nextPart1345745.cVBBstyyvz--