[kismac] Re: Large files/nos of APs
- From: siddhart <siddhart@xxxxxxxxxxx>
- To: kismac@xxxxxxxxxxxxx
- Date: Sun, 23 Jan 2005 13:44:01 +0100
hi mick,
first of all you designed and coded an outstanding application for
macos users. thanks a lot for that.
i personally had a lot of fun with it so far and it inspired me for my
own work which is settled around network and media art.
i appreciated the satement below as it explains how the thing works and
where the difficulties are. kismac is a highly specialized application
which made it possible to stumble passivly with a mac. that is a
milestone. it is up to every user what he or she is doing with the
created dataset and information. i personally am not that much into
security issues of wireless networks but more interested in mapping
networkstructures as topographical analysis. i didn't mean to scream
for more userbility when i posted my experiences with large files, i
just wanted to let you know.
sven o. heinze
Am 22.01.2005 um 19:06 schrieb Michael Rossberg:
let me just write a small statement to this. i use kismac primarily as
a test suite for single networks, lets say up to the size of a
university.
as many of you probably can remember, kismac used to be much slower
back in the really old days. back then i improved speed a lot by
replacing generic apple cocoa objects with highly specialized c
functions. even now it would be possible, by exchanging parts of
kismac, to improve some functions. for an example the save files could
be made more proprietary in order to gain more speed. i will keep
looking for areas in the code, where a optimization will actually gain
something.
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.
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. this project
size requires a commercial development team. sorry.
mick
- References:
- [kismac] [OpenSVN] r54 committed: KisMACng/KisMAC.xcode/mick.mode1KisMACng/KisMAC.xcode/m
- From: mick . bi
- [kismac] Re: [OpenSVN] r53 userexperience
- From: siddhart
- [kismac] Large files/nos of APs
- From: ard jonker
- [kismac] Re: Large files/nos of APs
- From: Michael Rossberg
Other related posts:
- » [kismac] Large files/nos of APs
- » [kismac] Re: Large files/nos of APs
- » [kismac] Re: Large files/nos of APs
- » [kismac] Re: Large files/nos of APs
- » [kismac] Re: Large files/nos of APs
Am 22.01.2005 um 19:06 schrieb Michael Rossberg:
as many of you probably can remember, kismac used to be much slower back in the really old days. back then i improved speed a lot by replacing generic apple cocoa objects with highly specialized c functions. even now it would be possible, by exchanging parts of kismac, to improve some functions. for an example the save files could be made more proprietary in order to gain more speed. i will keep looking for areas in the code, where a optimization will actually gain something.
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.
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. this project size requires a commercial development team. sorry.
mick
- [kismac] [OpenSVN] r54 committed: KisMACng/KisMAC.xcode/mick.mode1KisMACng/KisMAC.xcode/m
- From: mick . bi
- [kismac] Re: [OpenSVN] r53 userexperience
- From: siddhart
- [kismac] Large files/nos of APs
- From: ard jonker
- [kismac] Re: Large files/nos of APs
- From: Michael Rossberg