亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: tcp可靠性的問題 [打印本頁]

作者: alwaysR9 時(shí)間: 2015-07-03 10:55
標(biāo)題: tcp可靠性的問題
本帖最后由 alwaysR9 于 2015-07-03 10:55 編輯

unix socket編程，采用tcp協(xié)議

我的問題是：
假設(shè)客戶端寫入socket的數(shù)據(jù)是1024B，服務(wù)器采用select等待讀事件，
會(huì)不會(huì)出現(xiàn)先到達(dá)服務(wù)器的一部分?jǐn)?shù)據(jù)進(jìn)入socket的等待讀取隊(duì)列，并將select喚.醒的情況；
還是tcp協(xié)議可以保證只有全部數(shù)據(jù)都到達(dá)服務(wù)器端，才將數(shù)據(jù)放入socket的等待讀取隊(duì)列，并喚.醒select

希望大家能從原理上給出解釋

作者: hellioncu 時(shí)間: 2015-07-03 11:07
TCP是流，所以是前者

作者: windoze 時(shí)間: 2015-07-03 11:44
TCP的“可靠性”指的是：
1、連接故障在一個(gè)特定的時(shí)間范圍內(nèi)一定能被雙方感知
2、在連接無故障的前提下，傳輸數(shù)據(jù)不會(huì)錯(cuò)亂。
3、傳輸數(shù)據(jù)如果出現(xiàn)錯(cuò)亂，能被接受方發(fā)現(xiàn)。（理論上說可能出現(xiàn)發(fā)現(xiàn)不了的數(shù)據(jù)錯(cuò)亂，但這個(gè)概率一般可以忽略）

你自己體會(huì)一下應(yīng)該是哪種情況。

作者: alwaysR9 時(shí)間: 2015-07-03 11:52
回復(fù) 2# hellioncu

也就是說，操作系統(tǒng)(或者協(xié)議)會(huì)把接收到的數(shù)據(jù)直接放入對(duì)應(yīng)的socket中？

這樣是不是只能從socket中讀出一部分?jǐn)?shù)據(jù)？

底層過程還是不太明白，能仔細(xì)講一下嗎，或者看什么書或材料能幫助我弄清底層的過程？

作者: foolishx 時(shí)間: 2015-07-03 13:03
我記得**select的觸發(fā)方式有兩種吧：邊緣觸發(fā)，水平觸發(fā)。不同的觸發(fā)方式，使用不同的策略來保證讀取數(shù)據(jù)的完整性。

作者: hanzhenlll 時(shí)間: 2015-07-03 16:21
ET LT 是epoll的概念吧,,, select 只是輪詢查看fd 有沒有數(shù)據(jù)來而已， TCP能保證送到對(duì)端緩沖區(qū)是完整的，而select 讀取的是緩沖區(qū)數(shù)據(jù)，這時(shí)候如果恰巧有一半的數(shù)據(jù)來那就讀取出一半的數(shù)據(jù)，再select 還會(huì)發(fā)現(xiàn)有可讀數(shù)據(jù) 還能讀出剩余的數(shù)據(jù)。

這種情況多發(fā)生在單次發(fā)送大于MTU并且快速再次發(fā)送的情況。

作者: alwaysR9 時(shí)間: 2015-07-03 18:32

hanzhenlll 發(fā)表于 2015-07-03 16:21
ET LT 是epoll的概念吧,,, select 只是輪詢查看fd 有沒有數(shù)據(jù)來而已， TCP能保證送到對(duì)端緩沖區(qū)是完整的，而 ...

也就是說，tcp協(xié)議可以保證發(fā)送數(shù)據(jù)的完整性，但有可能一部分?jǐn)?shù)據(jù)先到達(dá)對(duì)端，并觸發(fā)對(duì)端的“讀事件”，其余數(shù)據(jù)到達(dá)對(duì)端再次觸發(fā)“讀事件”。
如果這樣，接收端有時(shí)候是不是需要為每一個(gè)socket分配一個(gè)緩沖，把socket中的數(shù)據(jù)讀到緩沖，當(dāng)緩沖包含完整數(shù)據(jù)才處理，緩沖中的數(shù)據(jù)不完整暫不處理

作者: alwaysR9 時(shí)間: 2015-07-04 00:01
如 hellioncu 和 hanzhenlll 所說，我寫了個(gè)程序驗(yàn)證了一下，確實(shí)如此。

服務(wù)器端用epoll等待事件，服務(wù)器端的socket用非阻塞式的；
客戶端發(fā)送一個(gè)很長的文本。

確實(shí)一部分?jǐn)?shù)據(jù)先到達(dá)服務(wù)器并**了epoll，剩下的數(shù)據(jù)到達(dá)服務(wù)器再次**epoll。
感謝樓上的各位

作者: 魔鬼的驚嘆 時(shí)間: 2015-07-05 16:12
第一種吧，網(wǎng)絡(luò)中的數(shù)據(jù)包在內(nèi)核中是skb形式來傳遞的，當(dāng)接收端收到后skb后會(huì)放在接收隊(duì)列，貌似沒有接收到全部數(shù)據(jù)才放到接收隊(duì)列。
用select 的話，貌似是從fd可以讀取東西就會(huì)**。

作者: alwaysR9 時(shí)間: 2015-07-05 16:46
回復(fù) 9# 魔鬼的驚嘆

謝謝，是不是內(nèi)核接收到的數(shù)據(jù)直接放進(jìn)對(duì)應(yīng)socket的接收隊(duì)列里，中間沒有緩沖？

作者: 魔鬼的驚嘆 時(shí)間: 2015-07-05 17:18
回復(fù) 10# alwaysR9
你的緩沖指的是什么

作者: 流氓無產(chǎn)者 時(shí)間: 2015-07-06 09:45

hellioncu 發(fā)表于 2015-07-03 11:07
TCP是流，所以是前者

哦，那么分包又有什么意義？

作者: hellioncu 時(shí)間: 2015-07-06 09:50

流氓無產(chǎn)者發(fā)表于 2015-07-06 09:45
哦，那么分包又有什么意義？

那是不同層的視角

作者: cutrain2010 時(shí)間: 2015-07-09 14:16
tcp需要處理粘包問題

歡迎光臨 Chinaunix (http://www.72891.cn/)

^{<dfn id="3qt66"></dfn>}