Hlavní navigace

Názory k článku Analogie ASN.1

Článek je starý, nové názory již nelze přidávat.

  • 14. 7. 2004 8:40

    Luděk R. (neregistrovaný)

    Můj oblíbený zdroj informací o ASN.1 je kniha ASN.1 Complete, která je ke stažení http://www.c7.com/ss7/books/ASN1_Complete.pdf

    A co se využití ASN.1 týká, když chcete efektivně (z hlediska objemu) serializovat strukturovaná data a zkusíte si vymyslet nějaký systém, téměř vždy skončíte u něčeho velice podobného ASN.1 - TLV.

    A co se praktického využití týká, máme celkem dobré
    zkušenosti s ASN.1 parserem/serializatorem v OpenSSL. Neumí (prý zatím) načítat ASN.1 moduly, ale pomocí sady maker není problém ručně zapsat požadovanou strukturu (1:1 s ASN.1 popisem syntaxe) a C preprocesor vygeneruje vše ostatní a pak už vám to samo serializuje a parsuje.
    OpenSSL parser je dobrá volba, pokud nemusíte zpracovávat tisíce modulů a nebo pokud chcete pouze rozšířit ASN.1 definice již v OpenSSL podporované.

  • 14. 7. 2004 10:52

    Vítězslav Novák (neregistrovaný)

    ASN.1 je použitelný zrovna tak na internetu, v jakkoli heterogenním prostředí. Právě pro taková prostředí byl vyvinut. A že v době vzniku byla počítačová prostředí heterogenní ažaž! Jenže internet se hodně orientuje na textové přenosy, často včetně binárních dat, z čehož vyplývají hrůzy jako Base64.

    ASN.1 je v zásadě binární záležitost, která řeší problémy s endiány, doplňky u záporných čísel, sizeof(), zarovnáváním a pokud bude na druhé straně něco, co nezná byty nebo má byte 9-bitový (existuje-li to), porozumíte si taky. Ani o tom nemusíte nic tušit.
    XML tyto problémy "řeší" tím, že je obejde - ASCII je dostatečně univerzální, tak co.

    BER nešetří každým bitem, dokáže být i pěkně plýtvavé, i když zdaleka ne tak plýtvavé jako XML. Nárůst dat u EXPLICIT může být klidně dvojnásobný i větší. Ovšem proti XML je to sranda.
    Takové BER s EXPLICITním kódováním přenese o každé hodnotě i informaci, jak ji interpretovat (boolovskou, integer, real ve tvaru trojice integerů [mantisa, základ, exponent], některý ze stringů,...). IMPLICIT přenese jen to podstatné pro identifikaci, takže na druhé straně musíte mít stejný popis. Zjistíte hodnotu, binární obraz, ale co to je, musíte vědět předem.

    Teprve PER se řídí socialistickou zásadou "ani bitík nazmar" včetně toho, že nemusí zarovnávat, kašle na hranice bytů a pokud budete chtít, sekvenci DNA zakódujete pomocí 2 bitů na jedno "písmeno" (bázi). A jeden bit bude v jednom bytu, druhý v následujícím...
    PER nepoužívá TLV a v nejúspornější variantě (jsou 4) zdrcne data tak, že víc to snad ani nejde. Tedy bez ztráty informace, že (;-))

  • 14. 7. 2004 11:26

    Jan Hlavatý (neregistrovaný)

    Pěkná knihovna pro práci s ASN.1 v Javě je součástí Bouncy Castle Crypto APIs http://www.bouncycastle.org/

  • 15. 7. 2004 9:53

    Vítězslav Novák (neregistrovaný)

    Ono je především určeno na něco jiného než XML. XML je textová záležitost a původně taky měla vyznačovat v textech. Že se dneska používá víc na problémy, kam by se hodilo něco binárního, je jiná věc.

    ASN.1 je primárně určená pro popis binárních dat, do kterých případně patří i textové kusy. Výsledek je úspornější a zpracování rychlejší.
    Běžné zpracování ASN.1-popsaných dat neprobíhá tak, že se udělá obecný parser parametrizovaný popisem, ale na základě popisu se vygeneruje (ale jde i napsat ručně) parser na konkrétní sadu dat. Třeba v C/C++, Javě..., a ten se začlení do programu. Tam, kde se zpracovává omezený (třeba velikánský) soubor zpráv, ale jde o rychlost, je to nejlepší řešení.

    Ovšem data jsou zase skoro nečitelná. To "skoro" je tam kvůli těm, kterým nevadí luštění v hexa editoru.

    V některém z posledních X Files byl odkaz na pokusy o propojení ASN.1 s XML. Psal to Dubuison, takže je to odborně na výši a navíc se to dá celkem dobře číst. Halt nejlepší angličtina je francouzská, pokud se k ní Francouz už dokope...

  • 14. 7. 2004 23:36

    Marek Turnovec (neregistrovaný)

    Nechcete se naucit psat k tem clankum trochu lepsi perexy a ne tam davat jen cut'n'paste prvniho odstavce? Zda se mi, ze se tu tento zlozvyk objevuje cim dal tim casteji... Kdyz jsem kdysi psal pro jeden webmag, tak nas k tomu docela nutili a bylo to jedine dobre... A kdyz tak si s tim dal jeste praci sefredaktor... Tady to je neci evidentni lennost... :-)

  • 15. 7. 2004 10:13

    lovec (neregistrovaný)

    Ake parsery na ASN.1 používate .. lebo ja už rok robím nejaké programy, ktoré načítavajú/zapisujú DER kódovanie - a nie je to úplne to pravé.


    Mimochodom .. ASN.1 tiež nie je tak dokonalé, ako popisuje článok - okrem 11 druhov reťazcov má 2 časy, pri tých zátvorkách "signedAttrs [1] ..." sa často neuvádza slovo IMPLICIT, ani EXPLICIT .. a potom sa v tom vysomárovať.

    Kódovania sú nešťastne navrhnuté - BER je absolútne nevhodný na čítanie, DER je zas pre zmenu neohrabaný pri zápise.

    Občas sú to hlúpo vymyslené štandardy, ale - treba ich dodržiavať.

  • 16. 7. 2004 16:07

    Vítězslav Novák (neregistrovaný)

    Objective Systems, Inc., v.5.5

    Mně to zase tak nedobře navrhnutý nepřipadá, ale dělal jsem si nějaký čtecí/psací funkce jen pro něco co jsem potřeboval qůli testování. Mně to připadá dobrý.

  • 15. 7. 2004 11:58

    Ondra (neregistrovaný)

    <quote>
    Distribuované aplikace na mobilních zařízeních používající ASN.1
    by opravdu byly efektivnější než Web Services - kdyby si někdo dal
    tu práci a implementoval je...
    </quote>

    pracuje se na tom ;-)), nejake (dnes uz out of date) zakladni informace jsou zde: http://www.ics.muni.cz/~hopet/MSR2003/MSR2003_Budapest.pdf

  • 16. 7. 2004 10:41

    Zdenek (neregistrovaný)

    Zajímavé.. věděl jsem že existují další kódování, ale zatím všude kde se používá ASN.1 jsem v praxi viděl *POUZE* DER (ldap, snmp, pkcs), takže každý BOOL se nafukuje na 3 bajty, což pomalu tomu XML začíná konkurovat. Můžete někdo uvést příklad, kdy se de facto skutečně používají efektivnější kódování?

  • 16. 7. 2004 16:17

    Vítězslav Novák (neregistrovaný)

    Dokonce jsem se setkal s tvrzením v učebnici, že ASN.1 == BER/DER/CER. Dřív to tak bylo a některý věci v syntaxi tomu i odpovídají. Třeba IMPLICIT/EXPLICIT/AUTOMATIC TAGGING má samozřejmě význam jen tam, kde se vůbec taguje, tedy v BER a odvozených.

    Kde se používá PER, nevím. Ono to vypadá zběsile neefektivně co do času na zpracování, ale protože parser vlastně vytváří kód, který se pak kompiluje a linkuje, může spoustu věcí prostě hodit do maker a maskovat. A bitové operace jsou rychlé snad na všech procesorech a kompilátory je zvládají dobře překládat, takže výsledek je pozoruhodně rychlý. Pokud si s tím dal autor práci.
    Mluvím o C.

    a samozřejmě jsem zapomněl dodat, že data oproti PERu nejde zdrcnout bez další komprese. PER nekomprimuje, jen co nejúsporněji naskládá. I když, tady se asi ani kompresní programy moc chytat nebudou.