Re: TCP/IP redundant connections
- From: Max Laier <max@xxxxxxxxxxxxxx>
- Date: Wed, 12 Sep 2007 15:21:58 +0200
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@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
Attachment:
signature.asc
Description: This is a digitally signed message part.
- References:
- TCP/IP redundant connections
- From: Artem Kazakov
- TCP/IP redundant connections
- Prev by Date: Re: TCP/IP redundant connections
- Next by Date: local "jailed" symlinks
- Previous by thread: Re: TCP/IP redundant connections
- Next by thread: Announcement: Devilator 1.0a for FreeBSD
- Index(es):
Relevant Pages
|
