[Development] Default enabling inbound flow control on sockets
thiago.macieira at intel.com
Tue Feb 14 20:41:35 CET 2012
On terça-feira, 14 de fevereiro de 2012 17.51.33, shane.kearns at accenture.com
> 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:
if (size == -1 && bytesAvailable() >= sizeof(size))
stream >> buffer;
if (size > bytesAvailable())
// 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: not available
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/development/attachments/20120214/ac2e96ba/attachment.bin
More information about the Development