?

Log in

No account? Create an account
brad's life [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

TCP connection passing! [Jul. 7th, 2004|10:03 pm]
Brad Fitzpatrick
Holy shit, where'd this bad boy come from!?

http://tcpcp.sourceforge.net/
tcpcp is a mechanism that allows cooperating applications to pass ownership of TCP connection endpoints from one Linux host to another one.
Such functionality should be useful in load-balancing and failover applications.
tcpcp can be used between hosts using different architectures and does not need the other endpoint of the connection to cooperate (or even to know what's going on).
*drool*

I'm so regretting not going to the Ottawa Linux Symposium:
http://www.linuxsymposium.org/2004/speakers.php?types=talk
LinkReply

Comments:
[User Picture]From: scosol
2004-07-07 10:44 pm (UTC)
hmmmm maybe im missing something but im failing to see how this works
from 1998-2000 i worked for resonate, which had a software load-balancing product
one of it's main advantages was just this sort of connection-handoff
but it operated in a "triangle" of sorts.
one machine was designated the "scheduler"- it accepted the incoming client tcp session + initial GET request, then passed that via a proprietary protocol to a "node" which would then answer the request.
the key here is that any subsequent communication from the client, acks, fins etc still went to the scheduler (and were passed on to the node)
so, all incoming client packets went to scheduler -> node, and all outgoing data went direct from node to client.
this made it very nice and scalable :)

but with the entire tcp endpoint being handed off to another node, wouldn't you need some intelligent front-machine to keep track of what endpoints were sent where?
(Reply) (Thread)
[User Picture]From: brad
2004-07-07 10:49 pm (UTC)
but with the entire tcp endpoint being handed off to another node, wouldn't you need some intelligent front-machine to keep track of what endpoints were sent where?

No clue. I haven't looked at it yet. Just catching up on news and found it.

What you described is definitely more obvious than passing off the whole connection. I don't see how two machines (two NICs, two MACs) could own separate TCP connections with the same dest IP address and only different dest ports.
(Reply) (Parent) (Thread)
[User Picture]From: scosol
2004-07-07 10:56 pm (UTC)
I don't see how two machines (two NICs, two MACs) could own separate TCP connections with the same dest IP address and only different dest ports.

Right- you would need an intelligent NAT that knew which MAC to address the packets to.
Interestingly, most devices have no problem with this on the outbound side.
Right around that time Cisco added some really fun functionality to their PIX that said "oh shit, I see lots of packets coming from the same IP but with a bunch of different MACs, that must mean somebody is spoofing, shut everything down!"
Hahah- call it "intelligient downtime" :)
(Reply) (Parent) (Thread)
From: (Anonymous)
2004-07-08 10:13 am (UTC)

Not really black magic

From the README:
> tcpcp requires that the hosts participating in such a transfer
> share a common local IP address (or use mechanisms like NAT to
> appear sharing an address), to which the TCP connection is bound.

and later:
> Implementation status
> ---------------------
> 
> This version was only tested when moving connections around on
> the same host. It is known to build and work correctly on ia32
> (Red Hat 7.2 and 9.0) and amd64 (Gentoo 2004.0).

It doesn't look like it's going to magically solve the problem of having your "load balancer" crash while you had established connections.
(Reply) (Parent) (Thread)
[User Picture]From: brad
2004-07-08 11:36 am (UTC)

Re: Not really black magic

Bleh.
(Reply) (Parent) (Thread)
[User Picture]From: marksmith
2004-07-08 08:26 am (UTC)
I'm curious how that works. Sounds like it'd be neat, kinda like two people behind NAT setups being able to connect to eachother with the temporary help of a third host.
(Reply) (Thread)