From: Xin Long
> Sent: 27 February 2017 04:49
...
> > what I'm worried about is if the msg_more is saved in assoc:
> > chk4[clear] -> chk3 [clear] -> chk2 [clear] -> chk1 [clear]
> > then when you send a small chkA with MSG_MORE,
> > the queue will be like:
> > chkA [set] -> chk4[set] -> chk3 [set] -> chk2 [set] -> chk1 [set]
> > because msg_more is saved in assoc, every chunk can look at it.
> > chk1 - chk4 are big enough to be packed into a packet, they were
> > not sent last time because a lot of chunks are in the retransmit
> > queue.
Or just waiting for transmit window space.
> > But now even if retransmit queue is null, chk1-chk4 are still blocked.
> >
> > can you accept that chkA may block the old chunks ?
> even also block the retransmit chunks.
I don't see a problem, the application is about to send another chunk.
It is likely that the whole lot will go in one packet.
If the connection is flow controlled off (even if due to packet loss)
the minor delay waiting for the application won't make any real difference.
Indeed reducing the number of ethernet frames may help increase
overall throughput.
Does a request for chunks to be retransmitted force a response packet be built?
If so it will pick up all the queued data chunks regardless of any saved
MSG_MORE bits.
David
��.n��������+%������w��{.n�����{������ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
