[Qt-interest] Concurrent qnetworkrequest's to same domain
Marcus Williams
marcus-qt at quintic.co.uk
Wed Jul 22 16:30:43 CEST 2009
Thiago Macieira wrote:
>> If I want to bump this up does the act of using more than one get
>> around this limit (so do I get 2 per manager) or is this 2
>> outgoing connections to a single domain shared across all
>> managers?
>
> The limit is per manager. Managers don't talk to each other.
>
> But you shouldn't have more than one manager, since they won't share
> other things like cookies and proxy settings.
Ok, that shouldnt pose a problem - the application in question talks to
a web service that in turn passes back some urls that need to be
downloaded. These urls point to static documents. So its these documents
(that are all on a single domain) that I need to download concurrently.
No cookies, and proxy/auth can be set up on a per manager basis if needed.
>> I have a download manager thread in a client talking to a single
>> assets server. It uses a single networkaccessmanager object. All
>> download requests are queued up as network requests on this object
>> and the thread deals with the download signals as required.
>
> I'd say the thread is completely redundant. But separate managers is
the only
> way to have multiple threads.
You're probably right about the thread, I'm not sure anymore that it is
necessary. I seem to remember I couldnt get the requests to work without
it and still keep the UI from blocking entirely. I understand the event
loop a little more now :)
> The signals are thread-safe.
>
> Accessing the objects isn't. You can only access it from the thread
that they
> were created in (the QNetworkAccessManager thread). You can't
moveToThread.
> Which is why you shouldn't use threads to deal with QNAM.
Not sure what you mean here. I create the networkrequest in the
downloadmanager thread directly:
QNetworkRequest request;
.. set up headers...
QNetworkReply *reply = m_netManager->get(request);
So request and reply are owned by the download manager thread arent they?
I then connect the slots/signals in the same method:
connect(reply, SIGNAL(finished()), this, SLOT(slotFinished()));
..
In the slotFinished I pull the reply from QObject::sender() and the
request object from the reply itself. I do what I need to do with the
document (save it somewhere, insert it in a db whatever) and then exit
from the slot. I may also kick off more downloads from within the
slotFinished code.
> We're also working on a priority concept which would allow QNAM to
override
> the socket limit and open a new connection.
This is probably what I'm looking for now :)
Is the max connection limit hackable if we build qt from scratch (we do
this already, so if its a simple change this might be the easiest).
Marcus
More information about the Qt-interest-old
mailing list