Am Freitag, 10. Januar 2014, 11:09:07 schrieb Henri Doreau: > 2014/1/10 Jan-Oliver Wagner <[email protected]>: > > that network-wide scanning is the last feature using the kb-saving > > feature. With the redis approach the drawback of host vs network scans > > can easily be overcome without nasty handling of special kb files. > > Yes, it's just a little bit of work which I guess shouldn't be that > difficult.
OK. Thats what I basically hoped for :) > >> - What was already called "old style kb access" doesn't work anymore. > >> > >> This only impacts nasl_builtin_find_services. The difficulty here is > >> that the concerned code looks like hell (or even worse: hell with > >> tabs). > > > > Perhaps it makes sense to work on making this use the "new" kb first > > before doing the redis migration? > > Yes, I think so too. > > I'd appreciate some help on this. I would eventually do it otherwise > but I first want to pursue my work on corner-cases (retry mechanisms, > no DB available, redis offline...) and documentation. Anyone ;-) ? > > What also comes to my mind: How about multiple concurrent scans? > > How are the data of the different scans kept separate from each other? > > My email contained a brief description of how concurrency is handled: > """ > Concurrency is achieved using redis "databases". The database zero > contains a special variable (called "OpenVAS.__GlobalDBIndex") that is > an array of the available (or not) namespaces. Concurrent scans acquire > ownership atomically by using a test-and-set instruction on the > GlobalDBIndex bitmap. > """ > > Redis databases are like namespaces. Redis' default number of > databases is 16, which can be a limitation: with 4 hosts scanned in > parallel per task, you would only have 3 tasks running concurrently > (DB #0 is reserved). I use 64 in my redis configuration. > > Or were you referring to more restrictive mechanisms? If so, there are > simply none. Some thoughts: - It needs to be ensured that any interference between two scans is prevented. - Scanning several hosts within one scan is something that does not need strict separation. Especially considering that we want network-wide scans it is even necessary to handle them together or mutually accessible (in a single database?) - It would be not unusual to have several 100s or even more hosts scanned concurrently. Even up 100 or more concurrent tasks are possible. All the best Jan -- Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460 Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-devel mailing list [email protected] https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-devel
