Hi Gary,
That's the type of approach Sun Cluster load balancing uses
(and presumably others too), however this requires support
on both the D and E systems, including a custom protocol
to share connection state information, otherwise D no longer
knows what's going on (eg. that the connection was accepted,
when it terminates, etc).
Rgds, Stuart.
>>> On 06-Jan-07 at 1:59 am, in message
<20070105145919.GC24417@cc.umanitoba.ca>,
Gary Mills <mills@cc.umanitoba.ca> wrote:
> On Fri, Jan 05, 2007 at 01:34:43AM +0000, Jefferson Ogata wrote:
>>
>> Think about what actually would happen in your desired scenario:
>>
>> 1. Remote client C sends a SYN packet from source endpoint C:P to
>> service destination endpoint D:S, which resides on a translating box
D.
>> On the client, the socket is in SYN_SENT state with remote endpoint
D:S.
>>
>> 2. Translating box receives SYN packet and translates destination to
E:T
>> and retransmits it to serving box E. So now the SYN packet is C:P ->
E:T.
>>
>> 3. Serving box E receives the SYN packet and responds with a
SYN/ACK
>> from E:T -> C:P. The socket on the serving box is in SYN_RCVD state
with
>> remote endpoint C:P. Since the SYN/ACK destination C is remote, E
sends
>> the packet out through the default router, so the translating box D
>> never sees this packet.
>
> Could serving box E fake the source of that packet so it appears to
> come from translating box D? Is that all that's needed to make
> this work?
>
>> 4. Client box C receives SYN/ACK from E:T and discards it, because
it
>> has no pending TCP connection in SYN_SENT state with E:T as the
remote
>> endpoint.
|