... | ... | @@ -2,15 +2,11 @@ Myšlenky k budoucím implementaci TCP stacku pro použití v DNS serveru poslou |
|
|
|
|
|
## Kontext spojení
|
|
|
|
|
|
TODO vymyslet co nejmenší datovou strukturu, která bude udržovat informace o spojení.
|
|
|
...se bud ukládat do struktury (podobné) `knot_xdp_msg_t`. Tyto struktury budou uloženy v hešovací tabulce, kde hešovací funkcí bude 32-bitová FNV-1a, a kolize se budou řešit spojovými seznamy. V hešovací tabulce budou společně navazovaná (přišel SYN) a již navázaná spojení.
|
|
|
|
|
|
TODO bude se lišit kontext teprve navazovaného (po SYN) a už navázaného spojení? (Ochrana proti SYN flood)
|
|
|
TODO vyřešit "garbage-collector", který bude umět vyhledat neaktivní spojení (`tcp-idle-timeout`).
|
|
|
|
|
|
Kontexty spojení se budou udržovat v hešovací tabulce.
|
|
|
|
|
|
TODO najít vhodnou hešovací funkci, která na zadanou čtveřici src+dst addr+port vrátí číslo z rozsahu 1..N, kde N lze nastavit.
|
|
|
|
|
|
TODO romyslet ošetření hešovacích konfliktů. Je lepší spoják nebo obsazení dalšího políčka?
|
|
|
TODO má se řešit i situace Příliš mnoho spojení? Stačí v takové situaci snížit idle timeout?
|
|
|
|
|
|
## Obecně k bufferům
|
|
|
|
... | ... | @@ -22,7 +18,7 @@ Buffer pool pro uričtý typ bufferů bude mít konfigurovatelnou max velikost j |
|
|
- staré buffery se nebudou mazat na základě časovače aka `tcp-remote-io-timeout` (to by vyžadovalo nějaký takový časovač / garbage collector implementovat) ale jen v následujících situacích:
|
|
|
* data v bufferu byla úspěšně zpracována
|
|
|
* celé TCP spojení bylo uzavřeno (např. `tcp-idle-timeout`)
|
|
|
* buffer uvolněn z důvodu vytvoření nového bufferu
|
|
|
* buffer uvolněn z důvodu vytvoření nového bufferu pro jiné spojení
|
|
|
|
|
|
## Konkrétně k bufferům
|
|
|
|
... | ... | |