--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--