Charles, 1) I've adapted the code (will send a new diff Monday, maybe with a new name (see point 3))
2) you're right, but as explained before, I just doubled the effort for the test attribute (not totally knowing my way in the code for now) and there again the same argument applies. For the moment, both are silently ignored if there is no next attribute, as are probably most other attribute/typing mistakes. Changing the code to warn for all such cases is probably best done with a formal syntax+grammar check, but I don't feel positioned to provide that. 3) When reading the code, beware: - for the script, the chance is a real number from 0=never to 1=always; - in the code, chance is, because of efficiency reasons, an integer from 0 to RAND_MAX (as documented on the variable definition) This way, there are no float operations and only a compare to zero is needed. In fact I first just programmed first with floats and a test a<=b, but this has to be done on every branch and it was quite easy to optimise. So, in the code chance=0 indeed means always, and is the opposite of chance="0" in the script! If you know a decent name for the variable that indicates this interpretation better, I'm willing to change the name to help avoid confusion. 4) The behaviour you describe should be the goal (equivalent to whether the test on a variable fails/succeeds). Now, it is this part of the code on the variable test for which I don't really get what it tries to do, and so how to mimic the same for the chance test. In fact, I have the impression that the code part for the variable test shouldn't be there in the first place, as branching should only be looked at after you know what you received, and thus what state is triggered, and not while searching the match. But of course, I might be wrong in that, as, to be honest, understanding all this code correctly is not that easy. Best regards, MarcVD -----Original Message----- From: Charles P Wright [mailto:[EMAIL PROTECTED] Sent: 01 December 2006 14:56 To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: [Sipp-users] statistical (conditional) branching 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=DEVDE V> _______________________________________________> Sipp-users mailing list> [email protected]> https://lists.sourceforge.net/lists/listinfo/sipp-users **** 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
