Re: [PATCH 3/3] tcp: Repair socket queues

于 2012年03月29日 18:36, Pavel Emelyanov 写道:

On 03/29/2012 02:30 PM, Li Yu wrote:

quoted

于 2012年03月28日 23:38, Pavel Emelyanov 写道:

quoted

Reading queues under repair mode is done with recvmsg call.
The queue-under-repair set by TCP_REPAIR_QUEUE option is used
to determine which queue should be read. Thus both send and
receive queue can be read with this.

Caller must pass the MSG_PEEK flag.

Writing to queues is done with sendmsg call and yet again --
the repair-queue option can be used to push data into the
receive queue.

When putting an skb into receive queue a zero tcp header is
appented to its head to address the tcp_hdr(skb)->syn and
the ->fin checks by the (after repair) tcp_recvmsg. These
flags flags are both set to zero and that's why.

The fin cannot be met in the queue while reading the source
socket, since the repair only works for closed/established
sockets and queueing fin packet always changes its state.

The syn in the queue denotes that the respective skb's seq
is "off-by-one" as compared to the actual payload lenght. Thus,
at the rcv queue refill we can just drop this flag and set the
skb's sequences to precice values. IOW -- emulate the situation
when the packet with data and syn is splitted into two -- a
packet with syn and a packet with data and the former one is
already "eaten".

When the repair mode is turned off, the write queue seqs are
updated so that the whole queue is considered to be 'already sent,
waiting for ACKs' (write_seq = snd_nxt<= snd_una). From the
protocol POV the send queue looks like it was sent, but the data
between the write_seq and snd_nxt is lost in the network.

This helps to avoid another sockoption for setting the snd_nxt
sequence. Leaving the whole queue in a 'not yet sent' state (as
it will be after sendmsg-s) will not allow to receive any acks
from the peer since the ack_seq will be after the snd_nxt. Thus
even the ack for the window probe will be dropped and the
connection will be 'locked' with the zero peer window.

Do we need to restore various TCP options switch bits. e.g. window
scale factor, sack_ok and so on.

SACK-s -- yes, this is in TODO list. Various window stuff -- not necessary.
TCP will eventually negotiate proper values again.

quoted

En, I think the recorded mss_cache may be need to restored too.

Same with mss. As far as I understand this one will be re-detected after
a connection restore.

After the connection are repaired, it directly enter ESTABLISHED state,
so this TCP connection has no chance to negotiate such optional
features, such negotiation only can occurs at 3WHS.

Thanks.

Yu

quoted

Thanks.

Yu