Ma újra le kellett fordítanom az ucspi-tcp-t, de beleszaladtam az alábbi hibaüzenetbe:

/usr/bin/ld: errno: TLS definition in /lib/libc.so.6 section .tbss mismatches non-TLS reference in tcpserver.o
/lib/libc.so.6: could not read symbols: Bad value
collect2: ld returned 1 exit status

A megoldás egyszerű: szerkeszd az error.h fájlt, és ezt a diff-et hajtsd végre rajta:

-extern int errno;
+#include <errno.h>

A HWSW-n megjelent egy cikk a fenti címmel. 15 perc hírnév (olvasd: 2 mondat) nekem is jutott benne.

A Virus Bulletin már hosszú ideje minősíti az antivírus termékeket, és úgy érezték, eljött az idő, hogy a spamszűrőket is nagyító alá tegyék. Ez annál inkább reális ötletnek tűnik, mert több gyártó nem csak vírusírtót, hanem spamszűrőt is gyárt.

Spamszűrőt tesztelni azonban nem egyszerű, azt kell ugyanis megvalósítani, hogy a teszt környezet minél életszerűbb legyen. Kiváncsi vagyok, mit hoznak ki az egyes termékekből, ill. arra még inkább, hogy lesz-e nyílt forrású termék a palettán. A spamellenes harcnak az éllovasai ugyanis ilyen jellemzően megoldások.

Az első teszt eredménye január vége felé várható. Amint elérhető lesz, ezen a blogon is megemlékezem róla.

Érdeklődve figyelem a dspam projekt sorsát, aminek több oka is van. A dspam egy enterprise-level statisztikai spamszűrő, amelyet Johnathan Zdziarski hozott létre, és számtalan helyen használják.

A dspam levelezőlistáját többek között azért is átlapozom időnként, hogy ihletet merítsek, milyen új feature-t kellene/lehetne még a clapfba építeni.

Időközben Zdziarski eladta a dspam projektet domainnel együtt a Sensory Networksnek (SN), akik pl. gyorsítókártyát is építenek. Az elején úgy tűnt, hogy minden szép, és minden jó, de idővel kiderült, hogy új dspam verziók nem nagyon jönnek ki, de akár úgy is fogalmazhattam volna, hogy a tranzakció óta egy sem.

Ez pedig elég nagy probléma, mert a felhasználói igények folyamatosan változnak, amit jó ha valamilyen szinten figyelembe vesz a/akármelyik projekt. Igen ám, de hiába is bátorította a népet az SN képviselője a népet, hogy ha jelentkezik egy elkötelezett fejlesztő, akkor ők támogatják. Senki nem állt ki a placcra, hogy én fejleszteni akarom a dspamet.

A levelezőlistán többen is megelégelték a Sensory Networks tehetetlenségét (vagy ha jobban tetszik, koncepciótlanságát), és létrehozták a DSPAM-COMMUNITY nevű projektet, ami a 3.8.0-ás verzióra épül, annak a forkja. Ez azért sem egy haszontalan lépés, mert az SN bejelentette, hogy szívesen eladnák a dspam portfolióját valakinek. Január végén ugyanis lekapcsolják a dspam dolgait hosztoló gépet, hacsak valaki nem jelentkezik, hogy átvenné a projektet.

Bár én egy konkurens spamszűrőben vagyok érdekelt, de szomorú lennék, ha a dspam eltűnne a süllyesztőben. Szerencsére a community projektnél máris van 6 fejlesztő. Kiváncsi vagyok, merre viszik tovább a dspamet…

Az utóbbi napokban nem új feature-ket adtam a spamszűrőhöz, hanem átdolgoztam néhány részletet. Arra kerestem ötletet, hogyan lehetne a MySQL lekérdezéseket gyorsítani. Eddig ugyanis azt a nem túl eredeti ötletet követtem, hogy a tokenek listáján végigmentem, majd elsütöttem egy selectet. 2k token esetén ezt 2k selectet eredményezett, ami azért – hiába gyors a MySQL – eltartott pár száz millisecundumig.

Mostmár azonban egy SELECT … WHERE token IN (…) jellegű SQL utasítást építek fel, és egy menetben kérdezem le az összes tokent. Ez 7-8x-os sebességnövekedést jelent, azaz a clapf ennyivel kevesebb ideig gondolkozik, hogy egy adott levél az ham vagy spam.

Összedobtam egy VMware virtuális masinát, és ráeresztettem 3159 levelet (2002 spam, 1157 ham levél) egy olyan felhasználóra, aki egy alias a /dev/null-ra. Az eddigi verziónak átlag ~800 ms-ba telt, amíg végzett egy levéllel, most azonban átlag ~110 ms alatt dönteni tudott egy levélről. A leveleket szekvenciálisan küldtem SMTP-vel a teszt gépre, ami nem jelenti azt, hogy a clapf egyszerre csak egy levéllel foglalkozott. A postfix ugyanis párhuzamosan, több levelet engedett a clapf spamszűrőre, amely így átlag 5 levél/sec teljesítményt ért el.

Ez nem tűnik túl soknak, de ez a teszt nem arra ment ki, hogy minél nagyobb áteresztőképességet érjek el (erre amúgy sem egy virtuális gép a legmegfelelőbb terep), hanem hogy növeljem a program teljesítményét. 800 ms helyett ~110 ms elég jó teljesítmény.

A korábbi postban említett cache démonról még nem mondtam le, majd visszatérek még rá. Eközben alapos módosításokat végeztem szinte minden .c és .h fájlban. A leggyakrabban használt függvényekben az adat struktúrákra mutatóval hivatkozom, ami még gyorsít egy kicsit, mert nem kell memóriaterület másolni.

Szóval ezek kerültek be a 0.4.0-rc2-be. Elvileg minden (eddigi) funkció rendben működik. Ha nem jön elő bug a következő hetekben, akkor jó lesz a végleges 0.4.0-nak is.

Seres Mária mongyon le! Az egész még tavaly november 18-án kezdődött, amikor egy ismeretlen a haszker.hu nevű gépről (91.120.50.16) spamet küldött az említett hölgy nevében, az a.geza.54@gmail.com email címről.

A levél témája egy népszavazási kezdeményezés, amely a képviselők költségelszámolásával kapcsolatos. Most azonban nem ez az érdekes, hanem az oldalhullámok, amit ez a mozgósítás kavart.

December 18-án jött egy újabb levél, ezúttal a szekeres.csabi@gmail.com email címről, de érdekes módon szintén a haszker.hu gépről (91.120.50.16). Ebben szerepel egy képviselő feleségének a méltatlankodása, hogy ne kotorásszanak a férje zsebében, stb, ill. Seres Mária állásfoglalása.

A “Seres Mária spamet” bizonyára olyanok is megkapták, akik nem osztják ezt a lelkesedést, mert a jelek szerint többen is írtak Seres asszonynak, és úgy tűnik, hogy nem szépeket, mivel ő idén január 3-án küldött egy levelet a sereslevelek@freemail.hu címről, és már te is tudod, hogy honnan: haszker.hu (IP-cím: 91.120.50.16).

Seres asszony ezúttal arra kéri az érintetteket (akik megkapták a Seres-spamet), hogy trágárkodás helyett inkább jó volna a levél végén levő linkre kattintani, hogy leiratkozzanak a www.seresmaria.hu-n – igen, ez is a haszker.hu (91.120.50.16) gépen van – ha nem érdekli őket ez az arcátlan panama (=a képviselők költségelszámolása).

“Akinek pedig emiatt volt valamilyen kellemetlensége, elnézést kérünk érte, de ez rajtunk kívülálló okok mia tt történhetett, mivel a levelezõlistára az ismerõsei vagy levelezõpartnerei is felírhatták vagy ajánlhatták a tudtán kívül. A szemrehányó levelek növekedése miatt jó okom van feltételezni sajnos azt is, hogy a honlapomon keresztül rosszakaróink szándékosan mások címeit megadva mérgezik meg a levelezõlistánkat, hogy feljelentést tegyenek a címzettek.”

Aha! Tehát azért kapom a csapda email címemre már az n+1-dik Seres Mária-spamet, mert az ismerőseim felírtak, esetleg rosszindulatú egyének mérgezik a címlistáját – és mindezt a tudtomon kívül. De így folytatja Seres:

“Mivel vétlenek vagyunk [...]“

Ó persze, vétlenek. Meg idétlenek. Létezik még ember, aki ne tudná, hogy címlistára csak megerősítéssel szabad felvenni bárkit is? Teljesen jól írja informer a HUP egyik fórumában, hogy “én nem akarok leiratkozni, mert fel sem iratkoztam!”

Néhányan tovább léptek, és a morgás helyett/mellett feltöltötték a Spam Wiki-re a Seres-spamet. Azonban Sipos Zoltán (Blogadmin) ezeket törölte, és az alábbi állásfoglalást tette közzé:

“[...] állásfoglalásunk szerint nem spam (kéretlen kereskedelmi célú üzenet), hanem személyes célú elektronikus levél.”

Abban igaza van, hogy ez nem kereskedelmi ajánlat, hanem valóban egy magánszemély levele, de ez ettől még ugyanúgy kéretlen, és sokakat irritáló, mint a hagyományos Viagrás levél.

A fórum nyitója, informer sem értette ezt, de kz86 azt írja, hogy “Blogadmin = blogin, azaz tomcat cimborája, a Seres Mária spamek meg a zöld párt szerveréről jönnek, aminek tomcat is tagja. A haverok spamelhetnek, másokat meg lejáratnak, ilyen egyszerű.”

Egy biztos: a spamszűrőt meg lehet tanítani a Seres spammel is, ill. én is csak elküldöm az NHH-nak ezt is, hátha rábírják a Seres-kompániát, hogy ők maguk kiszűrjék a nem önkéntes alapon bekerült email címeket az adatbázisukból. Mert a csapda email címemmel garantáltan sehova nem irtakozom fel. Sokkal inkább arról van szó, hogy a Seres Mária mögött/mellett álló technikai brigád is pont ugyanazokat az eszközöket használja, mint a megvetett spammerek.

Azon tűnödtem – így az év első napjaiban, meg már az előző utolsóiban is – hogyan lehetne gyorsítani a clapf statisztikai elemzésén? A szűk keresztmetszet a MySQL token adatbázis lekérdezése, azaz az I/O-műveletek.

Mert én ugyan a széles nyílvánosság számára nem publikált “mydb” fantázianevű token adatbázist használom, amivel egy átlag levél n * 10 msec alatt kategorizálható, de akik a MySQL backendet használják, azoknál ez tovább tart.

Szóval magamban hangosan gondolkodva azt találtam ki, hogy a clapf démon induláskor betölti a memóriába, pontosabban egy hash szerkezetbe a tokeneket, és a child processzek, amelyek a leveleket kategorizálják, már nem a MySQL démontól kérdezik le az egyes tokenekhez tartozó számlálókat, hogy abból még kiszámolják a spam valószínűségeket, hanem ebből a hash-ből olvasnák ki közvetlenül a tokenekhez tartozó valószínűségértékeket. 1 tokenhez 8+4(+4) byte tartozna, azaz 1 MB-on 64k rekordot lehetne tárolni.

Nekem jelenleg ~60k token van az adatbázisomban. Ha ennek a duplájával számolunk, akkor az 10 child processz esetén ~22 MB memóriaigényt jelent, ami nudli. Ha pedig enterprise-level alkalmazásról van szó, akkor ott alaposan ki szokták bélelni memóriával a gépeket, így ott sem gond a memóriahasználat.

Az első időkben persze ennél sokkal több token is lehet a MySQL adatbáisban, amíg le nem tisztul, hogy melyek a hasznos tokenek, és ki nem hullanak az érdektelenek, így lesz majd egy változó, ahol be lehet állítani, hogy max. hány token legyen a hash-ben. Így nem szalad el a ló a memóriafoglalással, mert a fork() miatt minden child processznek szüksége van az x MB memóriára.

Ezért az alábbi algoritmust találtam ki. Addig folytatom a keresést, amíg a tokenek száma a beállított érték (max_tokens) alá esik.

1. select count(*) from t_token where uid=0
2. select count(*) from t_token where uid=0 and NOT (nham=0 and nspam=1)
3. select count(*) from t_token where uid=0 and (nham + nspam)=1
4. select count(*) from t_token where uid=0 and (nham + nspam) <= 2
5. select count(*) from t_token where uid=0 and (nham + nspam) <= 2 and erdekesseg > 0.2
6. select count(*) from t_token where uid=0 and (nham + nspam) <= 2 and erdekesseg > 0.2 ORDER BY timestamp DESC LIMIT max_tokens

Az egyelőre fejben/blogban levő megoldás egyetlen hátránya, hogy induláskor kell egy full table scan, ami pár másodpercig azért eltarthat. Minden frissítéskor szintén kell az előbb említett full table scan, de ha már fut-robog a kicsi kocsi, akkor ezt észre sem lehet venni.

A tanítás továbbra is közvetlenül a MySQL adatbázisba történne, így 5 perces frissítési időközökkel számolva a token adatbázis módosítása 5 perces késleltetéssel terjed az éles/használt tokenek közé, ami általában elfogadható.

A MySQL adatbázisban az egyes tokenekhez egy timestamp-et is tárolok, amit a child processzek kilépéskor egy nagy UPDATE utasítással frissítenek az SQL táblába. Hogy a nem használt tokeneket ki tudjam hagyni ebből, ehhez kell még egy byte (kb. a dirty bit mintájára), amit beállítok, ha az adott tokent lekérdeztem.

A megoldásnak van/lesz még egy hátránya: közös (shared) token adatbázis kell hozzá, azaz mindenki ugyanazon a token halmazon osztozik. Ahol ez nem megfelelő, vagy megbízhatatlanoknak is meg kell adni a tanítás lehetőségét, ott továbbra is a jól bevált, közvetlen MySQL backend használata a járható út.

Hamarosan lekódolom, aztán majd jön egy benchmark, hogy mit gyorsít ez a levéláteresztő-képességen.

Igazság szerint van még egy ötletem a gyorsításra: ugyanezt egy threaded démonon keresztül megoldani, mert abban az esetben csak 1 példányban szerepel a hash tábla a memóriában, így ez sokkal gazdaságosabb megoldás, viszont a hálózati kommunikáció is időbe telik, mire egy nagy halom tokent át tudok vinni. Ennek további erénye, hogy nem nagyon kell azzal foglalkozni, hogy csak x db tokent olvashassak be. Majd ezt is kipróbálom még.