# HG changeset patch
# User František Kučera <franta-hg@frantovo.cz>
# Date 1340449868 -7200
# Node ID 92b32c3f9b8efb84ffefd60f9c92311c29724d1d

zadání, prvotní analýza

diff -r 000000000000 -r 92b32c3f9b8e analýza/stdio-fs.txt
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/analýza/stdio-fs.txt	Sat Jun 23 13:11:08 2012 +0200
@@ -0,0 +1,57 @@
+STDIO-FS
+--------
+
+Souborový systém (FUSE) komunikující přes standardní vstup/výstup (STDIO).
+Tzn. jeden kanál, který lze posílat buď mezi dvěma procesy lokálně (nemá moc velký smysl)
+nebo po síti – tunelovaně např. unitř SSH, nebo nešifrovaně přes obyčejné TCP.
+
+Skládá se ze dvou částí:
+ - server – zpřístupňuje skutečný souborový systém pomocí STDIO zvláštním protokolem
+ - klient – FUSE souborový systém, který se připojuje k serveru
+
+
+Požadavky
+---------
+
+ - pouze jeden kanál pro všechny operace → multiplexování (lze např. kopírovat dva soubory současně)
+ - efektivní binární protokol
+ - 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
+ - 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
+
+
+Implementatce
+-------------
+
+ - klient i server by měly být ve finální verzi v C++ případně v C
+ - prototyp může být v libovolném jazyce – Java, Perl?
+ - 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
+ - neřešíme bezpečnost – případné šifrování si řeší uživatel o úroveň níž (SSH, TLS) podle svých potřeb
+ - vrstvu, která se stará o multiplexování by bylo dobré napsat jako znovupoužitelnou knihovnu
+
+
+Multiplexování
+--------------
+
+ - přes jeden kanál (vstupní a výstupní proud) umožnit přenos libovolného počtu virtuálních kanálů
+ - kusy dat se označí číslem virtuálního kanálu a poskládají se do STDIO proudu
+ - na druhé straně se opět dekódují a rozloží jako samostatné kanály
+ - budeme mít nultý servisní kanál, který slouží k řízení toku a přenosu dalších metadat, tento kanál je prioritní
+ - ostatní kanály se vytváří na přání – podobně jako se vytvářejí TCP spojení
+ - klientem (iniciátorem kanálu) i serverem u virtuálních kanálů můžou být obě strany
+ - je potřeba řešit zahlcení
+	- 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
+	- částěčně lze řešit mezipamětí
+	- 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ů
+		- 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)
+		- 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í
+	- kanál je možné odblokovat:
+		- po uplynutí určitého času (stanovený v požadavku na blokaci)
+		- po odvolání blokace příjemcem (řekne, že už má místo na další data)
+		- pokud v ostatních kanálech nejsou žádná data k odeslání
+			- 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
+			- musí být povoleno příjemcem
+	- mohlo by jít řídit rychlost jednotlivých kanálů
+		- plynulá komunikace, bez blokování
+		- příjemce řekne, jakou rychlostí je schopný odbavovat data na daném kanále
+		- průběžně lze rychlost měnit
+