Diskuze: Full-duplexní použití síťového rozhraní TUN/TAP v Linuxu

Vít Labuda

Tvůrce

Vít Labuda:17.7.2020 0:27

Zdravím,
chystám se psát vícevláknový Linuxový program v C, který bude pracovat s virtuálním síťovým rozhraním TUN/TAP. Mám zde však jeden dotaz, na který jsem nenašel odpověď ani v dokumentaci , ani na různých fórech a proto se zkouším zeptat zde.

Současný návrh onoho programu vypadá asi takto: první thread bude číst ze souborového deskriptoru TUN/TAP rozhraní pomocí read(2) pakety a když nějaký přijde, tak jej pomocí anonymních rour (vytvořených voláním pipe(2)) a volání select(2) nebo poll(2) rozdistribuuje mezi "worker thready" a po dokončení manipulace (relativně náročné, proto program člením do vláken) budou podobným způsobem posílány do dalšího threadu, který je bude podobným způsobem vyzvedávat a pomocí write(2) zasílat zpět na rozhraní. Volání read i write budou brát stejný file descriptor, jelikož TUN/TAP se otevírá s flagem O_RDWR. Připojuji i diagram pro případné snadnější pochopení. :-)

Má otázka zní: je možné, aby se volání read a write na souborový deskriptor TUN/TAP rozhraní prováděly současně bez dodatečné synchronizace? Jinými slovy, je rozhraní plně duplexní a nebude potřeba při volání zamykat vlákna pomocí mutexů, čtení i zápis provádět ve stejném vlákně nebo to řešit nějak úplně jinak?

Na StackOverflow jsem našel v podstatě stejnou otázku , akorát jsou jejím předmětem sokety a nikoliv znaková zařízení (čímž TUN/TAP je, viz. ls -l /dev/net/tun). Sokety full-duplexní jsou, ale nejsem schopen zjistit, zda-li je tomu tak i tady.

Za odpovědi budu vděčný. :-)

Odpovědět

17.7.2020 0:27

JerryM

Člen

JerryM:18.7.2020 19:11

tu knihovnun neznám ale pokud je opravdu full-duplex znamená to že má buffery pro příjem a vysílání zvlášť a tudíž tvuj záměr nevadí ...
ale dá se to přeci otestovat ne ? napiš krátej prográmek co ti bude vysílat a přijímat zároveň a na staně serveru udělej to samý ..

Nahoru Odpovědět

18.7.2020 19:11

Vít Labuda

Tvůrce

Vít Labuda:18.7.2020 19:27

Otestovat se to pochopitelně dá, ale odhaduji, že bych do onoho rozhraní musel hnát alespoň stovky megabitů provozu, aby se to projevilo, protože jinak to program bude stíhat obsluhovat synchronně a nic se nepozná... To je důvod, proč jsem se ptal předem, zda-li k tomu někdo nemá více informací. :-)
Ale vzhledem k tomu, že nevypadá, že je ona věc zdokumentovaná, se na to metodou pokus-omyl asi budu muset vrhnout... (ještě je zde možnost rozpitvat kód onoho ovladače :-) )

PS: Nejedná se o knihovnu, ale o ovladač v Linuxovém jádře (ke kterému se přistupuje pomocí I/O primitives - syscallů, resp. v mém případě pomocí jejich wrapperů z glibc). :-)

V každém případě díky za odpověď. :-)

Nahoru Odpovědět

18.7.2020 19:27

Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.

Zobrazeno 3 zpráv z 3.