Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.
Obě strany předchozí revize Předchozí verze | Následující verze Obě strany příští revize | ||
cs:architecture [11.09.2018 15:10] mach@cesnet.cz [Architektura webového rozhraní] |
cs:architecture [11.09.2018 15:34] mach@cesnet.cz [Protokol pro výměnu zpráv] |
||
---|---|---|---|
Řádek 75: | Řádek 75: | ||
==== Protokol pro výměnu zpráv ==== | ==== Protokol pro výměnu zpráv ==== | ||
- | To facilitate message exchange between daemon modules a very simple filesystem-based message exchange protocol (aka. *filer protocol*) was designed and implemented. It is inspired again by [[http://www.postfix.org/|Postfix MTA]]. | + | Pro umožnění výměny zpráv mezi jednotlivými démon moduly byl navržen a implementován protokol pro výměnu zpráv založený na filesystému (aka. *filer protocol*). Inspirací byl opět již zmiňovaný [[http://www.postfix.org/|Postfix MTA]]. |
- | The protocol uses designated filesystem directory with following substructure for exchanging the messages: | + | Protokol používá pro výměnu zpráv označené adresáře na filesystému s definovanou nasledující strukturou se speciálním významem: |
- | * **incoming**: input queue, only complete messages | + | * **incoming**: vstupní fronta, pouze úplné zprávy |
- | * **pending**: daemon work directory, messages in progress | + | * **pending**: pracovní adresář modulu, *uzamčené zprávy* v průběhu zpracování |
- | * **tmp**: work directory for other processes | + | * **tmp**: pracovní adresář pro ostatní procesy |
- | * **errors**: messages that caused problems during processing | + | * **errors**: zprávy, které způsobily problém při zpracování |
- | Key requirement for everything to work properly is the **atomic move** operation on filesystem level. This requirement is satisfied on Linux system in case the source and target directories in the move operation are on the same partition. Therefore never put queue subdirectories on different partitions and be cautious when enqueuing new messages. To be safe use following procedure to put new message into the queue: | + | Klíčovým požadavkem pro správnou funkci protokolu je **atomická operace přesunu** na úrovni filesystému. Tento požadavek je na Linuxových systémech uspokojen v případě, že zdrojový a cílový adresář se nacházejí na stejné partition. Z toho vyplývá požadavek nikdy nedávat podadresáře fronty na různé oddíly disku. Následující procedura popisuje bezpečné vložení nové zprávy do fronty démona ke zpracování: |
- | - create new file in **tmp** subdirectory and write/save its content | + | - vytvořit nový soubor v podadresáři **tmp** a vepsat/uložit jeho obsah |
- | - filename is arbitrary, but must be unique within all subdirectories | + | - název souboru může být libovolný, ale rozumný z hlediska použitých znaků a unikátní v rámci celé fronty |
- | - when done writing, move/rename the file to **incoming** subdirectory | + | - přesunout/přejmenovat soubor do podadresáře **incoming** |
- | - move operation **must be atomic**, so all queue subdirectories must be on same partition | + | - operace přesunu **musí být atomická**, takže všechny podadresáře fronty musí být na stejné partition |
- | Following diagram describes the process of placing the message into the queue and the process of fetching the message from the queue by the daemon module: | + | Následující obrázek popisuje zmiňovaný proces vložení nové zprávy do fronty démonu: |
{{ ::mentat-queue-protocol.png?nolink |Protokol pro výměnu zpráv}} | {{ ::mentat-queue-protocol.png?nolink |Protokol pro výměnu zpráv}} | ||
- | Blue arrows are filesystem operations performed by the external process, that is placing new message into the queue. It is clear, that according to the procedure described above the message is first placed into the **tmp** and then atomically moved into **incoming**. Red arrows indicate filesystem operations performed by the daemon process itself. By atomically moving the message from **incoming** to **pending** it marks the message as *in progress* and may now begin the processing. When done, the message may be moved to the queue of another daemon module, moved | + | Modré šipky jsou filesystémové operace prováděné externím procesem, který vkládá novou zprávu do fronty. Dle výše popsané prcedury je zpráva nejprve vložena do podadresáře **tmp** a poté atomicky přesunuta do **incoming**. Červené šipky jsou filesystémové operace prováděné samotným démonem. Atomickým přesunutím zprávy z **incoming** do **pending** dojde k jejímu označení jakožto *in progress* a démon může zahájit zpracování. Když je hotov, zpráva je přesunuta do fronty následujícího dému v řadě, přesunuta do **errors** v případe nějaké chyby při zpracování nebo zcela smazána (v případě, že démon je posledním ve zpracovacím řetězu). |
- | to the **errors** in case of any problems or even deleted permanently (in case the daemon module is last in message processing chain). | + | |
- | The atomic move operation from **incoming** to **pending** serves also another purpose, which is locking. When multiple instances of the same daemon module work with the same queue the atomicity of the move operation makes sure that each message will be processed only once. All daemon modules are prepared for this eventuality and are not concerned when messages magically disappear from the queue. | + | Operace atomického přesunu z **incoming** do **pending** má i další účel a tím je zamykání. Ve chvíli, kdy více instancí démonu pracuje nad stejnou frontou atomicita přesunu zajišťuje, že každá zpráva je a bude zpracována právě jednou. Všechny démony jsou na tuto eventualitu připraveny a umí se vyrovnat s tím, že se nějaká zpráva nepodaří přesunout nebo záhadně zmizí z fronty. |
==== Architektura webového rozhraní ==== | ==== Architektura webového rozhraní ==== |