kandi X-RAY | client_ui Summary
kandi X-RAY | client_ui Summary
client_ui
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of client_ui
client_ui Key Features
client_ui Examples and Code Snippets
Community Discussions
Trending Discussions on client_ui
QUESTION
I have been stuck on this for the past 5 days, I have no idea how to proceed.
Overview:
I have a client UI
which interacts with a data handler
library, and the data handler
library utilizes a network manager
library, which is where my problem lies.
More Info
Firstly, QT provides a basic example for interactions between a QTcpServer
(Fortune Server)and a QTcpSocket
(Fortune Client).
I thus implemented this code into an extremely basic example of my own, which works like a charm and has no issues.
My own adaption of fortune client and server for the record (basic)
Quick Explaination:
Server application runs, click on start server
, then on the client side, enter text in field and click connect to server
and text is displayed, easy!
Problem:
Implementing the code above into my network manager
library, does not fire the QTcpSocket::readyRead()
in the server application above.
It connects to the server
, where the QTcpServer::newConnection()
is fired, as expected, straight after which the client
writes to the socket but the readyRead()
on the server socket does not fire, however in the example given it does.
Note:
The same port
and ip address
is used in this server-client
application example and my current application, and the server is also running.
Further Information:
From the above code, I copied over directly from the client. Only 2 things were changed/modified:
- String that is sent to server
- return types for method
This was copied into my network mannager ::write()
method. When running my application, and instance of QMainWindow
is passed via data handler
class and creates an instance of my network manager
class which inherits QObject
and implements the Q_OBJECT
macro.
Code Examples:
//client_UI
Class (snippet):
ANSWER
Answered 2017-Feb-06 at 19:45Add a tcp_con->flush()
statement to the end of your write function.
You weren't getting a readyRead
signal in your receiver because the written data was being buffered into the socket but not actually transmitted 'over the wire'. The flush()
command causes the buffer to be transmitted. From the docs
How are you supposed to knowThis function writes as much as possible from the internal write buffer to the underlying network socket, without blocking. If any data was written, this function returns true; otherwise false is returned.
In my case a lot of experience/frustration with serial ports and flushing. It's the equivalent of "have you rebooted it?" in the socket debugging toolbox.
If everything else is working fine, you may not have to flush
, but it's kind of application specific and depends on the lifetime of the socket, the TCP window size, socket option settings, and various other factors. That said, I always flush because I like having complete control over my sockets, and I want to make sure data is transmitted when I want it to be. I don't think it's a hack, but in some cases it could be indicative of some other problem. Again, application specific.
I'm pretty sure no flush is needed in the fortune server example because they disconnectFromHost
at the end of the sendFortune()
function, and from the Qt documentation:
Attempts to close the socket. If there is pending data waiting to be written, QAbstractSocket will enter ClosingState and wait until all data has been written.
The socket would disconnect if it were destroyed as well, but from what I can see of your code you aren't doing that either, and the buffer isn't full, so probably nothing is actually stimulating the buffer to flush itself.
Other causes can be:
- flow control isn't returned to the event loop (blocking calls, etc), so the buffer flush is never performed.
- Transmit is occuring inside of a loop, which seems like it will exit (e.g.
while(dataToTransmit)
), but in fact the condition never becomes false, which leads to the event loop being blocked. - Nagles algorithm: the buffer may be waiting for more data before it flushes itself to keep network throughput high. You can disable this by setting the
QAbstractSocket::LowDelayOption
, but it may adversely affect your throughput... it's normally used for latency-sensative applications.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install client_ui
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page