[CFT]: ipfw named tables / different tabletypes

[bycn82]

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:rizzo at iet.unipi.it]
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pps_and_ppt.patch
Type: application/octet-stream
Size: 5434 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20140606/5a16e3a4/attachment.obj>