From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55191)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <zhangchen.fnst@cn.fujitsu.com>) id 1bI8kA-0000kq-TR
	for qemu-devel@nongnu.org; Wed, 29 Jun 2016 02:13:03 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <zhangchen.fnst@cn.fujitsu.com>) id 1bI8k5-0006Zv-Sr
	for qemu-devel@nongnu.org; Wed, 29 Jun 2016 02:13:02 -0400
Received: from [59.151.112.132] (port=33009 helo=heian.cn.fujitsu.com)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <zhangchen.fnst@cn.fujitsu.com>) id 1bI8k5-0006Wh-DG
	for qemu-devel@nongnu.org; Wed, 29 Jun 2016 02:12:57 -0400
References: <1465902912-27527-1-git-send-email-zhangchen.fnst@cn.fujitsu.com>
	<1465902912-27527-4-git-send-email-zhangchen.fnst@cn.fujitsu.com>
	<57678CDA.7020700@redhat.com> <20160620121402.GC2891@work-vm>
	<576A020E.8040804@cn.fujitsu.com> <576A3174.2010905@redhat.com>
	<576BBE8D.1030009@cn.fujitsu.com> <576CCE68.90309@redhat.com>
	<57721A55.8020906@cn.fujitsu.com> <57732A77.1050209@redhat.com>
From: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>
Message-ID: <57736702.3070704@cn.fujitsu.com>
Date: Wed, 29 Jun 2016 14:13:22 +0800
MIME-Version: 1.0
In-Reply-To: <57732A77.1050209@redhat.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [RFC PATCH 3/3] filter-rewriter: rewrite tcp
 packet to keep secondary connection
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jason Wang <jasowang@redhat.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Yang Hongyang <hongyang.yang@easystack.cn>, "eddie . dong" <eddie.dong@intel.com>, qemu devel <qemu-devel@nongnu.org>, Li Zhijian <lizhijian@cn.fujitsu.com>, zhanghailiang <zhang.zhanghailiang@huawei.com>



On 06/29/2016 09:55 AM, Jason Wang wrote:
>
>
> On 2016年06月28日 14:33, Zhang Chen wrote:
>>>>
>>>>>
>>>>>> primary guest response 
>>>>>> pkt(seq=primary_seq+1,ack=client_seq+1+data_len,flag=ACK)
>>>>>> secondary guest response 
>>>>>> pkt(seq=secondary_seq+1,ack=client_seq+1+data_len,flag=ACK)
>>>>>
>>>>> Is ACK a must here?
>>>>
>>>> Yes.
>>>>
>>>
>>> Looks not, e.g what happens if guest does not use piggybacking acks?
>>>
>>>
>>
>> If guest does not use piggybacking acks, it will send a independent 
>> packet for ack.
>> we will get this packet.
>> like:
>> pkt(seq=xxxx,ack=xxx,flag=ACK). 
>
> Right, so looks like if guest want to send some data too, it can send 
> tcp packet without ACK set?

NO, I tried it. the tcp packet always has ACK set except the SYN packet 
and FIN packet.
you can dump the packet to see it.

Thanks
Zhang Chen

>
>
>

-- 
Thanks
zhangchen