[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: TCP/IP redundant connections
From:       Max Laier <max () love2party ! net>
Date:       2007-09-12 13:21:58
Message-ID: 200709121522.05049.max () love2party ! net
[Download RAW message or body]


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

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@freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier@EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]