From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:58416)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1bIauw-0003ff-98
	for qemu-devel@nongnu.org; Thu, 30 Jun 2016 08:18:06 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1bIaus-0004LO-8N
	for qemu-devel@nongnu.org; Thu, 30 Jun 2016 08:18:01 -0400
Received: from mx1.redhat.com ([209.132.183.28]:34909)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <jasowang@redhat.com>) id 1bIaus-0004LC-2l
	for qemu-devel@nongnu.org; Thu, 30 Jun 2016 08:17:58 -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>
	<57736702.3070704@cn.fujitsu.com>
From: Jason Wang <jasowang@redhat.com>
Message-ID: <57750DEF.5020504@redhat.com>
Date: Thu, 30 Jun 2016 20:17:51 +0800
MIME-Version: 1.0
In-Reply-To: <57736702.3070704@cn.fujitsu.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
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: Zhang Chen <zhangchen.fnst@cn.fujitsu.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: zhanghailiang <zhang.zhanghailiang@huawei.com>, "eddie . dong" <eddie.dong@intel.com>, qemu devel <qemu-devel@nongnu.org>, Li Zhijian <lizhijian@cn.fujitsu.com>, Yang Hongyang <hongyang.yang@easystack.cn>



On 2016=E5=B9=B406=E6=9C=8829=E6=97=A5 14:13, Zhang Chen wrote:
>
>
> On 06/29/2016 09:55 AM, Jason Wang wrote:
>>
>>
>> On 2016=E5=B9=B406=E6=9C=8828=E6=97=A5 14:33, Zhang Chen wrote:
>>>>>
>>>>>>
>>>>>>> primary guest response=20
>>>>>>> pkt(seq=3Dprimary_seq+1,ack=3Dclient_seq+1+data_len,flag=3DACK)
>>>>>>> secondary guest response=20
>>>>>>> pkt(seq=3Dsecondary_seq+1,ack=3Dclient_seq+1+data_len,flag=3DACK)
>>>>>>
>>>>>> 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=20
>>> packet for ack.
>>> we will get this packet.
>>> like:
>>> pkt(seq=3Dxxxx,ack=3Dxxx,flag=3DACK).=20
>>
>> Right, so looks like if guest want to send some data too, it can send=20
>> tcp packet without ACK set?
>
> NO, I tried it. the tcp packet always has ACK set except the SYN=20
> packet and FIN packet.
> you can dump the packet to see it.
>
> Thanks
> Zhang Chen

Right, RFC said:

"   If the ACK control bit is set this field contains the value of the
     next sequence number the sender of the segment is expecting to
     receive.  Once a connection is established this is always sent.
"