TCPはストリームなので、前のパケットが失われて再送になると後ろが一緒に詰まる、というのはQUICがTCPを捨てた大きな理由だったけど、後ろのパケットはホストまで届いているんから、再送を待たずに投機的に処理して再送されてきた前のパケットとシーケンス番号が噛み合ったら確定、は出来るんだよな
-
-
Replying to @fadis_
ただ、その処理の仕方は「ストリーム処理」とは言い難く… 大昔、送受信単位を「sector」と呼んで順不同でHDDにIOしたかのように見せる処理系は書いたことがある。RTTがバカでかい処理系ではそれなりに役に立った。
2 replies 0 retweets 1 like
Replying to @fjs_kyousosama
前のパケットがなくても次のパケットが解釈できる事が条件になるので、もはやストリームでなくUDPのようにパケットの最大サイズを意識してメッセージを投げる感じになってしまいますね
5:46 AM - 20 Apr 2020
0 replies
0 retweets
1 like
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.