summaryrefslogtreecommitdiffstats
path: root/doc/networking.doc
diff options
context:
space:
mode:
authorTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-05 22:04:08 -0600
committerTimothy Pearson <kb9vqf@pearsoncomputing.net>2011-12-05 22:04:08 -0600
commite02e31c8b9d854cd62cbe9799228f6e08e882773 (patch)
tree53303c981d0b20e03c5a2fc8e959fa74adcb90d1 /doc/networking.doc
parent143f194af098d44bf0dd1ebb29e59f30ce48d523 (diff)
downloadtqt3-e02e31c8b9d854cd62cbe9799228f6e08e882773.tar.gz
tqt3-e02e31c8b9d854cd62cbe9799228f6e08e882773.zip
Sync with latest script
Diffstat (limited to 'doc/networking.doc')
-rw-r--r--doc/networking.doc8
1 files changed, 4 insertions, 4 deletions
diff --git a/doc/networking.doc b/doc/networking.doc
index 6d88a1975..99d3ceb2a 100644
--- a/doc/networking.doc
+++ b/doc/networking.doc
@@ -40,7 +40,7 @@ refer to them her.
The QSocket and QServerSocket classes provide an easy-to-use
API for client and server socket programming.
-These classes retquire an event loop and must be used within an
+These classes require an event loop and must be used within an
application's GUI thread. They are ideal for end-user
applications that need network access, but they are not suitable for
console applications or for high performance daemons (services).
@@ -253,7 +253,7 @@ This function sends a command to the server. Notice that is uses QTextStream to
\printline }
\printline }
-Here we parse responses from the server. It's worth noting again that the communication is asynchronous and it must not be assumed when and how the data will come. The fact that server socket sends all data lines at once (in one loop) does not mean that client socket will receive them as one package and emit one readyRead() signal. That is why we designed our protocol to have termination line , with M = ' ' (e.g. "213 "). In this example the line code will determine its destination (infoList or infoText), but in more advanced usage client would probably retquire some sort of the finite state machine, as we'll se in the next example.
+Here we parse responses from the server. It's worth noting again that the communication is asynchronous and it must not be assumed when and how the data will come. The fact that server socket sends all data lines at once (in one loop) does not mean that client socket will receive them as one package and emit one readyRead() signal. That is why we designed our protocol to have termination line , with M = ' ' (e.g. "213 "). In this example the line code will determine its destination (infoList or infoText), but in more advanced usage client would probably require some sort of the finite state machine, as we'll se in the next example.
\skipto ::socketConnectionClosed()
@@ -275,7 +275,7 @@ Protocol) is declared (\c network/infoprotocol/infourlclient/qip.h):
\skipto Qip
\printuntil };
-QNetworkProtocol is the base class for every Network Protocol class. Because this protocol uses network, we embedded one QSocket* member variable to which we'll delegate network communication. Protocols that doesn't retquire to use network will do it on their own way - e.g. QLocalFs uses QDir, some data actquisition protocol may use serial or USB connection, only retquirement is that protocol uses hierarchical structure and can be accessed using URLs (to have addressable nodes).
+QNetworkProtocol is the base class for every Network Protocol class. Because this protocol uses network, we embedded one QSocket* member variable to which we'll delegate network communication. Protocols that doesn't require to use network will do it on their own way - e.g. QLocalFs uses QDir, some data actquisition protocol may use serial or USB connection, only requirement is that protocol uses hierarchical structure and can be accessed using URLs (to have addressable nodes).
Let us go to the Qip implementation (\c
network/infoprotocol/infourlclient/qip.cpp):
@@ -310,7 +310,7 @@ Here we implement two supported operations. QUrlOperator is class that initiated
\printuntil }
\printuntil }
-Implementation is very similar to previous example in addition that there are now some signal emitting retquirements, so we had to use simple state machine here. In list operation we have to emit start(QNetworkOperation*) before first child, and then to emit QNetworkProtocol::newChild (const QUrlInfo&, QNetworkOperation*) for each child listed from the server. For get operation, we should emit QNetworkProtocol::data (const QByteArray&, QNetworkOperation*) for each data chunk received (in this case, one text line). It is very important that \e every operation finishes with QNetworkProtocol::finished(QNetworkOperation*) signal!
+Implementation is very similar to previous example in addition that there are now some signal emitting requirements, so we had to use simple state machine here. In list operation we have to emit start(QNetworkOperation*) before first child, and then to emit QNetworkProtocol::newChild (const QUrlInfo&, QNetworkOperation*) for each child listed from the server. For get operation, we should emit QNetworkProtocol::data (const QByteArray&, QNetworkOperation*) for each data chunk received (in this case, one text line). It is very important that \e every operation finishes with QNetworkProtocol::finished(QNetworkOperation*) signal!
\skipto error
\printuntil state