Marc, This seems like a really useful feature, particularly for turning a Markov user-model into a SIPp XML file. I've looked at the code a bit, but have not actually run it. I just have four comments/questions:
(1) In scenario.c on line 783, you may want to replace the atof function with the get_double wrapper that I have written. get_double uses strtod and checks the return value, so that erroneous XML won't trip users up as much. (2) It seems that chance only makes sense if there is a next field, maybe a check for that should be added? (3) If chance is not specified, you set it to zero, why not 1? I can see from the code that a chance of zero means do it all the time, but why not pick 1, which would have the same effect. Additionally, then a chance of zero, would really be a probability of zero instead of a magic value. (4) I am not 100% sure about the optional receive behavior you are mentioning. It seems like that if an optional receive happens, and there is a next, and chance is false, you should go to the next message (as if the next was not there in the first place). Is this what happens, or is it something more insidious? Charles [EMAIL PROTECTED] wrote on 12/01/2006 06:56:45 AM: > Peter, > > you're totally right that normally you don't want to use this on an > optional receive and that it can be replaced by an unconditional > jump + pause or nop. > > That's why I find it so strange that in the code part I described > earlier, there is that weird special handling of the conditional > branch (test="x"), for which finally the same arguments apply. So > this way, I at least pointed out that there can be a difference in > behaviour between those two features, although users will probably > see them as totally similar. > > Best regards, > > MarcVD > > From: Peter Higginson [mailto:[EMAIL PROTECTED] > Sent: 01 December 2006 11:24 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]> Subject: RE: [Sipp-users] statistical (conditional) branching > Hi Marc, > > I have not looked at the code yet – I will I’m sure because it seems > a useful feature. > > I would have though that you would probably not want it in > combination with receive optional. The idea of the next in optional > is that you go there only when you get the optional packet – the > “normal” flow is in effect to ignore optional packets (although I > think the state machine steps) so I suppose that is a valid result. > > You would be better if you wanted a statistical response to an > optional packet to jump out to a 100ms pause and put the chance in > that. That way you get two possible responses. > > Peter > > Peter Higginson > Newport Networks Ltd, > Direct line 01494 470694 > http://www.newport-networks.com/ > > From: [EMAIL PROTECTED] [mailto:sipp-users- > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]> Sent: 01 December 2006 10:00 > To: [EMAIL PROTECTED]> Cc: [EMAIL PROTECTED]> Subject: [Sipp-users] statistical (conditional) branching > > Hello all, > to have sipp behave somewhat more like a "normal" sip client being > used by a human, I added statistical branching in the code. > In more detail: wherever you can have a conditional branch on a > variable being set (test="4"), you can also branch based on a > statistical decision using the attribute "chance" (e.g. chance="0. > 90"). Chance can have a value between 0 (never) and 1 (always), > "test" and "chance" can be combined, i.e. only branching when the > test succeeds and the chance is good. > With this, you can have a variable reaction in a given scenario (e. > g.. answer the call or reject with busy), or run around in a loop > (e.g. registrations) and break out of it after some random number of > iterations. > About the code: > As the feature is very similar to the conditional branch, I added it > on the code wherever conditional branching was handled. > There is one exception to this, where maybe it's not quite ok: in > the receive handling code around lines 2950-2990 in call.cpp, where > I couldn't get any clue on what exactly the goal/usage of that code > part was. Maybe the author of the "test" feature could have a look > at that?? Anyhow, the only possible problem the strange code part > could have, is with optional receives with a statistical branch in > it where the statistical decision would give a NO answer (everybody > is warned by this;-) > Anyhow, it should be working without problems on pause, nop, send > and non-optional receives. > <<sipp.2006-11-08.chance.diff>> > Best regards, > > MarcVD > > (-: from Marc VAN DIEST (BELGACOM ANS/NTA) +32 2 244 5078 ;-) > > **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Sipp-users mailing list > [EMAIL PROTECTED]> https://lists.sourceforge.net/lists/listinfo/sipp-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
