[Development] Default enabling inbound flow control on sockets

[Thiago Macieira]

On terça-feira, 14 de fevereiro de 2012 17.51.33, shane.kearns at accenture.com 
wrote:
> When using the low level (QTcpSocket) API, you are dealing with a stream.
> Intuitively, you would expect the stream applies flow control and rate
> limiting by itself. If using native apis (either synchronous or
> asynchronous) on all platforms, this is what happens. The exact amount of
> buffering in the OS level varies between platforms. With QTcpSocket, this
> does not happen, because Qt reads all available data from the OS into its
> own buffers each time the event loop runs socket notifiers. Regressions are
> less likely, because socket using code is normally processing the stream as
> it arrives.

Agreed. I think this applies more to QTcpSocket than to QNetworkReply.

But I'd still use a higher value for the buffer size. The kernel buffer size on 
Windows is 48k and on Linux it can reach 128k. Also note the very common way 
that people use QDataStream over QTcpSocket, which is:

void Class::readyReadSlot()
{
    QDataStream stream(this);
    if (size == -1 && bytesAvailable() >= sizeof(size))
        stream >> buffer;
    if (size > bytesAvailable())
        return;

    // read using stream here
}

So the question is: what type is most recommended for the "size" variable? 
What's the average size of the datastream packet?

To be honest, I'd also like to replace QDataStream with stream that did that 
understood incomplete data (like QXmlStreamReader does).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120214/ac2e96ba/attachment.sig>