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 <[EMAIL PROTECTED]>, Gary Mills <[EMAIL PROTECTED]> 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.
