mailing list archives
Re: Nmap GUI
From: Sam <samara.brin () gmail com>
Date: Sun, 26 Jun 2005 22:23:00 +0530
I went through your project proposal in http://home.no.net/grodaas/nmap/.
I have some comments about the use of Sqlite and also about the database
support in general.
Sqlite 3 supports a single writer at a time. When a process is
writing to the database, the entire database is locked and no other
process is alllowed to read or write from the database. This may be a
bottleneck if you want to simultaneously write the output of many
scans to a single database. There are other databases like IBM
Cloudscape/derby that support multiple writers that you may look into
if not done already.
Sqlite does support the use of multuple databases (a separate file
per database), but use of multiple databses may deafeat your purpose
of using a database ( I gathered from your design that you intend to
store the results of the scans in a single db).
2. Transaction support overhead:
AFAIK, Sqlite provides crash recovery and there is no option to
turn it off. This may be a big overhead. In my opinion, crash recovery
is not required in nmap. You can probablly use a db that provides
concurrency support without the overhead of crash recovery.
3. XML databases:
There are native xml databases available that store and query xml
data directly. Avoids the overhead of converting xml scan output into
relational data. One good link may be
Some versions of berkeley xml db have support for concurrent
writers without the transactional support overhead.
I hope these points were of some help.
Sent through the nmap-dev mailing list
Nmap GUI Grodås, Ole Morten (Jun 25)
Re: Nmap GUI Sam (Jun 26)