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

开发环境:((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，阻塞读取数据。

5、断开则调用disconnectFromHost;

6、调用waitForDisconnected。

 

在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源码片段

 

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

qint64 QNativeSocketEnginePrivate::nativeBytesAvailable() const{    int nbytes = 0;    // gives shorter than true amounts on Unix domain sockets.    qint64 available = 0;#ifdef Q_OS_SYMBIAN    if (::ioctl(socketDescriptor, FIONREAD, (char *) &nbytes) >= 0)#else    if (qt_safe_ioctl(socketDescriptor, FIONREAD, (char *) &nbytes) >= 0)#endif        available = (qint64) nbytes;    return available;}

读取数据的步骤：

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网络的东西，可以搭建调试环境。自己调试来分析源码，查找原因。

 

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