Tady je otázka, co takhle rozumíte tím "TCP stackem". Obvykle se tím rozumí jádro, které vystavuje aplikacím nějaké API (typicky BSD sockets). Vše nad tím už je aplikační část.
Ale asi by šlo tohle dát do getaddrinfo(3), že by se záznamy vracely nikoli podle staticky nastaveného gai.conf, ale podle nějakého dynamického nastavení. Šlo by to cachovat podobně jako třeba funguje nscd(8).
Akorát je otázka, jak ty informace do tohoto zdroje ukládat, nejlépe tak, aby to neumožňovalo zneužití tím, že jedna podvratná aplikace do té cache uloží něco, co jiným bude vadit. Nebo že nějaká aplikace bude schopna z odezvy getaddrinfo(3) usuzovat na to, na jaké stroje v poslední době přistupovala jiná aplikace.
Jádro by asi muselo umět nějak předávat informace o úspěšných voláních connect(2) nebo tak něco. Nějaký démon by to sbíral a cpal do té cache. Tohle aspoň v Linuxu jednoduše nejde (šlo by přes perf nebo systemtap).
Zejména ten bezpečnostní aspekt je problematický. A to jsem vůbec neřešil otázku, že u většiny aplikací by bylo třeba triviální volání connect(2) nahradit neblokujícími voláními, a čekáním na některé z nich pomocí select(2)/poll(2)/epoll(2). Nebo vláknem, což zase není vhodné pro všechny situace.
-Yenya, http://www.fi.muni.cz/~kas/blog/
Teď to mám napsaný tak, že otevřu naráz všechna spojení asychroně, a čekám, který se ozve jako první. Nicméně plánuju, že ta asynchroní spojení budu startovat podle priority s odstupem třeba čtvrt sekundy a vždy zůstanou otevřená, dokud nevyprší globální timeout (nebo dokud se někdo nechytí). Jen ještě nevím, jak to udělám v asynchroním režimu navazování aniz bych musel používat vlákna ... (k plánování těch čtvrtsekundových startů).
Specifikace zároveň požaduje, aby se informace o výsledcích navazování spojení ukládaly do dočasné paměti [...] Životnost těchto informací by ale neměla přesáhnout 10 minut.
Uprimne nesnasim kdyz nekdo vymysli takove veci a ani nezohledni takovy zaklad jako TTL u DNS zaznamu, takze ve snaze o zlepseni ten protokol jen vic a vic rozbiji :(
(I kdyz mozna autorum krivdim, protoze ted jsem ten dokument jen hodne zbezne prohledal a zda se mi ze se cachuje jen address family, tj. jestli pro dany cil pro pristich deset minut preferovat IPv4 nebo IPv6)
Nechápu proč by tato logika měla být na úrovni aplikace, to povede jedině k tomu, že se každá aplikace bude chovat jinak a troubleshooting bude zbytečně složitý (jak už je uvedeno v článku). Tyto algoritmy by se měly řešit v rámci TCP stacku operačního systému, aby byly transparentní pro aplikace i uživatele (a doufejme i lépe optimalizované a naprogramované).