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

[Li Yu <raise.sail@gmail.com>]

于 2012年03月29日 18:36, Pavel Emelyanov 写道:
> On 03/29/2012 02:30 PM, Li Yu wrote:
>> 于 2012年03月28日 23:38, Pavel Emelyanov 写道:
>>> 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.
>
>> 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 occur at 3WHS.

Thanks.

Yu

>> Thanks.
>>
>> Yu
>