@jeremy_k said in TCP connection with changing IP addresses:

You guys are seriously pessimistic about the state of end-to-end connectivity!

I am sysadmin with over 20y of experience. "I've seen things you people wouldn't believe", to quote a classic.
Serious note aside - the fact that something is possible doesn't mean one should try it. There's lots of "it depends on the use case" but I've had large enough share of commercial products with design compromising network security. That "pessimism" is perfectly warranted.

More to the topic - I personally think the OP's design is abysmal in terms of security. Can they make it work? But of course. Would I allow such a solution in the network I manage? Under no circumstances.
My advice here would be for the clients to report to the server's API at certain intervals, doing push-pull (so server would need a queue). Let's leave p2p connections for the LAN games.

Other than that I think one can make it using UPNP, where target IP is safely obtained from the server's API together with a shortlived key used to validate incoming connection on the other end, but that's borderline already.

I tested it with my hardware an now it works! Thanks for helping me out!

@Sajjad-Ali Quite apart from @JonB's observations:

Your receiver is not listening. You need to look at QTcpServer You need to ensure that the receiving end does not have a system firewall blocking whatever port you are listening on.

@Prakash08
Sorry, but you're wrong. @Christian-Ehrlicher & I have both tried to point this out to you.

First of all, QMediaPlayer *player = new QMediaPlayer is a pointer to an allocated object on the heap. That means it persists until something deletes it. The fact that QMediaPlayer *player is itself a local variable is neither here nor there, when it goes out of scope that does not destroy the object it points to. That is quite different from QBuffer buffer(&received_data), which is a local stack variable, not a pointer to an object. That does get destroyed at the end of the if.

Secondly, player->setMedia(QMediaContent(), &buffer) means that player is using the stack buffer, so as soon as the if exits buffer is destroyed but the QMediaPlayer is still using it as its buffer. When you go player->play() at the end that only starts playing the video, it does not finish playing it. It carries on playing after the function exits. But it's reading from a buffer which has now been destroyed. Not good! Lucky it does not "crash". Your "Error:failed to seek" error may be from code trying to access it when it is no longer valid.

This is all standard C++ stuff.

@Christian-Ehrlicher yes, this works perfectly.

I am beginning to understand transactions as well, although it warrants further study. Thank you for the pointers, I appreciate it!

@Narutoblaze
Then no you cannot, as you can see in the documentation for QTcpSocket/ QAbstractSocket. If there were a method which took a "connection name" you would see it documented.

There is nothing to stop you writing your own code to store connections indexed by some "connection name" you choose, e.g. using a QMap Class.

@Narutoblaze
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.

@Dariusz said in Deleting QTcpSocket cause app crash:

My MainA is a QSharedPointer<>, Here is the picture of log >

I hope you have create it like this QSharedPointer<MainA>(new MainA(), &QObject::deleteLater);

It looks to me like extraData can be invalid & cause the core crash?
Given my complex thread logic... it may be a bit difficult to reproduce it.
I do quite few of

if (mSocketPtr) { QMetaObject::invokeMethod(this, [this]() { QMetaObject::invokeMethod(mSocketPtr, [this]() { mSocketPtr->setParent(this); }, Qt::QueuedConnection); }, Qt::QueuedConnection); }

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:

if(mSocketPtr && mSocketPtr->parent() != this) { if(mSocketPtr->thread() != this->thread()) { QMetaObject::invokeMethod(mSocketPtr, [this]() { mSocketPtr->moveToThread(this->thread()); mSocketPtr->setParent(this); }); } else mSocketPtr->setParent(this); }

@duckrae List your client with id, when you are getting new incomingConnection. server can reply as per client id to a specific client or reply to all.

@J-Hilk thanks for your comment. I put that to read continuously from the buffer, but of course it is not necessary as soon as the signal/slot mechansim works.

@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 >
319d7357-9211-4008-ad08-dde32da2cfc0-image.png
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 >

accept connections, 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.

@jsulm Silly me, I always went straight to QAbstractSocket from that page... thanks!

@Dariusz said in How to properly delete threads& objects in them ?:

So in general, moving object to another thread does not set the thread as it parent does it.

No because the function is called moveToThread and not moveToThreadAndDoOtherStuffLikeSettingaParent

@Dariusz said in QtcpSocket states & disconnect signal:

QAbstractSocket::UnconnectedState

As per Qt Docs

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().

My dumb ass set the socket thread to nullptr 1 function before and then I was scratching my head why thread() was retuning QObejct(0x0) and I could not test against nullptr/etc... I'm gifted

Sorted.

Solved.
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! :- )

@BodyaGunko
Hi and welcome.

That's what running a web/HTTP server and exposing the IP over the Internet allows, from any client with a web browser.