第84話のmailboxの下で、床が透明になった。
emailのcontent。
chatのevent。
pushのsmall notice。
どれも、青いdata roadへ降りていく。
イトは、その横へSNS広場の大きな入口地図を置いた。
広場の開場を知らせるlive cueも、六個の小さな光に変えて並べる。
「同じ道を使うなら、同じ送り方にすれば迷わない」
イトは地図と六個のcueを、一つのreliable / ordered gateへ順番に詰めた。
地図のdataが先。
live cueは、その後ろだ。
send leverを倒す。
途中で地図の一部が欠けた。
受信側には後ろのdataも着いている。
けれど、一つのordered byte streamは、欠けた位置より後ろをapplicationへまだ渡せない。
地図だけでなく、開場の合図まで止まった。
同じnetworkは、同じ意味を運ばない
公開demoまで、あと九十秒。
入口地図は一byteでも欠ければ不合格。
live cueは、このfixtureでは作成から三百millisecondsを過ぎたら不合格だ。
遅れて完全な古い合図を鳴らしても、開場の瞬間には役に立たない。
ユイ
地図は待って直したい。でも、古い合図は待つほど困ります
イト
同じdata roadだから、同じ確認方法にそろえると思ってた
マコト
共通の道と、荷物ごとの約束を分けないといけないんだね
networkの途中にいるrouterは、今回のfixtureで「これは入口地図」「これは開場cue」と意味を読んで決めない。
IP destinationを手がかりに、次の道へdatagramをforwardする。
地図として完成させること。
cueを期限内だけ鳴らすこと。
その意味と判断は、両端のapplicationに残る。
一つのdataにも、役割の違う層がある
イトは、止まった列を上から見た。
同じdataが、役割ごとに包まれている。
application objectの意味、境界、期限
transport flow、順序、回復、datagram
internet source / destination host、forwarding
link 次のhopへ渡すframeこれは実装の全てを四つの箱へ押し込む図ではない。
隣の層は互いに影響し、実際のprotocolにはもっと多くのstateがある。
ただ、故障を一つの「通信error」へ丸めないための見取り図になる。
applicationは、地図やcueをnetworkへそのまま投げない。
形式を決め、bytesへencodeし、相手側でどこまでが一つのobjectか読める境界を持たせる。
TCPはapplicationへreliableでin-orderなbyte streamを提供する。
byte stream自体には「ここまでが地図一枚」というmessage境界がない。
今回のmap applicationは、自分でobject kindとlengthをframeへ入れる。
transportが作るsegment境界と、application objectの境界を同じものにしない。
TCP segmentはIP datagramに入ってnetworkを進む。
UDPを使う場合も、UDP datagramはIPの上で運ばれる。
上の送り方が違っても、下のIP networkを共有できる。
三つの直し方
イトは、止まったuniversal streamの前へ三枚のroute cardを置いた。
イト
A。地図もcueも、一つのexact ordered streamへ残す
イト
B。全部をdatagramへ変えて、欠けても再送しない
イト
C。同じIP network上でflowを分け、地図は欠けを回復し、cueは期限と重複をapplicationが判断する
Aでは、地図の欠けが後ろのlive cueまで待たせる。
Bでは、地図の一部が失われても完成扱いにしてしまう。
Cなら、共通のnetworkと、objectごとのdelivery policyを分けられる。
Picoはcardへ触れない。
欠けた地図片と、期限切れになったcueだけをcyan lightで分離している。
イトがuniversal streamを閉じた
イトはAのwide stream shutterを閉じた。
Bのno recovery for all gateもOFFへ戻す。
一つのshared roadの上へ、二つのflow gateを自分の両手で開いた。
上はmap flow。
下はlive cue flow。
map flowは、reliable ordered byte streamを使う。
宛先hostと、closed fixtureのmap service endpointを指定する。
欠けを検出したtransportは、必要なdataを再送してstreamを埋める。
map applicationは、宣言したlengthまで受け取ってからfileを完成させ、expected hashと照合する。
TCP acceptedをmap usableへ飛ばさない。
live cue flowは、一cueを一application datagramとして作る。
cue id
created at
expires at
payload今回のreceiverは、期限切れを鳴らさない。
同じcue idを二度受け取っても、一度だけ扱う。
UDP自身がloss、順序、再送、flow controlを解決してくれるとは考えない。
senderにはrate capを置き、receiver feedbackで混雑時の送信量を下げるclosed fixtureにした。
「UDPなら必ず速い」でも、「TCPならどんなdataにも正解」でもない。
applicationが必要な結果を先に決め、その結果を支えるtransportを選ぶ。
一つを落とし、二つを入れ替えた
test switchで、map streamの一segmentを落とした。
後続bytesは先に到着したが、map flowは欠けを回復してからapplicationへ順番どおり渡す。
file completionは待つ。
その間も、別のlive cue flowは同じIP routeを進む。
三番目のcueは途中で失われた。
二番目は遅れて、四番目より後に着いた。
receiverは四番目を期限内に鳴らし、到着時には期限を過ぎていた二番目を捨てた。
shared IP network flows 2
map complete 1
map hash mismatch 0
live cue sent 6
live cue arrived 5
live cue played on time 4
expired cue discarded 1地図は一byteも欠けずに完成した。
合図は一つ失われたが、古い音で現在を止めなかった。
二つのflowを分けても、shared networkの混雑が両方へ影響する可能性は残る。
今回なくしたのは、同じbyte streamへ詰めたことによるapplication deliveryの待ち合わせだ。
network全体の干渉が消えたとは言わない。
「通信が遅い」を、一つのlampに戻さない
一つの画面だけが遅いとき、イトはすぐに「network全部がdown」と決めなくなった。
まずapplicationがobjectを作れたかを見る。
次に、そのobjectを運ぶtransport flowが進んだかを見る。
IP destinationへ届いたあと、receiver applicationが受け取り、期限やformatを満たしたかを見る。
mapが待っていてlive cueが動くなら、少なくとも全てのIP pathが同時に消えたとは限らない。
両方が止まるなら、共通するname resolution、destination、route、linkを一段下で見る。
「届いた」と言うときは、IP到着、transport delivery、application usable、human seenのどこかを決める。
段階を一つ選べば、次に見るlampも一つにできる。
届いた投稿を、全員の棚へつないだ
公開demoのclockが0になる。
入口地図は崩れずに表示され、最後のlive cueが時間どおり鳴った。
二つのdataは、同じsocial serviceの入口へ着いている。
その横に、最初のpost objectが保存された。
transport successはgreen。
イトは勢いのまま、届いたpostから広場にある全timeline shelfへ線を伸ばした。
一斉にred lampが点く。
audience policy: unset。
networkは、postをserviceへ届けた。
誰に見せるかまでは決めていない。
イトは全員の棚へ伸ばした線を握ったまま、まだ一つも接続しなかった。
次回、ピコルート第86話。
イトは、同じ投稿を全員の棚に置く？｜タイムラインは誰が決める？