Please let me explain what is my problem:
I have a Gui application, that has to connect to remote server and keep connected to it for the time untill a user decides to quit the connection, or the server will. I wish to create the client connection mechanism in a separate thread. If the client should be able to asynchronusly receive data and in event driven style inform the main gui thread about it. The thread should also be able to receive data from gui thread to be sent to the server.
I come from a low level microcontroller place, where I would handle this task simply using interrupts and while(1) loop and flags. The problem is on a pc, this would take to much processor time. I have watched and read a lot of tutorials about sockets and threads in qt, but i still dont know what is the best aproach and how to do it properly.
For now, I have a test server on a remote target that is able to receive connections from my Qt client that I am trying to write. I have a class now for my client in Qt, that inherits from Qthread, but then I read that it is not the best aproach anymore.
I wish to create a client instance in new thread (triggered from the gui thread) that will hang forever with exec(). Now I dont know how to handle, using signals the incoming data from the server and incoming commands from the main GUI thread. In general, I would maybe know how to implement this on a low level, but i read about a lot of high level functions for this that qt delivers, i wish to use that.
I would really aprichiate help in this matter. I tried searching, but havent found any solid, working up to date code examples. Could someone please explain me how to create a client instannce in a new thread that wont disconnect after sending/ receiving some data, but instead stay connected and stay responsive to to server calls and gui thread calls in event driven style?
May be use general Qt socket mechanism instead separate thread will be better for you. Sockets is very similar to MCU interrupts and simple to use. For your application requests it must be enough.
Related
I have a simple Client application (using QWebSocket) that wants to connect to my server application (i.e. QWebSocketServer).
When I open a connection to a webSocketServer that is down/unavailable, my webSocket fires a "disconnectd" signal after 30 sec.
This is good as it helps me to understand that the server is down/unavailable so I can retry or warn the user about the problem.
If the link between the client and server fails the same thing happens. i.e. after writing (sendBinaryMessage) to the webSocket causes the disconnected signal to be fired after 30 secs.
I would like to know what are the default timers in QWebSocket and how I can modify them?
Where can I find such information/documentation? The Qt documentation on webSockets does not mention this behaviour at all! Should I read the code or ...?!
Thanks in advance
I doubt that any of these timers are part of Qt; these timers exist as part of the underlying operating system's implementation of TCP/IP. A socket waiting for a connection to time out will eventually go bad if the remote end does not respond. Same if a sent data is not acknowledge after a reasonable amount of time.
Qt however does everything asynchronously and makes use of signals and slots to notify you when something has happened. This means that if you want to shorten a timeout the simplest way to do this is using a QTimer that runs in parallel to you QAbstractSocket, if the timer times out before the socket signals its response, you can then take appropriate action.
Failing that, there may be some socket options that allow you to set the various timeouts on your TCP Connection to your liking.
From QWebSocket:
This class was modeled after QAbstractSocket.
QAbstractSocket in turn inherits from QIODevice.
The documentation of these classes have some information about timeouts.
Specifically you can see the default of 30 seconds pop up here and there.
Another place to look at is QObject's documentation (QWebSocket inherits it). Perhaps by overriding QObject's timer-related virtual functions you can somehow get in between these mechanisms and perhaps change the timeout.
Sorry to not be of more help.
I am writing an QT desktop application that is going to display information received from a serial port. Therefore a class was created and packed into an DLL using standard Windows API features to communicate with the connected device (CreateFile, ReadFile, WriteFile, ...).
At the moment a timer calls the DLL at a predefined rate [< 200ms] and this leads the gui to freeze for short periods. Because of that i am thinking of using a thread to do the serial port stuff, that is also going to display everything.
Is is better to use threads for this problem or should i rewrite the class to do the work event based? The target is, that the gui doesnt freeze.
Edit:
I solved the problem using a QThread derived worker class with an overshadowed run() function, that handles the serial port communication in the background and updates the gui as new informations are available.
It is good practice in many use cases to do all blocking (synchronous) I/O on a separate thread, especially when a graphical user interface is involved. Here's a page I've referenced regarding the challenges with synchronous I/O (as opposed to asynchronous where your code doesn't block but is still single-threaded, or parallel as you're discussing). There are more issues than just what you brought up, for example:
What if there is no data available? Does the GUI block until there is data? For example, if the sender was off then there would be no data
What does the program do if the I/O device is no longer available? For example, if it is a USB-to-serial adapter, what happens if the adapter is unplugged?
I'm new to Poco framework and not to good with C++ but I am learning. I have to create a server-client based application in windows.
The problem that I have now is that I need to send repeatedly from minute to minute some data to the clients. i need to do this for the clients that have an active tcp connection with the server. I don't know how can I create an event, or something that is triggered in a thread and starts all the active threads to send data to the clients.
My first idea is that I have to rewrite, or extend the TCPServerDispatcher Class. And I don't know how can I identify the active threads from the ThreadPool.
Do you have any ideas, or maybe suggestions, or a tutorial, something?
I can't figure it out how to do it...
Hope somebody can give me an idea, or some code example. Thank you.
Can these server<> client threads not obtain the data for themselves? It would be fairly easy to add a 60-second timeout on a read() in each thread and send the data then. Maybe this would involve too many database connections?
Failing that, can you put the latest data in a lockable object and have the threads just lock, write and unlock the latest data on a timeout? Such a solution should really have a write timeout as well to prevent a badly-behaved client causing its server thread to block while holding the lock. If it's not too large, I suppose the server<> client thread could make a copy of the data to send, but I'm not a great fan of copying, TBH.
There are more complex ways of signaling the server<> client threads that new data is avalable. It is quite possible to signal each thread that new data is available and have them act upon it 'immediately'. This usually means the server<> client thread waiting on more than one signal. In general, the lower the latency, the more complex the solution:(
Rgds,
Martin
Hey I am not sure if this has already been asked that way. (I didn´t find anwsers to this specific questions, at least). But:
I have a program, which - at startup - creates an Login-window in a new UI-Thread.
In this window the user can enter data which has to be verified by an server.
Because the window shall still be responsive to the users actions, it (ofc it´s only a UI-thread) shall not handle the transmission and evaluation in it´s own thread.
I want the UI-thread to delegate this work back to the main thread.
In addition: The main thread (My "client" thread) shall manage all actions that go on, like logging in, handle received messages from the server etc... (not window messages)
But I am not sure of how to do this:
1.) Shall I let the UI-Thread Queue an APC to the main thread (but then the main thread does not know about the stuff going on.
2.) May I better use event objects to be waited on and queues to transmit the data from one thread to another?...
Or are there way better options?
For example: I start the client:
1. The client loads data from a file and does some intialization
The client creates a window in a new thread which handles login data input from the user.
The Window Thread shall notifiy and handle the , that has been entered by the user, over to the client.
The Client shall now pack the data and delegate the sending work to another object (e.g. CSingleConnection) which handles sending the data over a network (of course this does not require a new thread, because it can be handle with Overlapped I/O...
One special receiver thread receives the data from the server and handles it back to the client, which - in turn - evaluates the data.
If the data was correct and some special stuff was received from the server, the main thread shall signal the UI thread to close the window and terminate...
The client then creates a new window, which will handle the chatting-UI
The chatting UI thread and the Client thread shall communicate to handle messages to be sent and received...
(Hope this helps to get what I am trying)...
It all depends on what you are prepared to use. If you are developing with Qt, their signals and slots are just the thing to do such a communication. They also supply a network library, so you could easily omit the receiver thread because their network classes do asynchronous communication and will send a signal when you have data, which means your thread does not need to be blocked in the mean time.
If you don't want to use Qt, boost also supplies thread safe signals and slots, but as far as I understand it their slots will be run in the context of the calling thread...
Anyways, I have used Qt sig and slots with great satisfaction for exactly this purpose. I wholeheartedly agree GUI's shouldn't freeze, ever.
I don´t know wether this is good style or not (anwsering Your own question):
But I think I go with Event Objects and two queues (one for the connection between Client and Connection, and one to communicate Client and UI)...
I have a game I am working on in C++ and OpenGL. I have made a threaded server that right now accepts clients (the game) and receives messages from them. Right now the game only sends messages. I want both the game and server to be able to send and receive, but I'm not sure the best way to go about it. I was considering using a thread for sending and one for receiving, both on the same socket. Right now the game runs in a single thread, and the server makes a separate thread for each client.
Looking for suggestions on how to go about it for the game as well as the server (unless your suggestion is the same for both). Any questions, feel free to ask :)
Thanks!
What you need to do is set up an outgoing queue of messages for each client. Say you have 2 clients connected to the server, one being serviced by thread A and the other by thread B. Thread A should do a WaitOnMultipleObjects() on its socket and on a semaphore/mutex/condition variable for its queue. That way, if it gets something in its queue, it can wake up and send it out. If it gets a message from the client that it needs no give to client B, it will process that message and put it in thread B's outgoing queue.
This is a very simple synchronization scheme. If your game is very complex or massive, you will have to do something much more clever than this.
Don't use threads in a game server. Many professional, AAA game servers are single-threaded - every one I've ever seen, in fact.
Consider using Boost.ASIO that implements this well with a C++ API (allowing many different approaches besides just asynchronous I/O). There are plenty of tutorials. However, for the absolute highest performance, you should probably not use threads.