analýza/stdio-fs.txt
author František Kučera <franta-hg@frantovo.cz>
Sat, 23 Jun 2012 13:11:08 +0200
changeset 0 92b32c3f9b8e
child 1 f57460019f80
permissions -rw-r--r--
zadání, prvotní analýza
     1 STDIO-FS
     2 --------
     3 
     4 Souborový systém (FUSE) komunikující přes standardní vstup/výstup (STDIO).
     5 Tzn. jeden kanál, který lze posílat buď mezi dvěma procesy lokálně (nemá moc velký smysl)
     6 nebo po síti – tunelovaně např. unitř SSH, nebo nešifrovaně přes obyčejné TCP.
     7 
     8 Skládá se ze dvou částí:
     9  - server – zpřístupňuje skutečný souborový systém pomocí STDIO zvláštním protokolem
    10  - klient – FUSE souborový systém, který se připojuje k serveru
    11 
    12 
    13 Požadavky
    14 ---------
    15 
    16  - pouze jeden kanál pro všechny operace → multiplexování (lze např. kopírovat dva soubory současně)
    17  - efektivní binární protokol
    18  - zpřístupnit co nejvíce informací o souborech včetně rozšířených atributů a pravdivého údaje o obsazeném místě na disku
    19  - pomocí rozšířených atributů zpřístupnit další nestandardní informace a funkce – např. umožnit výpočet hashe souboru na serveru → po síti (STDIO) se pak přenese pouze otisk, ne celý soubor
    20 
    21 
    22 Implementatce
    23 -------------
    24 
    25  - klient i server by měly být ve finální verzi v C++ případně v C
    26  - prototyp může být v libovolném jazyce – Java, Perl?
    27  - server může mít více implementací – pracuje pouze se standardním vstupem/výstupem a soubory, nemá nic spolenčného s FUSE
    28  - neřešíme bezpečnost – případné šifrování si řeší uživatel o úroveň níž (SSH, TLS) podle svých potřeb
    29  - vrstvu, která se stará o multiplexování by bylo dobré napsat jako znovupoužitelnou knihovnu
    30 
    31 
    32 Multiplexování
    33 --------------
    34 
    35  - přes jeden kanál (vstupní a výstupní proud) umožnit přenos libovolného počtu virtuálních kanálů
    36  - kusy dat se označí číslem virtuálního kanálu a poskládají se do STDIO proudu
    37  - na druhé straně se opět dekódují a rozloží jako samostatné kanály
    38  - budeme mít nultý servisní kanál, který slouží k řízení toku a přenosu dalších metadat, tento kanál je prioritní
    39  - ostatní kanály se vytváří na přání – podobně jako se vytvářejí TCP spojení
    40  - klientem (iniciátorem kanálu) i serverem u virtuálních kanálů můžou být obě strany
    41  - je potřeba řešit zahlcení
    42 	- když se z jednoho virtuálního kanálu nebude číst vůbec nebo pomalu, musí být možné číst ostatní kanály, aniž by bylo potřeba čekat na odbavení paketů pomalejšího kanálu
    43 	- částěčně lze řešit mezipamětí
    44 	- pokud dojde k jejímu zaplnění na straně příjemce, je potřeba odesílateli sdělit, že má přestat na tomto kanále posílat data a posílat zatím data jiných kanálů
    45 		- pokud odesílatel neposlechne, dojde k zablokování a je potřeba počkat, až budou pakety tohoto pomalejšího kanálu odbaveny na straně příjemce (do té doby bude zablokována i komunikace na všech ostatních kanálech)
    46 		- v krajním případě může nespokojený příjemce reagovat na neposlušného odesílatele odpojením – před tím pošle servisním kanálem informaci, proč ukončuje spojení
    47 	- kanál je možné odblokovat:
    48 		- po uplynutí určitého času (stanovený v požadavku na blokaci)
    49 		- po odvolání blokace příjemcem (řekne, že už má místo na další data)
    50 		- pokud v ostatních kanálech nejsou žádná data k odeslání
    51 			- potenciálně nebezpečné – může opět dojít k zahlcení tohoto kanálu a v té době už se objeví data v jiných kanálech a nepůjde je odeslat
    52 			- musí být povoleno příjemcem
    53 	- mohlo by jít řídit rychlost jednotlivých kanálů
    54 		- plynulá komunikace, bez blokování
    55 		- příjemce řekne, jakou rychlostí je schopný odbavovat data na daném kanále
    56 		- průběžně lze rychlost měnit
    57