Pavel Kácha wrote:

Bodík: pokud prijimaci kllient nejakou dobu stoji a pak se probudi tak prijem vyOOMuje ten perl
Bodík: to se mi stalo kdyz sem si bootstrapoval databazi
Bodík: ono je to logicky
Bodík: ja sem si schvalne posunul ID na 1
Bodík: a ten perlo to potom neprijme
pharook: je potřeba limit kolik toho klient může stáhnout najednou, aby to nesáčkoval do paměti
Bodík: tohle se stane kazdymu kdo si spatne zacachruje s IDckem nebo se odmlci natolik ze pro nej bude nachystano prilis mnoho dat nez dokaze najednou zpracovat
Bodík: limit sme chteli ale zatim se nejak neimplementoval

Pridame, ale az do nove verze klietna, ne do warden-client-2.0.

Návrh¶

Problém: Dlouho "spící" přijímající klient po probuzení stahuje nadměrnou dávku dat, na kterou nemá dostatek paměti

Řešení: Stahovat zprávy nikoliv vše najednou, ale po rozumných dávkách. V současné podobě architektury zasahuje do API jak mezi klientem a serverem tak i mezi klientskou knihovnou a klientskou aplikací.

Poznámka: V tomto úkolu neřešíme problém "ochrany" serveru před nenažranými klienty (to řeší úkol #526). Zde jde o ochranu klientské aplikace před nechtěnou (mnohdy neočekávánou a výjimečnou) nadměrnou konzumací paměti i jiných zdrojů systému ze strany klientské knihovny. Pokud si uživatel záměrně nastaví a bude spouště klienta v "nenažraném" režimu, je to v zásadě jeho problém.

Klient-server API¶

Pravděpodobně není možné rozumně sdělit serveru, že klient požaduje omezené množství zpráv, jinak, než rozšířením současného API.

Varianty s rozšířením počtu atributů při registraci na Warden server o položku "max. počet zpráv najednou" neuvažuji. HW nároky představují problém na straně klienta a mohou se měnit v čase bez ohledu na stav registrace a klienta vůči serveru vůbec, proto je vhodné ponechat.

Nabízí se rozšířit volání serverové funkce getNewEvents, resp. objekt $request_data (SOAP::Data) o atribut MAX_EVENTS_TO_RECEIVE (vedle existujících REQUESTED_TYPE a LAST_ID). Server poté předá klientovi maximálně tolik zpráv, kolik je uvedeno v této hodnotě.

Zpětná kompatibilita¶

Nebude-li hodnota MAX_EVENTS_TO_RECEIVE uvedena (bude-li undef), lze klienta považovat za starou verzi, případně za klienta, kterému velké dávky zpráv nevadí. V takovém případě vrací server maximum možných zpráv (resp. menší z hodnot: počet nových zpráv, limit serveru pro velikost jedné dávky nových zpráv. viz #526)

API mezi klientskou aplikací a knihovnou¶

Úzce se dotýká #519.

TODO

Statické nastavení velikosti dávky¶

MAX_EVENTS_TO_RECEIVE v konfiguráku

TODO

Dynamické nastavení velikosti dávky¶

Dynamický atribut při voláni WardenClientReceive::getNewEvents

TODO

API mezi klientskou aplikací a knihovnou¶

Návratové hodnoty¶

Úzce se dotýká #519. Je třeba vyřešit, jakým způsobem sdělit nadřazené aplikaci, zda byla stažena všechna data nebo byl vyčerpán limit a je vhodné spustit stahování znovu.

Lze řešit prostřednictvím rozšířené struktury návratových hodnot (řeší se v #519) - např. MAX_EVENTS_LIMIT_REACHED = true/false v hashi, kterou klientská funkce bude vracet.

Statické nastavení velikosti dávky¶

MAX_EVENTS_TO_RECEIVE v konfiguráku.

Dynamické nastavení velikosti dávky¶

Atribut v hashi při voláni WardenClientReceive::getNewEvents. (Opět souvisí s #519 a rozhraním funkcí).

Je-li atribut přítomný dynamicky při volání, neřeší se už hodnota nastavená v konfiguráku.

Do serveru jsem pridal podporu pro $MAX_RCV_EVENTS_LIMIT viz revize 47e20d2e a posleze i 4422a2b2. Pokud klient neprijde s zadnym limitem, je pouzit limit serveru (zpetna kompatibilita), pokud prijde s limitem vyssim nez je limit serveru, tak je ignorovan a je pouzit limit serveru a pokud prijde s limitem, ktery je nizsi nez limit serveru, tak je konecne pouzit tento klientsky limit.

Do klienta jsem pridal moznost nastavit v konfiguraku maximalni pocet udalosti, ktery muze klient v jedne davce (v jednom zavolani fce getNewEvents) maximalne obdrzet (revize 8165af3e).

#-------------------------------------------------------------------------------
# MAX_RCV_EVENTS_LIMIT - maximum number of events the client is allowed to get
#                        from the Warden server in one batch
#-------------------------------------------------------------------------------
$MAX_RCV_EVENTS_LIMIT = 50;

• doplnit do changelogu, readme
• zvazit, zda a jakou hodnotu nastavovat do konfiguraku implicitne pri instalaci (pripadne zda nabidnout uzivateli moznost si pri instalaci zvolit hodnotu parametrem) \
• zvazit, zda vubec na klientske strane provadet nejake kontroly vstupu pri cteni z konfiguraku

Upravil jsme v konfiguraku implicitni hodnotu $MAX_RCV_EVENTS_LIMIT na 6000. Tato hodnota mi generovala cca ctvrt giga peak.

• primo ve skriptu (vzdy tesne pred vracenim davky funkci getNewEvents):
  

   #memory test
    my $memusage = `ps h -o vsz $$`;
    print "events received: " . scalar @events . "\nmemory used: $memusage\n";
  

  • ukazkovy vypis (memory used v KiB):
    

    events received: 6000
    memory used: 224052
    +------------------------------------------------------------------------------------------------------------------------------------------+
    events received: 6000
    memory used: 243416
    +------------------------------------------------------------------------------------------------------------------------------------------+
    events received: 6000
    memory used: 246912
    +------------------------------------------------------------------------------------------------------------------------------------------+
    events received: 1293
    memory used: 247208
    +------------------------------------------------------------------------------------------------------------------------------------------+
    events received: 0
    memory used: 247208
    

• paralelne jsem kontroloval v topu a taky:
  

  cat /proc/13376/status | grep VmPeak
  

• hodnoty pro meho testovaciho klienta (typ portscan) pri prijimani 6000 zprav byly tesne pod hranici 250 MB. U narocnejsich zprav (napr. phishing jako IODEF/IDMEF v poznamce) bude urcite potreba nastavit individualni prah)

Aktualizoval jsem CHANGELOG a README o informace o davkovem prijimani udalosti a $MAX_RCV_EVENTS_LIMIT hodnote v konfiguraku (revize 6ead5f66). Implicitni hodnota 6000 do konfiguraku pridana v revizi 1a7634b1.