問題描述

我正在使用 C++ TCP/IP 套接字.根據(jù)我的要求，我的客戶端必須連接到服務(wù)器并讀取它發(fā)送的消息(這真的很新，不是嗎)但是......在我的應用程序中，我必須等待一段時間(通常為 1 - 2 小時)) 在我真正開始閱讀消息之前(通過 recv() 或 read())并且服務(wù)器仍然繼續(xù)發(fā)送消息.

I am using C++ TCP/IP sockets. According to my requirements my client has to connect to a server and read the messages sent by it (that's something really new, isn't it) but... in my application I have to wait for some time (typically 1 - 2 hrs) before I actually start reading messages (through recv() or read()) and the server still keeps on sending messages.

我想知道緩沖區(qū)的容量是否有限制，用于保存這些消息以防它們不被讀取，以及使用誰的物理內(nèi)存來緩沖這些消息?發(fā)件人還是收件人?

I want to know whether there is a limit on the capacity of the buffer which keeps those messages in case they are not read and whose physical memory is used to buffer those messages? Sender's or receiver's?

推薦答案

TCP 數(shù)據(jù)在發(fā)送方和接收方都被緩沖.接收方的socket接收緩沖區(qū)的大小決定了在沒有確認的情況下可以傳輸多少數(shù)據(jù)，發(fā)送方的發(fā)送緩沖區(qū)的大小決定了在發(fā)送方阻塞或獲得EAGAIN/EWOULDBLOCK之前可以發(fā)送多少數(shù)據(jù)，取決于阻塞/非阻塞模式.您可以將這些套接字緩沖區(qū)設(shè)置為您喜歡的大小，最大為 2^32-1 字節(jié)，但是如果您將客戶端接收緩沖區(qū)設(shè)置為高于 2^16-1，則必須在連接套接字之前這樣做，以便 TCP 窗口縮放可以在連接握手中協(xié)商，以便高 16 位可以發(fā)揮作用.[服務(wù)器接收緩沖區(qū)在這里不相關(guān)，但如果您將其設(shè)置為 >= 64k，則需要將其設(shè)置在偵聽套接字上，從那里它將被接受的套接字繼承，再次握手可以協(xié)商窗口縮放.]

TCP data is buffered at both sender and receiver. The size of the receiver's socket receive buffer determines how much data can be in flight without acknowledgement, and the size of the sender's send buffer determines how much data can be sent before the sender blocks or gets EAGAIN/EWOULDBLOCK, depending on blocking/non-blocking mode. You can set these socket buffers as large as you like up to 2^32-1 bytes, but if you set the client receive buffer higher than 2^16-1 you must do so before connecting the socket, so that TCP window scaling can be negotiated in the connect handshake, so that the upper 16 bits can come into play. [The server receive buffer isn't relevant here, but if you set it >= 64k you need to set it on the listening socket, from where it will be inherited by accepted sockets, again so the handshake can negotiate window scaling.]

然而，我完全同意 Martin James 的觀點，即這是一個愚蠢的要求.它在服務(wù)器上浪費一個線程、一個線程堆棧、一個套接字、一個大套接字發(fā)送緩沖區(qū)、一個 FD 和所有其他相關(guān)資源兩個小時，并可能影響其他線程，從而影響其他客戶端.它還錯誤地給服務(wù)器一個印象，認為已經(jīng)接收了兩個小時的數(shù)據(jù)，而實際上它只是傳輸?shù)浇邮站彌_區(qū)，這可能會導致恢復情況下的未知并發(fā)癥:例如，服務(wù)器可能無法重建之前發(fā)送的數(shù)據(jù).您最好在準備好開始接收數(shù)據(jù)之前不要連接，否則在客戶端讀取數(shù)據(jù)并將其假脫機給自己以備后用.

However I agree entirely with Martin James that this is a silly requirement. It wastes a thread, a thread stack, a socket, a large socket send buffer, an FD, and all the other associated resources at the server for two hours, and possibly affects other threads and therefore other clients. It also falsely gives the server the impression that two hours' worth of data has been received, when it has really only been transmitted to the receive buffer, which may lead to unknown complications in recovery situations: for example, the server may be unable to reconstruct the data sent so far ahead. You would be better off not connecting until you are ready to start receiving the data, or else reading and spooling the data to yourself at the client for processing later.

這篇關(guān)于C++ 套接字編程 TCP/IP 套接字緩沖區(qū)的最大大小?的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網(wǎng)！