Vlákno názorů k článku Další nestabilita v BGP protokolu ohrozila Internet od bredy.novacisko.cz - Zase vidím kus kódu C programátora a zase...
-
Jirka P (neregistrovaný)Proč by ten patch měla být prasečina? Možná vám to přijde divné, ale ten patch dělá téměř přesně to, co běžné implementace řetězců (např.) v C++, a dělá se to tak kvůli lepší časové složitosti. MMCH, když ta délka řetězce začíná na 32 a zvětšuje se v jednom kroku max. o (asi) 10, jaký je rozdíl mezi realokací na konci a po každém spočtení...? (žádný, že)
Co byste použil vy? asprintf() nebo něco ekvivalentního? -
Neměl jsem možnost a čas studovat kód Quaggy do detailu, takže teď budu trochu obecně plkat :-).
1) Ta transformace na string je tam úplně zbytečně. Protokol BGP je binární, takže textová reprezentace má smysl pouze v případě zobrazování (log, debug, konzole, atp.), a to se dá vždycky nasypat v případě, že je potřeba textovou reprezentaci vypsat.
2) Pokud by to opravdu nějaký smysl mělo, tak bych použil statický buffer. Maximální velikost BGP zprávy je 4k a například Cisco natvrdo omezuje počet AS na max 2000.
#bgp maxas-limit ? <1-2000> Number of ASes in the AS-PATH attribute
Jinými slovy nemá smysl dělat víc, protože to skrz Cisca stejně dál neprojde (druhá věc je, že standardní omezení je 255). A 22kB buffer (v maximálním případě) není zas tolik. -
Jirka P (neregistrovaný)Taky jsem nestudoval kód do detailu. Například nevím, co se stane, když ten jejich XMALLOC selže :)
1) V obecné rovině máte možná pravdu. V kontextu toho patche je to ale trochu mimo.
Je možné, že celý ten kód je zbytečný (a věřím, že kdybyste napsal patch, který ho odstraňuje a zbytek toho démona zjednoduší, byli by vývojáři rádi), ale ta transformace tam jednou je, mrtvý kód to není, a ať už ji používají k čemukoli (kromě důvodů, které jste vypsal, to třeba ukládají někam do texťáku), bude patch, který ji odstraní, mnohem složitější, než pouhá oprava té funkce. Což je ale špatná vlastnost pro rychlou opravu.
BTW není mi úplně jasné, co znamená "dá se vždycky nasypat".
2) Dovedu si představit statický buffer (i menší), pokud bude dobře vyřešeno jeho přetečení. Ale nemyslím si, že je to menší nebo větší prasárna, než to, co tam nakonec dali. Na Cisco bych se radši neohlížel, ti si své užili nedávno. -
BTW pro (ultra)rychlou opravu stačilo z "5 + 1" udělat "10 + 1".
BGP démon zpracovává mnoho UPDATE a potřebuje to dělat hodně rychle, což se skoro přímo vylučuje s funkcí realloc(). Což mimo jiné odpovídá i na otázku jaký je rozdíl mezi (pokud není počet opakování while cyklu roven jedné):
while (*space < needed) *space *= 2;
XREALLOC (MTYPE_AS_STR, path, *space);
a
while (*space < needed) { *space *= 2; XREALLOC (MTYPE_AS_STR, path, *space); }
"dá se vždycky nasypat" -> převést binární reprezentaci AS path na textovou v případě, že to zrovna potřebujete. Hádám (tak nějak z principu věci), že počet takových případů bude menší než potřeba rychle zpracovat BGP UPDATE. Ale teď už opravdu jenom spekuluju... -
Jirka P (neregistrovaný)ultra-rychlá úprava: ano. Proč to nepoužili, nevím.
"potřebuje to dělat hodně rychle" a "vylučuje ... realloc()": Co přesně znamená hodně rychle? Máte nějaká data, která ukazují na realloc jako zásadní brzdu toho kódu?
"pokud není počet opakování ... roven jedné": Klíčová otázka je, jaký bude počet opakování toho cyklu v daném kusu kódu. (MMCH ten while si skutečně mohli ušetřit). -
K rychlosti - mrkněte třeba sem: http://bgpupdates.potaroo.net/
Skoro dole je tabulka, a logscale graf s BGP update za sekundu.
realloc je vždy z principu brzda. Prostě když musíte (v nejhorším případě) přehazovat v paměti data do nově alokovaného bloku, tak to bude vždycky pomalé. Samozřejmě že je otázka, jak často se tento kus kódu vlastně vykoná -> a tenhle konkrétní případ spíš ukazuje na celkovou koncepci než, že by tenhle kus kódu byl tím zásadním problémem, který zpomaluje celou quaggu.
Každopádně už vedeme čistě akademickou debatu, aniž bychom opravdu znali vnitřnosti tohoto vyhynulého zvířete. -
bredy.novacisko.cz (neregistrovaný)Mě šlo hlavne o to #define ....
Totiž Cčkový programátoři neumí nic jiného, než používat příkaz #define, čímž zaplevelují kód naprosto nevýdaným způsobem.
Ve svých programech používám #define opravdu minimálně, a opravdu jen tam, kde se to prostě jinak dělat nedá. -
Petr (neregistrovaný)No to je hlavne proto, protoze normalni kod neni duvod ukazovat. Duvod ukazovat je jen praseciny.
"Zase vidim ve zpravach bouchacku a zase s ni nekoho zabili."
"Zase vidim ve zpravach podnikatele a zase vytuneloval firmu."
"Zase vidim ve zpravach felicii a zase se v ni nekdo zabil." -
anonymníHmm, spravuju jeden nejmenovany ERP a dobytky kteri to vyvyjeli bych mohl naplnit cele staje.
Ostatne obcas mam dojem, ze programator == dobytek.
Jenze kdyz pak clovek vidi, jak to ve vyvojarske firme "funguje" ("mas na to hodinu, tak to sprav"), tak se divit prestane.
U os je to zkraka obcas o tom, ze nekdo neco napise aby "to fungovalo", s tim, ze pozdeji tomu kodu da lepsi formu. Jenze pak uz se k tomu nedostane a nikdo jiny to neopravi, protoze "to funguje". Pripadne nejaky bug opravi "neprogramator", protoze se k tomu nikdo jiny nema.
BTW: Pocitam ze cs aplikace maji kod obecne omoc horsi. Nikdo to nevidi, takje to preci jedno ne ? -
Karell (neregistrovaný)Nekteri programatori proste nejsou schopni domyslet "co se stane kdyz". Verim tomu, ze tenhle takovy kod napise i kdyz by na to mel mraky casu. Proc premyslet, kdyz 5 je tak krasne cislo a dosud fungovalo.
Jinymi slovy, je rozdil napsat v casove nouzi neefektivni kod (tezko to mit programatorovi za zle) a napsat to blbe s tim, ze dnes to tak funguje a zitra potopa. fuj -
anonymníNo za me (podotykam, ze se nezivim jako programator, i kdyz obcas neco napisu) sme se uz na zs (krouzek) ucili, ze 20% kodu je to, co vykonava funkci a 80% to, co osetruje chybovy stavy. Ono to pak celkem logicky dopada tak,ze programator napise tu funkci a chyby uz neosetri. Proc by mel, vzdyt preci "nikdo neni tak blby, aby misto cisla vlozil string".
Vysledek je v extremnim pripade ten, ze vyvojari samozrejme vse funguje, protoze "vi", co ma kam zadat, ale prvni uzivatel aplikaci spolehlive sestreli, protoze zada nejakou blbost.
BTW: Pouzivat ruzna "magicka" cisla je dost rozsireny zpusob programovani. Prca nastava, kdyz kod potrebuje upravit nekdo jiny nebo i tvurce po par mesicich/letech ;) . -
Petr (neregistrovaný)To je trochu sentimentalni nazor. Vzbuzuje predstavu firmy, ktera se s kazdou drobnosti hrozne pipla, vysledek je fakt perfektni ... jenze pro nej neni trh, protoze je prilis drahy. Firma se stahuje do ulity "nam nikdo nerozumi" a "jaktoze nechapou, ze to {konkurence} pise uplne amatersky". A je nakonec trhem prevalcovana.
Kazde rozhodnuti *dobreho* programatora je predevsim cost-effective (pardon, jaky je cesky ekvivalent? efektivni vzhledem k nakladum?). Externality jsou proste externality. Pokud nasledky me chyby neplatim ja, ale nekdo jiny, tak rozhodne nesmim venovat usili, abych tu chybu neudelal; jinak plytvam. Pokud oprava chyby zpozdi vydani softwaru o mesic, je to take naklad (ztracene prodeje za ten mesic, konkurent me predbehne apod.), tedy take plytvani.
Dobry programator mimo jine vi, kdy je software "dostatecne dobry".
V softwarech typu "rizeni letadel" a "kardiostimulatory" je to jasne. Naklady za chybu v softwaru plati tvurce softwaru. Takze se software vyviji bez chyb (a desive draho a desive pomalu). V softwarech typu "enterprise" a "mass market kancelarsky balid" je to take jasne. Dusledkem chyby je nejvys ztrata reputace, naklady nese uzivatel.
Jestli se vam nelibi, ze tohle je realita trhu, cesta ke zmene vede pres zmenu zakonneho ramce. Postaveny dum vam nesmi spadnout na hlavu a stavebni firma se nesmi pokusit to riziko na vas prenest; i kdyby tim byl ten dum desetkrat levnejsi. Pokud zakon zamezi tomu, aby naklad za sw chybu na vas autor sw prenesl, pak uvidite, jak rychle se zacne psat dobry software. A jak rychle budou ti "taky-programatori", kteri psat bez chyb neumeji, preskoleni nebo odlozeni. A take uvidite, jak sakra drahy ten software bude.
ČLÁNKY DO MAILU