2011-06-01 78 views
0

我在Linux上使用套接字,我想發送一個大表(超過2 Mb)而不丟失任何數據,並且足夠快以在客戶端上獲得流暢的視頻。 (即時消息發送是一個視頻流)。套接字:發送2Mb而不丟失數據

我已經嘗試了兩兩件事:

1°)發送整個表一次

socketError = send(newsockfd,(char*) DataTab,sizeof(DataTab),0); 
if (socketError < 0) 
    error("ERROR server writing to socket"); 

2°)發送由一個

for (int i=0; i<nbelem; i++) // nbelem is greater than 600'000 
{ 
    socketError = send(newsockfd,(char*) &DataTab[i],sizeof(&DataTab[i]),0); 
    if (socketError < 0) 
    error("ERROR server writing to socket"); 
} 

的元件中的一個發送表一次很快,但我失去了一些數據。

逐個發送元素工作正常,沒有數據丟失,但速度太慢。

所以我有兩個問題:什麼是可以在一個套接字中發送的數據的限制(以字節爲單位)?以及如何快速發送我的表格而不會丟失數據?

PS:我的方案都應該在本地comunicate,或以太網。互聯網溝通並不是設想的。

+6

爲什麼不建立在保證傳輸的TCP之類的面向連接的協議之上呢? – 2011-06-01 13:41:28

+0

「丟失數據」是什麼意思?你是否收到任何發送或接收錯誤?你使用的是TCP還是UDP? – 2011-06-01 13:45:48

+0

是否有任何錯誤?如果是這樣,爲什麼不檢查errno的價值,以便知道發生了什麼?如果沒有,爲什麼你認爲它是發送而不是接收的問題?你使用的是TCP還是UDP? – hplbsh 2011-06-01 13:46:07

回答

2

最簡單的答案:使用tcp socket:socket(AF_INET, SOCK_STREAM, 0)

更復雜的答案:如果你想使用udp,使用(或發明)一些協議與交付檢查,重發,並可能與擁塞控制。

1

一般來說,UDP是發送視頻流數據的好主意,因爲通常可以容忍丟失的視頻數據

如果你不能丟失數據,可以考慮使用TCP的建議!

可以通過UDP發送的最大數據包大小取決於網絡中使用的硬件,沒有固定的數字。如果您需要創建最佳數據包大小,則需要實施稱爲「MTU Discorvery」的操作。

如果你能買得起的好猜測,使包大小1492

編輯:

如果您使用的是Windows,考慮擴大接收緩衝區大小:

int bufferSize = 64 * 1024; // 64k 
setsockopt(socket, SOL_SOCKET, SO_RCVBUF, (char *) & bufferSize); 
+0

最大數據包大小不一,但最大的**數據報**大小沒有。它是64K。 UDP不支持在單個'send()'中傳輸2MB。 – 2011-06-03 13:34:03

0

網絡編程是棘手的,你可以考慮很多折衷。例如,如果你的服務器和客戶端在LAN或控制&可靠的廣域網都是,您可以使用UDP。這樣您就可以節省TCP的開銷,並且不會丟失大多數傳輸的數據。

如果正在通過Internet發送的視頻,你需要的可靠性,必須使用TCP。如果您使用TCP,然後就send()所有的數據一次。 TCP具有內置的可靠性和流量控制機制。在這種情況下加快數據傳輸的速度並不是很快。

您也可以考慮使用原始套接字,並實現自己的可靠性和流量控制。否則,請在您的應用程序上工作,以便即使存在一些丟失的視頻幀,它也可以正常工作。

0

那麼,如果你使用UDP或沒有,你沒有回答。如果你那麼這就是你的答案。 UDP的最大數據報大小是64K。所以它不支持2MB的send()。所以你需要做的第一件事(繼續使用UDP)將其分解爲64K或更少的塊。

但是,即使這也不是最理想的。這是因爲你的底層鏈路層可能不支持接近那麼大的數據包。 UDP通過將數據報分成數據包大小的傳輸來自動處理。但是,UDP非常簡單。如果這些數據包中的任何一個丟失或中斷,整個數據報必須被丟棄。另一方面,TCP會重發丟失的數據包。如果你的UDP數據報只有兩三個數據包,這可能不大。但是(假設標準數據大小爲1420左右),所有的傳輸都要求33個獨立的數據包中沒有47個IP數據包的呃逆。

既然你說你在一個私人網絡上,這可能並不重要。如果您可以控制網絡流量,那麼您可以通過在協議中確保沒有其他人嘗試使用該網絡來處理這些大型數據包。如果流量不是很大,一個好的快速智能交換機通常也會在局域網上處理這些問題。

這就是爲什麼許多人已經暗示,切換到TCP可能會更容易。它在協議中處理所有這些。