Your code/algorithm is incorrect. This is basic coding, please study what your code does. You "actively" encourage reading across file boundaries, i.e. what you call "too much").
You (seem to) start by setting size to the total number of bytes expected for the file. Then you call read(buffer, size);. But when that returns with fewer bytes than size you still call it again next time round asking it to read up to size further bytes. This can/will exceed the number of bytes in the first file. You obviously need to reduce what size you pass to read() accordingly on subsequent calls. And then be careful what you compare in your if (... || numReadTotal == size). Adjust your code however to make it right.
I previously said that the whole synchronous approach of repeatedly calling waitForReadyRead() in a loop is not the event-driven way to do things. Allow bytes to arrive in repeated readyRead() signals asynchronously instead.
The issue is that you are handling the incoming data as if you would get full frames every time you receive something. There's no guarantee for that. Hence you should fix your buffer usage. Cumulate all the data until you know you have a full frame ready to be parsed further.
I do not understand this!
If you want to change parent for a class instance, why do it so complicat?
Setting parent can only be done if children and parent in same thread, but it muss not be done in the work thread!
I would do it like this:
@VRonin yes thats right. But the example here is simplified to the bone to track down that evil issue...
Currently my server in release mode with profiler enable pushes around 3000 connections in 592ms, so 6k per second +/-... I've no idea if thats good or bad, But looking at profiler >
The top green are new connection handlers, all it does is grab a handle > pushes it to vector. Its about 0.001 ms
the second row is the creation of objects for each handle, which is done in worker and the "tall" one are all the pragma omp helping multithread different parts of app.
Seems pretty fast given that in that time >
push them to monitor for display to show that there are new connections - this is batched too
Set connections details from packed I received
Validate connection credentials
some more work.
Yeah, I'm amazed o.o, but I have no idea if thats good/bad performance-wise. Learning networking here lol. Possibly 360k Connections /validations/ displaying per minute ? I can't spawn enough test connections per second to test how much can I push lol.
To close the socket, call disconnectFromHost(). QAbstractSocket enters QAbstractSocket::ClosingState. After all pending data has been written to the socket, QAbstractSocket actually closes the socket, enters QAbstractSocket::UnconnectedState, and emits disconnected().
First enters the state then emits the signal,
In this case UnconnectedState state and then emits disconnected().
For some reason one of my QThread workers send a message on socket and did not post it to Socket thread... that caused it to internally "crash" without telling any1 about it and thus became "broken" internally. Once I posted it to correct thread everything started to work again... sigh! :- )
and used server application from the link above at receiver end.
this works well. I have tested this with JSON file having 3000 object. Will this work for 50,000 samples and more possibly 1500000 objects?