|
Julian Anastasov wrote:
>
> > Regarding the second question, it's about ICMP packets that are replied to
> > the
> > client accessing the virtual service. Maybe I should precise I am in a
> > VS/NAT
> > configuration.
> > For example, a client accesses a TCP virtual service and then stops sending
> > data
> > for a long time, enough for the LVS entry to expire. When the client try to
> > send
> > new data over this same TCP connection the LVS box sends ICMP (port
> > unreachable)
> > packets to the client. But for a TCP connection how these ICMP packets can
> > "influence" the client ? It will stop sending packets to this expired (for
> > the
> > LVS box...) TCP connection only after its own timeouts, doesn't it ?
>
> By default TCP replies RST to the client when there is no
> existing socket. LVS does not keep info for already expired connections
> and this is the reason ICMP is replied. Of course, if we implement
> TCP RST replies we can reply TCP RST instead of ICMP.
>
> The other question is how the client interpretes the ICMP
> replies. Linux at least allows the application to listen for such
> ICMP replies.
> In the other case (which is default) they are reported
^^^^^^^^^^ ^^^^
> after a TCP timeout (as soft errors).
Julian,
what is "the other case" (non Linux) and why is it default?
what is "they"?
Thanks Joe
--
Joseph Mack PhD, Senior Systems Engineer, Lockheed Martin
contractor to the National Environmental Supercomputer Center,
mailto:mack.joseph@xxxxxxx ph# 919-541-0007, RTP, NC, USA
|
