Hi Michael and all,
tcp_tw_recycle is incompatible with NAT on the server side
... because it will enforce the verification of TCP time stamps.
Unless all
clients behind a NAT (actually PAD/masquerading) device use identical
timestamps
(within a certain range), most of them will send
Sven,
tcp_tw_recycle is incompatible with NAT on the server side
... because it will enforce the verification of TCP time stamps.
Unless all clients behind a NAT (actually PAD/masquerading) device
use identical timestamps (within a certain range), most of them will
send invalid TCP
Sven,
Right, you're saying that the srcaddr+srcport pair of a connection in
TIME_WAIT should not be reused under this scheme (i.e. the SYN can be
dropped), and I agree. Then I don't understand why a new connection
originating from a *different* source port (although from the same
source IP)
Hi,
in http://varnish.projects.linpro.no/ticket/613 I have suggested to add a
measure to varnishstat which I thought could be called the efficiency ratio.
Tollef has commented that we'd need the community's (YOUR) opinion on this:
The varnishstat cache hit rate basically gives a ratio for how
Paul,
have I missed anything or have you not yet stated which version of OpenSolaris
(uname -v) you're using? If you don't use a standard build, could you please
give the hg changeset you're on?
Nils
___
varnish-misc mailing list
Hi Poul-Henning and all,
If I had implemented the hack I suspect Solaris contains, I would
have found some bit somewhere, to make sure the errno would be the
correct, documented and expected:
#define ECONNRESET 54 /* Connection reset by peer */
Somebody with a Solaris
Hi Paul,
You're right, I'd forgotten to mention it before now.
[r...@varnish bin]# uname -a
SunOS varnish 5.11 snv_111b i86pc i386 i86pc
Good, thank you. Then at least this shouldn't be a bug introduced with the
major
changes of the ip datapath refactoring project
