Re: [Wipsim-devel] Improved sniff-framework

[Martijn K. <mar...@lx...>]

On Thu, 2003-11-27 at 14:02, Gerben Kuijpers wrote:
> Hi,
> 
> Good idea to improve the sniff-framework. Had been thinking about that as
> well. Currently there are two different ways of writing information in the
> sniff-file:
> 
> 1. Individual events, that are written to the sniff-file by calling one of
> the functions of cSniff.
These are the ones I want to put in the new framework

> 2. Combined statistics on e.g. control traffic in AODV, which is collected
> by local sniff modules. The sniff modules are typically implemented as a
> singleton class. At the end of the simulation the cSniff module calls all
> local sniff modules so they can write all the collected information to the
> sniff-file.
I don't want to touch these (for now at least).


> > I am becoming more in favour of a printf-like function.
> > Maybe somthing like
> > sniff(SEND,"Sending frame %d of length %f",cFrame->Id(),
> > cFrame->Size());
> This looks like a good idea to me. This way, the cSniff class does not
> need to have a large number of functions and more important, it does not
> need to know the details of the different protocols. Currently the cSniff
> class calls functions of cFrame, cPacket etc.
Ok, so we go this way...

> > Since the sniff function is a private-derived function of cSniffElem,
> > the class from where it is called can easilly convert this into this:
> > cSniff->Sniff("Sending frame 2 of length 24");
> Another advantage of having the class from where the sniff is called
> handle the details, is that you can more easily fine tune what is
> outputted to the sniff file on a per-event basis.
Exactly, make testing/debugging more easy for the developper.


> Normally C uses block I/O to write to files, meaning
> > only after some bytes (4096) are written to a file, the data will be
> > transfered to disk. We could force a data transfer each time by calling
> > fflush(), but this would slow things down, as disk access is a slow
> > process. Again, for this we could make an option (-df, direct flush).
> Although this can be nice for debugging purposes sometimes, this is IMO
> not a high priority feature. If you are debugging and need all output that
> is sent to the sniff file until you arrive at a breakpoint (or crash) you
> can always just output the sniff to STDOUT instead. At least that works
> fine for me.
As far as I know, stdout behaves just like a file...so maybe adding this
as a parameter would not hurt anyone. I guess we can do this in a smart
way, with a check ones and after that just use the function by its
pointer.


> > Each class also needs a standard framework to store the
> > sniff-information. I guess that a __int16 would give you 16 different
> > sniff-event, which should be more than enough (since it is static for
> > all similair classes, it only takes 16 bits once).
> 65536 Sniff events in WIPSIM should be enough for everyone! :)
Nope, 16 events per class/protocol. Because you want to use each bit
from the __int16 as a boolean, so you can sniff more than 1 event from
bluetooth (send, recv, ...whatever, but up to 16).

>
> > So instead of having all these command-line parameters, I would like to
> > propose to add the following statements to the scn-file.
> >
> > 0.00 snf MAC BT +ALL
> > would turn on all bluetooth sniffing (I guess that using MAC or DLC for
> > BT would have the same effect), and
> >
> > 0.00 snf MAC 802.11 +rcv
> > would turn on sniffing for all recv events of the 802.11 mac
> >
> > 1.00 snf MAC 802.11 -ALL
> > would turn off all sniffing for 802.11
> >
> > Similair you could switch on debugging info for for instance the ping
> > application by
> > 0.00 dbg app ping
> >
> > So what is the difference between dbg and snf?
> > Well, snf either goes to stdout or to the sniff-file, while sbg goes to
> > stderr (or to a dbg file if you wish, because I am not sure whether
> > windows has stderr).
> Windows has stderr as well.
Learn somethng new every time ...


> But I'm not sure we should send debug output to stderr. In my view there's
> three types of output of the simulator:
> 1. Sniff events: used to evaluate the performance of protocols, when
> running the simulator for its right purpose. This output can be used by
> users of the simulator and for developers to do functional tests of the
> implementation of a specific protocol (black box testing).
> 
> 2. Debug output: used to check the implementation of specific protocols by
> the developers (white box testing). This output is not supposed to be used
> in stable versions of the simulator.
> 
> 3. Warnings and Errors: used to indicate (to both user and developer) that
> something might go wrong or went wrong.
Maybe we could add a weight to it.
For instance 
-dbg or -dbg0	- write to stdout
-dbg1		- write to stderr

For me it makes sense to have debug info send to stderr (prefix [DEBUG]
or something), because it is often this info together with the
warnings/errors will tell you what has happened.

> the 3rd type definitely should be sent to stderr, but I'm in doubt about
> number 2. Do we need seperate files for debug output / warning and errors?
I hope not, I am trying to reduce the number of parameters. So far we
already have some files:
.nwk, .cfg, .scn, .snf of which only .cfg is optional.

Come to think of it:
It makes sense to me to have the .nwk, .cfg and .snf file mentioned in
the .scn file. Something like:
//----------------------------
// This is the scenario-file
use cfg examples.cfg	// optional
use nwk bridge.nwk
use snf bridge_out.txt //or whatever)
use seed 0x1234		// optional
snf MAC BT +ALL
snf MAC 802.11 +ALL
snf DLC 802.11 +ALL
snf APP ping +snd +rcv
// Maybe we can add some static configuration stuff (can't think of 
// any right now)

// Followed by what we already have:
0.000 app Ping ::1 ::2 1
50.00 stop
//----------------------------

This way you can start the simulator by:
./wipsim bridge.scn -dbg

Does this sound like a plan (yes, I really got tired of typing things
like:
./src/wipsim scripts/examples.cfg scripts/bridge.nwk scripts/ping.scn
scripts/bridge.snf -mac -snk -drp -rt -snd -bt)

The only parameters we have are then
scenario-file		// No need to have special file extensions
-dbg[0/1]		// debugging stuff
-df			// direct flush all output
-info [filename]	// make a info-file


/Martijn