Qt网络编程QTcpServer和QTcpSocket的理解【转载】

前一段时间通过调试Qt源码，大致了解了Qt的事件机制、信号槽机制。毕竟能力和时间有限。有些地方理解的并不是很清楚。

开发环境:linux((fedora 17),Qt版本(qt-everywhere-opensource-src-4.7.3)。

Qt网络编程比较常用的两个类：QTcpServer和QTcpSocket。当然还有UDP的类(在这就不介绍了）。

这两个类的操作比较简单。

QTcpServer的基本操作:

1、调用listen监听端口。

2、连接信号newConnection，在槽函数里调用nextPendingConnection获取连接进来的socket。

QTcpSocket的基本能操作：

1、调用connectToHost连接服务器。

2、调用waitForConnected判断是否连接成功。

3、连接信号readyRead槽函数，异步读取数据。

4、调用waitForReadyRead，阻塞读取数据。

在main函数中调用 app.exec()之后会进入事件循环。在Qt的事件循环中回调用QEventLoop::processEvents。在这个函数中又会调用QAbstractEventDispatcher::processEvents。

Qt为不同的平台，提供了不同的EventDispatcher。本人用的是linux。接下来会调用QEventDispatcherUNIX::processEvents。doSelect，select。

通过调试源码可以证实，函数调用的顺序。其实Qt网络编程，底层是通过select实现的。可能跟跨平台有关系吧，采用select。linux有比select更好的API(poll,epoll)。

通过调试，可以发现newConnection和readyRead这两个信号都和select有关系。

因为调用的是select所以服务器端肯定会有监视文件描述符数量问题。select默认的是1024。Qt默认的也是1024。服务器端在调用nextPendingConnection。会创建一个QTcpSocket对象。这个对象在QTcpServer对象删除的时候会自动删除。也可以手动删除，避免浪费内存，可以在该对象断开的时候，删除该对象。该对象在断开的时候，select调用会清除该描述符，不会影响文件描述符的数量。如果内存足够用的话，不需要关心该对象。

接下来介绍readyRead信号。该信号用的比较多。

该信号当有数据要读的时候，会触发该信号。不过在触发该信号之前，Qt会尝试读取bytesToRead数据，存在内部缓冲区中。

下面是Qt源码片段

[cpp]  view plain  copy

1.     qint64 bytesToRead = socketEngine->bytesAvailable();  
2. #ifdef Q_OS_LINUX  
3.     if (bytesToRead > 0) // ### See setSocketDescriptor()  
4.         bytesToRead += addToBytesAvailable;  
5. #endif  
6.     if (bytesToRead == 0) {  
7.         // Under heavy load, certain conditions can trigger read notifications  
8.         // for socket notifiers on which there is no activity. If we continue  
9.         // to read 0 bytes from the socket, we will trigger behavior similar  
10.         // to that which signals a remote close. When we hit this condition,  
11.         // we try to read 4k of data from the socket, which will give us either  
12.         // an EAGAIN/EWOULDBLOCK if the connection is alive (i.e., the remote  
13.         // host has _not_ disappeared).  
14.         bytesToRead = 4096;  
15.     }  
16.     if (readBufferMaxSize && bytesToRead > (readBufferMaxSize - readBuffer.size()))  
17.         bytesToRead = readBufferMaxSize - readBuffer.size();  
18.   
19.     // Read from the socket, store data in the read buffer.  
20.     char *ptr = readBuffer.reserve(bytesToRead);  
21.     qint64 readBytes = socketEngine->read(ptr, bytesToRead);  
22.     if (readBytes == -2) {  
23.         // No bytes currently available for reading.  
24.         readBuffer.chop(bytesToRead);  
25.         return true;  
26.     }  
27.     readBuffer.chop(int(bytesToRead - (readBytes < 0 ? qint64(0) : readBytes)));  

[cpp]  view plain  copy

1. qint64 QNativeSocketEnginePrivate::nativeBytesAvailable() const  
2. {  
3.     int nbytes = 0;  
4.     // gives shorter than true amounts on Unix domain sockets.  
5.     qint64 available = 0;  
6. #ifdef Q_OS_SYMBIAN  
7.     if (::ioctl(socketDescriptor, FIONREAD, (char *) &nbytes) >= 0)  
8. #else  
9.     if (qt_safe_ioctl(socketDescriptor, FIONREAD, (char *) &nbytes) >= 0)  
10. #endif  
11.         available = (qint64) nbytes;  
12.   
13.     return available;  
14. }  

读取数据的步骤：

1、通过ioctl获取系统能够读取的数据长度。

2、在linux系统中多加4K数据(跟linux域套接字有关系)。

3、如果调用setReadBufferSize()设置缓冲区大小的话。重新计算bytesToRead。从代码中可以看出来，只有bytesToRead大的话，才重新计算。如果readBufferMaxSize设置过大，不会重新计算。

4、调用read函数尝试读取bytesToRead长度数据。返回实际读取的数据长度readBytes。通过调试可以看出readBytes和bytesToRead相差并不是很多。

bytesAvailable()函数返回缓冲区长度。如果没设定readBufferMaxSize，该函数返回值主要取决于ioctl系统调用。该系统调用跟系统当前运行的状态有关系。

可能会出现的问题：

1、当触发readyRead信号，但是缓冲区的长度小于另一端发送的数据。这样就会触发多次readyReady信号。如果一次槽函数里面读取缓冲区的长度，数据就会接受不全，进行数据处理肯定会出问题。Qt的例子中提供了一种方法。在发送数据的头部加上数据的长度。只有当bytesAvailable大于数据的长度时，才读取数据。

2、系统API里面调用read是从系统缓冲区里面读取数据。如果系统缓冲区满的话。以前的就会被覆盖。但是Qt里面也存在缓冲区。如果一端发送数据。另一端并不从Qt缓冲区读取数据。那么Qt就会无限制的从系统缓冲区中读出数据放置自己内部缓冲区。最后肯定会出现堆栈满的情况,系统异常退出。

想进一步了解Qt网络的东西，可以搭建调试环境。自己调试来分析源码，查找原因。

转载自：https://blog.csdn.net/ying_593254979/article/details/17006507