Sorry for waste you time to explain it again, I will read the code first. And the latest patch of `PPS` should be OK, I checked the logic carefully this time. I sent it out last weekend.
logic as below, PPS actually will be fulfilled using `PPT`,(N packets per M
ticks).
+ case O_PPT:
+ case O_PPS:{
+ ipfw_insn_pps *pps = (ipfw_insn_pps *)cmd;
+ if(pps->limit==0){
+ int limit,duration_in_ticks;
+ if(1000/hz > pps->duration){
+ duration_in_ticks=1;
+ }else{
+
duration_in_ticks=(pps->duration * hz +500)/1000;
+ }
+ limit=(cmd->arg1 *1000 *
duration_in_ticks + hz * pps->duration/2)/(hz * pps->duration);
+ pps->limit=limit;
+
pps->duration_in_ticks=duration_in_ticks;
+ }
+ if(pps->start_time+pps->duration_in_ticks>=
ticks){
+ if(pps->count < pps->limit){
+ retval = IP_FW_PASS;
+ }else{
+ retval = IP_FW_DENY;
+ }
+ pps->count++;
+ }else{
+ pps->start_time=ticks;
+ pps->count=1;
+ retval = IP_FW_PASS;
+ }
+ l = 0;
+ done = 1;
+ break;
+ }
> -----Original Message-----
> From: 'Luigi Rizzo' [mailto:[email protected]]
> Sent: 05 June, 2014 23:54
> To: bycn82
> Cc: 'Alexander V. Chernikov'; 'FreeBSD Net'
> Subject: Re: [CFT]: ipfw named tables / different tabletypes
>
> On Thu, Jun 05, 2014 at 10:49:27PM +0800, bycn82 wrote:
> > Hi Luigi,
> > Yes, use string instead of integer for the ID of table, but the same
> method cannot apply to the feature `set type of table`. And in the
> kernel, compare string will cause more than compare an integer. In my
> opinion, actually they are just alias name for the object. Users already
> accept that every object has an integer ID.
>
> Bill,
> I appreciate your enthusiasm on contributing to the project, but before
> starting to code, you (and everyone else, including myself) should spend
> some time at the drawing board, question your assumptions, and consider
> possible implementations.
>
> Also the fact that previous implementations had bugs or restrictions
> does not imply that we should repeat the same mistakes now.
>
> Specifically:
>
> - comparing strings in the kernel is perfectly fine, we do it all the
> time (sysctl names, filenames, interfaces and whatnot).
> What would be terribly wrong is having to do, on every packet,
> an expensive string or number lookup (note- it's the entire lookup
> process, not a string comparison) to locate the table.
> However, this is not the case.
> The way to implement named objects (tables etc.) is to accept strings
> as object names, and when the rule is added the string is checked
> and converted to a pointers or an integer which permits direct
> access to the table.
> This is as fast as it can be at runtime, which is all what matters.
>
> - at the moment tables and pipes have a single ID, which happens to be a
> sequence of digits for mostly historical reasons (you can read it
> as laziness of the original authors; i can take the blame for pipes).
>
> If we extend the namespace to include strings we improve the user's
> experience and remain compatible with the existing user interface.
>
> Instead, if we require users to create a mapping before using
> alphanumeric names, not only we add a step that was not there before,
> but also create two names for the same object which makes it harder
> to reason about the rulesets, and there is also the issue of how
> to handle references to non-existing tables (which are trivially
> supported now or with the approach i suggested, and would instead
> require rescanning the ruleset whenever a name-number association
> is added or deleted.
> Another troubles with that approach is that you opening a race
> window between the creation of the name-number mapping and its use,
> and this is also something you don't want in a security-related tool.
>
> We have had a similar discussion about your 'pps' extension for ipfw:
> useful feature, but your various implementations have issues (even the
> final one), and we have only so much time for reviewing patches; please
> do not burn it.
>
> cheers
> luigi
pps_and_ppt.patch
Description: Binary data
_______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[email protected]"
