TCP/IP redundant connections
max at love2party.net
Wed Sep 12 06:22:10 PDT 2007
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
> 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
> 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
side assumes that you have actually received it. In your scenario, that
would mean to defer the ACK until the secondary box has received the copy
of the segment and acknowledged to the first one which then in turn will
acknowledge the client. As a result you are back to a single point of
failure and greatly diminished performance. If you try to do it
differently - e.g. have the second box just snoop in on the TCP state.
There is no guarantee that it has actually seen every packet and once a
segment (that the primary has ACKed) is lost, there's no way to get it
I think you should rather look at session management in the application
and move away from long-lived TCP connections for that purpose.
/"\ Best regards, | mlaier at freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier at EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20070912/e07a60ef/attachment.pgp
More information about the freebsd-hackers