UPDATE: THIS ISSUE HAS NOW BEEN RESOLVED. MORE INFO CAN BE FOUND BY CLICKING HERE.
Open-source downloads are currently unavailable due to a severe hardware failure at our cloud service provider. This affects both the online installer as well as the offline packages. Commercial downloads are unaffected, because they use a different service provider.
Unfortunately a hardware failure in the disk system of our cloud service provider caused two important servers to go offline yesterday. Work is ongoing to fix this, but the cloud service provider has informed us yesterday evening that they have not yet been able to restore the servers due to severe issues in their disk system.
Both of the key services related to open-source Qt delivery are affected (download frontend and delivery system master). Mirrors are not affected, so the downloads should be working again as soon as we have the master server for the online installation back online.
The downloads of open-source and commercial packages are done from different systems, despite using the same installer application. Because of this redundancy the commercial distribution continues to work normally. We also had two separate servers to reduce the risk of failure in the open-source distribution, but unfortunately both of these are affected by the disk system failure at our cloud service provider.
Commenting for this post has ended.
Awesome :] Any news about potential changes in QWebSockets module? :P
Hey, thanks! For 6.0 it was decided that we want to have a more limited scope to focus on the core/base components, so QWebSockets is not 'officially' supported in 6.0. But it will be brought back shortly after! I don't know anything more about the plans beyond that I'm afraid.
Could you remove the limit of 6 instances of QNetworkAccessManager? And I can't understand why you do this limit for Qt5?
There's no limit on how many instances of QNetworkAccessManager you can have (although our documentation recommends only having one instance). Are you perhaps talking about the limit of parallel connections QNetworkAccessManager will make in the background to a single host? That limit only counts for HTTP 1(.1) and was/is fairly standard. For HTTP/2 it's actually limited to only 1 connection, but thanks to how the protocol is made up it can actually send multiple requests per connection, so it doesn't need any more.
Yes, I am talking about the parallel connections. But I still hope you to remove this limit because QNetworkAccessManager is a very useful library et everywhere needs it, even in some urgent cases. For example, in the Security Industry with alarms, we hope continuously post the images immediately. If you still won't change ideas, it doesn't matter. But if we buy a commercial license, could you help us to remove this limit?? Thanks.
PS, the Http protocol is the best way to communicate with other languages et system, doesn't it? So I hope you can seriously think about it. Thanks again.
If you compile Qt on your own then as far as I'm aware (never tried) this is the only line that needs to be changed to increase it: https://github.com/qt/qtbase/blob/dev/src/network/access/qhttpnetworkconnection.cpp#L68
Thanks, I will try immediately. But I want to know what's your philosophy to set the value 6 ? I know a book named "the philosophy of Unix" which explains many things at the top level. And I want to get the same philosophy from you.
I wasn't around when the choice was made so I don't know the definitive source, but it was chosen to be 6 since that matched what major browsers used at the time (and largely still do for HTTP 1) and was considered a reasonable fit for Qt as well.
https://stackoverflow.com/a/30064610/2493610
You are so kind and I now know everything about it. In fact, the browsers are the applications for the client, so they can set the value 6 because peoples havn't 20 or 1000 eyes (another reason is the work of rendering is heavy). But Qt is a neutral library, the developers should do what they want, only limited by OS or physical. So removing the limit is still a good idea, this is only my suggestion, you can do as you like.
Last question, if I modify it myself, set defaultHttpChannelCount = 1000 even 60000, that's enough? Should I modify the other things, by example, which are the best values for defaultPipelineLength and defaultRePipelineLength when HttpChannelCount is 1000 or 60000? Sorry I have troubled you so much. But this is really an interesting thing.
Right, as I mentioned earlier I haven't tried it myself, but in theory changing defaultHttpChannelCount is enough. Pipelining isn't enabled by default so unless you enable it it's not going to make a difference what you set those to. Do keep in mind that if you set it to 60000 then it will allocate 60000 channels as well, even if for some connections you only end up using 10. There might also be limits on the server on how many connections you, or perhaps anyone in total, can establish before they start getting dropped.
I recommend to vote and subscribe to and maybe comment on https://bugreports.qt.io/browse/QTBUG-25280 :-)
good to see that there's some work on QTBUG-86966 to provide infos on Network Connection State. really need this for nearly all of my apps.
Hi to all What I can use insteed of QNetworkConfiguration Thank you
QNetworkConfiguration has a few things available. There's no replacement for it in 6.0 though. What about QNC are you currently using?
Can be the linking between Qt Network and QML optional? I don't see why should I deploy Qt Network in an application that does not uses network capabilities at all.
Redirect not happening automatically and I can't seem to get it to work with any policy.
Where is the FTP plugin in Qt 6.1.2?
Still no FTP plugin or support in Qt 6.2?