[kismac] Re: Large files/nos of APs

At 7:06 PM +0100 2005-01-22, Michael Rossberg wrote:

 but i think we are hitting another barrier here. with 3000 access points
 the data volume becomes to big to be handled entirely in memory in real
 time. this means we need a database alike function within kismac. this
 on the other hand would mean no instant updates, as we cannot execute a
 couple of database calls whenever a packet comes in.

Have you checked out Berkeley db? You should be able to get transactional data rates and still handle very large databases. It is used as the implementing technology underneath MaxSQL, the full ACID-compliant version of MySQL. Should be pretty simple to program, too.

 the only solution that i see is an engine which uses for lately
 active networks a memory solution and for the rest a database
 backend. unfortunately i am not able to program in my spare time.

Berkeley db takes care of that for you, by caching in memory as much of the database as is being actively used as possible. Throw more memory at it, and it can keep the whole thing in memory. If you're short on memory, it runs a bit slower.

        But either way, you can handle millions of entries with relative ease.

this project size requires a commercial development team. sorry.

Maybe, but I'm not convinced. If I were a programmer, I'd go look at how postfix and sendmail interface with Berkeley db, and rip off code from them. Or maybe go to the Sleepycat website and look at their programming examples.

--
Brad Knowles, <brad@xxxxxxxxxxxxxxxxxxx>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

    -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
    Assembly to the Governor, November 11, 1755

  SAGE member since 1995.  See <http://www.sage.org/> for more info.

Other related posts: