前一段时间通过调试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，阻塞读取数据。
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