c******n
发帖数: 4965 | 1 I'm trying to simulate the situation where a connection is lost, to prepare
for fault-tolerance of my application.
my server listens on port 11111
instead of pulling out the physical cable, so far I do
sudo /sbin/iptables -t filter -A INPUT -p tcp --dport 11111 -j REJECT
this would reject new connections. but it seems that for already-established
connections,
the client side TCP won't trigger an exception if more bytes are pushed onto
the connection
is there a way to let TCP trigger an error ?
Thanks |
S*A
发帖数: 7142 | 2 You can simulate random packet drop in iptables.
http://code.nomad-labs.com/2010/03/11/simulating-dropped-packet
prepare
established
onto
【在 c******n 的大作中提到】
: I'm trying to simulate the situation where a connection is lost, to prepare
: for fault-tolerance of my application.
: my server listens on port 11111
: instead of pulling out the physical cable, so far I do
: sudo /sbin/iptables -t filter -A INPUT -p tcp --dport 11111 -j REJECT
: this would reject new connections. but it seems that for already-established
: connections,
: the client side TCP won't trigger an exception if more bytes are pushed onto
: the connection
: is there a way to let TCP trigger an error ?
|
c******n
发帖数: 4965 | 3 actually DROP will only cause a indefinite freeze on the client side,
not causing it to drop, REJECT will actually send a RST
what I am doing is similar to them with propability=1.0
【在 S*A 的大作中提到】
: You can simulate random packet drop in iptables.
: http://code.nomad-labs.com/2010/03/11/simulating-dropped-packet
:
: prepare
: established
: onto
|
x**m
发帖数: 941 | 4 If I were you, I might do this in a virtual machine and simulate real
connection drop by disabling its virtual network interface.
Can you try:
sudo /sbin/iptables -t filter -A INPUT -p tcp --dport 11111 --state
ESTABLISHED -j REJECT |
S*A
发帖数: 7142 | 5 if you set p=1.0, there is no need for the random part.
You just change the DROP to reject it should be fine.
【在 c******n 的大作中提到】
: actually DROP will only cause a indefinite freeze on the client side,
: not causing it to drop, REJECT will actually send a RST
: what I am doing is similar to them with propability=1.0
|
v*****r
发帖数: 1119 | 6 Just curious. What fault-tolerance you used on the server side?
An idle client vs a dead client, will the server behave the same?
Are you using tcp keepalive function or have your own logic?
prepare
established
onto
【在 c******n 的大作中提到】
: I'm trying to simulate the situation where a connection is lost, to prepare
: for fault-tolerance of my application.
: my server listens on port 11111
: instead of pulling out the physical cable, so far I do
: sudo /sbin/iptables -t filter -A INPUT -p tcp --dport 11111 -j REJECT
: this would reject new connections. but it seems that for already-established
: connections,
: the client side TCP won't trigger an exception if more bytes are pushed onto
: the connection
: is there a way to let TCP trigger an error ?
|
c******n
发帖数: 4965 | 7 connection is always kept, server does not proactively bring down idle
clients
btw, I found the answer, it's simply adding "--reject-with tcp-reset " to my
commands
【在 v*****r 的大作中提到】
: Just curious. What fault-tolerance you used on the server side?
: An idle client vs a dead client, will the server behave the same?
: Are you using tcp keepalive function or have your own logic?
:
: prepare
: established
: onto
|
