Browse code

modules: readme files regenerated - app_lua_sr ... [skip ci]

Kamailio Dev authored on 25/05/2020 09:21:05
Showing 1 changed files
... ...
@@ -10,12 +10,8 @@ Edited by
10 10
 
11 11
 Ovidiu Sas
12 12
 
13
-Edited by
14
-
15 13
 Bogdan Vasile Harjoc
16 14
 
17
-Edited by
18
-
19 15
 Hendrik Scholz
20 16
 
21 17
    Copyright © 2006 Freenet Cityline GmbH
Browse code

modules: readme files regenerated - acc ... [skip ci]

Kamailio Dev authored on 28/02/2018 17:03:37 • The Root committed on 28/02/2018 19:11:36
Showing 1 changed files
... ...
@@ -303,7 +303,7 @@ modparam("ratelimit", "queue", "2:*")
303 303
 
304 304
    A pipe is characterised by its algorithm and limit (bandwidth, in ipfw
305 305
    terms). When specifying a limit, the unit depends on the algorithm used
306
-   and doesn't need to be spedified also (eg, for TAILDROP or RED, limit
306
+   and doesn't need to be specified also (eg, for TAILDROP or RED, limit
307 307
    means packets/sec, whereas with the FEEDBACK algorithm, it means [CPU]
308 308
    load factor).
309 309
 
Browse code

modules: readme files regenerated - ratelimit ... [skip ci]

Kamailio Dev authored on 31/05/2017 07:31:47
Showing 1 changed files
... ...
@@ -51,7 +51,7 @@ Hendrik Scholz
51 51
         6. Functions
52 52
 
53 53
               6.1. rl_check([pvar])
54
-              6.2. rl_check_pipe([pipe_no])
54
+              6.2. rl_check_pipe(pipe_no)
55 55
 
56 56
         7. RPC Commands
57 57
 
... ...
@@ -103,7 +103,7 @@ Chapter 1. Admin Guide
103 103
    6. Functions
104 104
 
105 105
         6.1. rl_check([pvar])
106
-        6.2. rl_check_pipe([pipe_no])
106
+        6.2. rl_check_pipe(pipe_no)
107 107
 
108 108
    7. RPC Commands
109 109
 
... ...
@@ -325,7 +325,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
325 325
 6. Functions
326 326
 
327 327
    6.1. rl_check([pvar])
328
-   6.2. rl_check_pipe([pipe_no])
328
+   6.2. rl_check_pipe(pipe_no)
329 329
 
330 330
 6.1.  rl_check([pvar])
331 331
 
... ...
@@ -334,8 +334,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
334 334
    type, and then the pipe will be identified based on the matched queue.
335 335
    If a pipe number is provided as a parameter, then the given pipe number
336 336
    will be used for identifying the ratelimit algorithm. The pipe number
337
-   must be provided via a pseudovariable. It is recommended to provide the
338
-   pipe number via an integer pseudovariable.
337
+   must be provided as number or via a pseudovariable.
339 338
 
340 339
    The method will return an error code if the limit for the matched
341 340
    algorithm is reached.
... ...
@@ -344,7 +343,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
344 343
      * pvar - the pseudovariable holding the pipe id to be used by
345 344
        ratelimit.
346 345
 
347
-   This function can be used from REQUEST_ROUTE.
346
+   This function can be used from ANY_ROUTE.
348 347
 
349 348
    Example 1.4. rl_check usage
350 349
 ...
... ...
@@ -353,7 +352,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
353 352
                 append_to_reply("Retry-After: 5\r\n");
354 353
                 sl_send_reply("503","Limiting");
355 354
                 exit;
356
-        };
355
+        }
357 356
 ...
358 357
         # use pipe no 1 for the current method
359 358
         # set int pvar to 1
... ...
@@ -362,25 +361,14 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
362 361
                 append_to_reply("Retry-After: 5\r\n");
363 362
                 sl_send_reply("503","Limiting");
364 363
                 exit;
365
-        };
366
-...
367
-        # use pipe no 1 for the current method
368
-        # set str pvar to 1
369
-        $var(p) = "1";
370
-        if (!rl_check("$var(p)") {
371
-                append_to_reply("Retry-After: 5\r\n");
372
-                sl_send_reply("503","Limiting");
373
-                exit;
374
-        };
364
+        }
375 365
 ...
376 366
 
377
-6.2.  rl_check_pipe([pipe_no])
367
+6.2.  rl_check_pipe(pipe_no)
378 368
 
379
-   Check the current request against the matched ratelimit algorithm. If
380
-   no parameter is provided, the queue will be matched based on method
381
-   type, and then the pipe will be identified based on the matched queue.
382
-   If a pipe number is provided as a parameter, then the given pipe number
383
-   will be used for identifying the ratelimit algorithm.
369
+   Check the current request against the matched ratelimit algorithm of
370
+   the pipe provided as parameter. The parameter can be provided as number
371
+   or variable.
384 372
 
385 373
    The method will return an error code if the limit for the matched
386 374
    algorithm is reached.
... ...
@@ -391,20 +379,13 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
391 379
    This function can be used from REQUEST_ROUTE.
392 380
 
393 381
    Example 1.5. rl_check_pipe usage
394
-...
395
-        # perform queue/pipe match for current method
396
-        if (!rl_check_pipe()) {
397
-                append_to_reply("Retry-After: 5\r\n");
398
-                sl_send_reply("503","Limiting");
399
-                exit;
400
-        };
401 382
 ...
402 383
         # use pipe no 1 for the current method
403 384
         if (!rl_check_pipe("1") {
404 385
                 append_to_reply("Retry-After: 5\r\n");
405 386
                 sl_send_reply("503","Limiting");
406 387
                 exit;
407
-        };
388
+        }
408 389
 ...
409 390
 
410 391
 7. RPC Commands
Browse code

modules: readme files regenerated - benchmark ...

Kamailio Dev authored on 14/01/2017 12:16:33
Showing 1 changed files
... ...
@@ -123,7 +123,7 @@ Chapter 1. Admin Guide
123 123
 
124 124
    This module implements rate limiting for SIP requests. In contrast to
125 125
    the PIKE module this limits the flow based on a per SIP request type
126
-   basis and not per source IP. The MI interface can be used to change
126
+   basis and not per source IP. The RPC interface can be used to change
127 127
    tunables while running Kamailio.
128 128
 
129 129
    The module implements the pipe/queue policy from BSD's ipfw manual,
Browse code

modules: readme files regenerated - app_jsdt ...

Kamailio Dev authored on 10/01/2017 22:31:22
Showing 1 changed files
... ...
@@ -53,7 +53,7 @@ Hendrik Scholz
53 53
               6.1. rl_check([pvar])
54 54
               6.2. rl_check_pipe([pipe_no])
55 55
 
56
-        7. Exported RPC Functions
56
+        7. RPC Commands
57 57
 
58 58
               7.1. rl.stats
59 59
               7.2. rl.set_pipe
... ...
@@ -105,7 +105,7 @@ Chapter 1. Admin Guide
105 105
         6.1. rl_check([pvar])
106 106
         6.2. rl_check_pipe([pipe_no])
107 107
 
108
-   7. Exported RPC Functions
108
+   7. RPC Commands
109 109
 
110 110
         7.1. rl.stats
111 111
         7.2. rl.set_pipe
... ...
@@ -407,7 +407,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
407 407
         };
408 408
 ...
409 409
 
410
-7. Exported RPC Functions
410
+7. RPC Commands
411 411
 
412 412
    7.1. rl.stats
413 413
    7.2. rl.set_pipe
Browse code

core, lib, modules: restructured source code tree

- new folder src/ to hold the source code for main project applications
- main.c is in src/
- all core files are subfolder are in src/core/
- modules are in src/modules/
- libs are in src/lib/
- application Makefiles are in src/
- application binary is built in src/ (src/kamailio)

Daniel-Constantin Mierla authored on 07/12/2016 11:03:51
Showing 1 changed files
1 1
new file mode 100644
... ...
@@ -0,0 +1,541 @@
1
+ratelimit Module
2
+
3
+Ovidiu Sas
4
+
5
+Bogdan Vasile Harjoc
6
+
7
+Hendrik Scholz
8
+
9
+Edited by
10
+
11
+Ovidiu Sas
12
+
13
+Edited by
14
+
15
+Bogdan Vasile Harjoc
16
+
17
+Edited by
18
+
19
+Hendrik Scholz
20
+
21
+   Copyright © 2006 Freenet Cityline GmbH
22
+
23
+   Copyright © 2008-2010 VoIP Embedded Inc.
24
+     __________________________________________________________________
25
+
26
+   Table of Contents
27
+
28
+   1. Admin Guide
29
+
30
+        1. Overview
31
+        2. Use Cases
32
+        3. Static Rate Limiting Algorithms
33
+
34
+              3.1. Tail Drop Algorithm (TAILDROP)
35
+              3.2. Random Early Detection Algorithm (RED)
36
+              3.3. Network Algorithm (NETWORK)
37
+              3.4. Dynamic Rate Limiting Algorithms
38
+              3.5. Feedback Algorithm (FEEDBACK)
39
+
40
+        4. Dependencies
41
+
42
+              4.1. Kamailio Modules
43
+              4.2. External Libraries or Applications
44
+
45
+        5. Parameters
46
+
47
+              5.1. timer_interval (integer)
48
+              5.2. queue (integer:string)
49
+              5.3. pipe (integer:string:integer)
50
+
51
+        6. Functions
52
+
53
+              6.1. rl_check([pvar])
54
+              6.2. rl_check_pipe([pipe_no])
55
+
56
+        7. Exported RPC Functions
57
+
58
+              7.1. rl.stats
59
+              7.2. rl.set_pipe
60
+              7.3. rl.get_pipes
61
+              7.4. rl.set_queue
62
+              7.5. rl.get_queues
63
+              7.6. rl.set_pid
64
+              7.7. rl.get_pid
65
+              7.8. rl.push_load
66
+              7.9. rl.set_dbg
67
+
68
+        8. Known limitations
69
+
70
+   List of Examples
71
+
72
+   1.1. Set timer_interval parameter
73
+   1.2. Set queue parameter
74
+   1.3. Set pipe parameter
75
+   1.4. rl_check usage
76
+   1.5. rl_check_pipe usage
77
+
78
+Chapter 1. Admin Guide
79
+
80
+   Table of Contents
81
+
82
+   1. Overview
83
+   2. Use Cases
84
+   3. Static Rate Limiting Algorithms
85
+
86
+        3.1. Tail Drop Algorithm (TAILDROP)
87
+        3.2. Random Early Detection Algorithm (RED)
88
+        3.3. Network Algorithm (NETWORK)
89
+        3.4. Dynamic Rate Limiting Algorithms
90
+        3.5. Feedback Algorithm (FEEDBACK)
91
+
92
+   4. Dependencies
93
+
94
+        4.1. Kamailio Modules
95
+        4.2. External Libraries or Applications
96
+
97
+   5. Parameters
98
+
99
+        5.1. timer_interval (integer)
100
+        5.2. queue (integer:string)
101
+        5.3. pipe (integer:string:integer)
102
+
103
+   6. Functions
104
+
105
+        6.1. rl_check([pvar])
106
+        6.2. rl_check_pipe([pipe_no])
107
+
108
+   7. Exported RPC Functions
109
+
110
+        7.1. rl.stats
111
+        7.2. rl.set_pipe
112
+        7.3. rl.get_pipes
113
+        7.4. rl.set_queue
114
+        7.5. rl.get_queues
115
+        7.6. rl.set_pid
116
+        7.7. rl.get_pid
117
+        7.8. rl.push_load
118
+        7.9. rl.set_dbg
119
+
120
+   8. Known limitations
121
+
122
+1. Overview
123
+
124
+   This module implements rate limiting for SIP requests. In contrast to
125
+   the PIKE module this limits the flow based on a per SIP request type
126
+   basis and not per source IP. The MI interface can be used to change
127
+   tunables while running Kamailio.
128
+
129
+   The module implements the pipe/queue policy from BSD's ipfw manual,
130
+   with some simplifications. In principle, each specified method is
131
+   associated with its own queue and a number of queues are connected to a
132
+   certain pipe (see the queue and pipe params).
133
+
134
+   Please also take a look at the “pipelimit” module, that implements the
135
+   pipe policy with database support. Note that it doesn't implement the
136
+   queues that exist in this module.
137
+
138
+2. Use Cases
139
+
140
+   Limiting the rate messages are processed on a system directly
141
+   influences the load. The ratelimit module can be used to protect a
142
+   single host or to protect an Kamailio cluster when run on the
143
+   dispatching box in front.
144
+
145
+   A sample configuration snippet might look like this:
146
+...
147
+        if (is_method("INVITE|REGISTER|SUBSCRIBE") {
148
+                if (!rl_check()) {
149
+                        append_to_reply("Retry-After: 5\r\n");
150
+                        sl_send_reply("503","Limiting");
151
+                        exit;
152
+                };
153
+        };
154
+...
155
+
156
+   Upon every incoming request listed above rl_check is invoked. It
157
+   returns an OK code if the current per request load is below the
158
+   configured threshold. If the load is exceeded the function returns an
159
+   error and an administrator can discard requests with a stateless
160
+   response.
161
+
162
+3. Static Rate Limiting Algorithms
163
+
164
+   3.1. Tail Drop Algorithm (TAILDROP)
165
+   3.2. Random Early Detection Algorithm (RED)
166
+   3.3. Network Algorithm (NETWORK)
167
+   3.4. Dynamic Rate Limiting Algorithms
168
+   3.5. Feedback Algorithm (FEEDBACK)
169
+
170
+   The ratelimit module supports two different statc algorithms to be used
171
+   by rl_check to determine whether a message should be blocked or not.
172
+
173
+3.1. Tail Drop Algorithm (TAILDROP)
174
+
175
+   This is a trivial algorithm that imposes some risks when used in
176
+   conjunction with long timer intervals. At the start of each interval an
177
+   internal counter is reset and incremented for each incoming message.
178
+   Once the counter hits the configured limit rl_check returns an error.
179
+
180
+   The downside of this algorithm is that it can lead to SIP client
181
+   synchronization. During a relatively long interval only the first
182
+   requests (i.e. REGISTERs) would make it through. Following messages
183
+   (i.e. RE-REGISTERs) will all hit the SIP proxy at the same time when a
184
+   common Expire timer expired. Other requests will be retransmitted after
185
+   a given time, the same on all devices with the same firmware/by the
186
+   same vendor.
187
+
188
+3.2. Random Early Detection Algorithm (RED)
189
+
190
+   The Random Early Detection Algorithm tries to circumvent the
191
+   synchronization problem imposed by the tail drop algorithm by measuring
192
+   the average load and adapting the drop rate dynamically. When running
193
+   with the RED algorithm (enabled by default) Kamailio will return errors
194
+   to the Kamailio routing engine every n'th packet trying to evenly
195
+   spread the measured load of the last timer interval onto the current
196
+   interval. As a negative side effect Kamailio might drop messages
197
+   although the limit might not be reached within the interval. Decrease
198
+   the timer interval if you encounter this.
199
+
200
+3.3. Network Algorithm (NETWORK)
201
+
202
+   This algorithm relies on information provided by network interfaces.
203
+   The total amount of bytes waiting to be consumed on all the network
204
+   interfaces is retrieved once every timer_interval seconds. If the
205
+   returned amount exceeds the limit specified in the modparam, rl_check
206
+   returns an error.
207
+
208
+3.4. Dynamic Rate Limiting Algorithms
209
+
210
+   When running Kamailio on different machines, one has to adjust the drop
211
+   rates for the static algorithms to maintain a sub 100% load average or
212
+   packets will start getting dropped in the network stack. While this is
213
+   not in itself difficult, it isn't neither accurate nor trivial: another
214
+   server taking a notable fraction of the CPU time will require re-tuning
215
+   the parameters.
216
+
217
+   While tuning the drop rates from the outside based on a certain factor
218
+   is possible, having the algorithm run inside ratelimit permits tuning
219
+   the rates based on internal server parameters and is somewhat more
220
+   flexible (or it will be when support for external load factors - as
221
+   opposed to cpu load - is added).
222
+
223
+3.5. Feedback Algorithm (FEEDBACK)
224
+
225
+   Using the PID Controller model (see Wikipedia page), the drop rate is
226
+   adjusted dynamically based on the load factor so that the load factor
227
+   always drifts towards the specified limit (or setpoint, in PID terms).
228
+
229
+   As reading the CPU load average is relatively expensive (opening
230
+   /proc/stat, parsing it, etc), this only happens once every
231
+   timer_interval seconds and consequently the FEEDBACK value is only at
232
+   these intervals recomputed. This in turn makes it difficult for the
233
+   drop rate to adjust quickly. Worst case scenarios are request rates
234
+   going up/down instantly by thousands - it takes up to 20 seconds for
235
+   the controller to adapt to the new request rate.
236
+
237
+   Generally though, as real life request rates drift by less, adapting
238
+   should happen much faster.
239
+
240
+4. Dependencies
241
+
242
+   4.1. Kamailio Modules
243
+   4.2. External Libraries or Applications
244
+
245
+4.1. Kamailio Modules
246
+
247
+   The following modules must be loaded before this module:
248
+     * SL: Stateless request handling.
249
+
250
+4.2. External Libraries or Applications
251
+
252
+   The following libraries or applications must be installed before
253
+   running Kamailio with this module loaded:
254
+     * None.
255
+
256
+5. Parameters
257
+
258
+   5.1. timer_interval (integer)
259
+   5.2. queue (integer:string)
260
+   5.3. pipe (integer:string:integer)
261
+
262
+5.1. timer_interval (integer)
263
+
264
+   The initial length of a timer interval in seconds. All amounts of
265
+   messages have to be divided by this timer to get a messages per second
266
+   value.
267
+
268
+   IMPORTANT: A too small value may lead to performance penalties due to
269
+   timer process overloading.
270
+
271
+   Default value is 10.
272
+
273
+   Example 1.1. Set timer_interval parameter
274
+...
275
+modparam("ratelimit", "timer_interval", 5)
276
+...
277
+
278
+5.2. queue (integer:string)
279
+
280
+   The format of the queue parameter is "pipe_no:method". For each defined
281
+   method, the algorithm defined by pipe number "pipe_no" will be used.
282
+
283
+   To specify a queue that accepts all methods, use “*” instead of METHOD.
284
+   As queues are matched against request methods, you will usually want to
285
+   have this as the last queue added or other queues with specific methods
286
+   will never match. At this time, glob or regexp patterns are not
287
+   supported.
288
+
289
+   Example 1.2. Set queue parameter
290
+...
291
+# assign pipe no 0 to method REGISTER
292
+# assign pipe no 3 to method INVITE
293
+# assign pipe no 2 to all other methods
294
+modparam("ratelimit", "queue", "0:REGISTER")
295
+modparam("ratelimit", "queue", "3:INVITE")
296
+modparam("ratelimit", "queue", "2:*")
297
+...
298
+
299
+5.3. pipe (integer:string:integer)
300
+
301
+   The format of the pipe param is "pipe_no:algorithm:limit". For each
302
+   defined pipe, the given algorithm with the given limit will be used.
303
+
304
+   A pipe is characterised by its algorithm and limit (bandwidth, in ipfw
305
+   terms). When specifying a limit, the unit depends on the algorithm used
306
+   and doesn't need to be spedified also (eg, for TAILDROP or RED, limit
307
+   means packets/sec, whereas with the FEEDBACK algorithm, it means [CPU]
308
+   load factor).
309
+
310
+   Example 1.3. Set pipe parameter
311
+...
312
+# define pipe 0 with a limit of 200 pkts/sec using TAILDROP algorithm
313
+# define pipe 1 with a limit of 100 pkts/sec using RED algorithm
314
+# define pipe 2 with a limit of 50 pkts/sec using TAILDROP algorithm
315
+# define pipe 3 with a limit of load factor 80 using FEEDBACK algorithm
316
+# define pipe 4 with a limit of 10000 pending bytes in the rx_queue
317
+#                                     using NETWORK algorithm
318
+modparam("ratelimit", "pipe", "0:TAILDROP:200")
319
+modparam("ratelimit", "pipe", "1:RED:100")
320
+modparam("ratelimit", "pipe", "2:TAILDROP:50")
321
+modparam("ratelimit", "pipe", "3:FEEDBACK:80")
322
+modparam("ratelimit", "pipe", "4:NETWORK:10000")
323
+...
324
+
325
+6. Functions
326
+
327
+   6.1. rl_check([pvar])
328
+   6.2. rl_check_pipe([pipe_no])
329
+
330
+6.1.  rl_check([pvar])
331
+
332
+   Check the current request against the matched ratelimit algorithm. If
333
+   no parameter is provided, the queue will be matched based on method
334
+   type, and then the pipe will be identified based on the matched queue.
335
+   If a pipe number is provided as a parameter, then the given pipe number
336
+   will be used for identifying the ratelimit algorithm. The pipe number
337
+   must be provided via a pseudovariable. It is recommended to provide the
338
+   pipe number via an integer pseudovariable.
339
+
340
+   The method will return an error code if the limit for the matched
341
+   algorithm is reached.
342
+
343
+   Meaning of the parameters is as follows:
344
+     * pvar - the pseudovariable holding the pipe id to be used by
345
+       ratelimit.
346
+
347
+   This function can be used from REQUEST_ROUTE.
348
+
349
+   Example 1.4. rl_check usage
350
+...
351
+        # perform queue/pipe match for current method
352
+        if (!rl_check()) {
353
+                append_to_reply("Retry-After: 5\r\n");
354
+                sl_send_reply("503","Limiting");
355
+                exit;
356
+        };
357
+...
358
+        # use pipe no 1 for the current method
359
+        # set int pvar to 1
360
+        $var(p) = 1;
361
+        if (!rl_check("$var(p)")) {
362
+                append_to_reply("Retry-After: 5\r\n");
363
+                sl_send_reply("503","Limiting");
364
+                exit;
365
+        };
366
+...
367
+        # use pipe no 1 for the current method
368
+        # set str pvar to 1
369
+        $var(p) = "1";
370
+        if (!rl_check("$var(p)") {
371
+                append_to_reply("Retry-After: 5\r\n");
372
+                sl_send_reply("503","Limiting");
373
+                exit;
374
+        };
375
+...
376
+
377
+6.2.  rl_check_pipe([pipe_no])
378
+
379
+   Check the current request against the matched ratelimit algorithm. If
380
+   no parameter is provided, the queue will be matched based on method
381
+   type, and then the pipe will be identified based on the matched queue.
382
+   If a pipe number is provided as a parameter, then the given pipe number
383
+   will be used for identifying the ratelimit algorithm.
384
+
385
+   The method will return an error code if the limit for the matched
386
+   algorithm is reached.
387
+
388
+   Meaning of the parameters is as follows:
389
+     * pipe_no - the pipe id to be used by ratelimit.
390
+
391
+   This function can be used from REQUEST_ROUTE.
392
+
393
+   Example 1.5. rl_check_pipe usage
394
+...
395
+        # perform queue/pipe match for current method
396
+        if (!rl_check_pipe()) {
397
+                append_to_reply("Retry-After: 5\r\n");
398
+                sl_send_reply("503","Limiting");
399
+                exit;
400
+        };
401
+...
402
+        # use pipe no 1 for the current method
403
+        if (!rl_check_pipe("1") {
404
+                append_to_reply("Retry-After: 5\r\n");
405
+                sl_send_reply("503","Limiting");
406
+                exit;
407
+        };
408
+...
409
+
410
+7. Exported RPC Functions
411
+
412
+   7.1. rl.stats
413
+   7.2. rl.set_pipe
414
+   7.3. rl.get_pipes
415
+   7.4. rl.set_queue
416
+   7.5. rl.get_queues
417
+   7.6. rl.set_pid
418
+   7.7. rl.get_pid
419
+   7.8. rl.push_load
420
+   7.9. rl.set_dbg
421
+
422
+7.1.  rl.stats
423
+
424
+   Lists the parameters and variables in the ratelimit module.
425
+
426
+   Name: rl.stats
427
+
428
+   Parameters: none
429
+
430
+   RPC Command Format:
431
+                kamcmd rl.stats
432
+
433
+7.2.  rl.set_pipe
434
+
435
+   Sets the pipe parameters for the given pipe id.
436
+
437
+   Name: rl.set_pipe
438
+
439
+   Parameters:
440
+     * pipe_id - pipe id.
441
+     * pipe_algorithm - the algorithm assigned to the given pipe id.
442
+     * pipe_limit - the limit assigned to the given pipe id.
443
+
444
+   RPC Command Format:
445
+                kamcmd rl.set_pipe 2 RED 10
446
+
447
+7.3.  rl.get_pipes
448
+
449
+   Gets the list of in use pipes.
450
+
451
+   Name: rl.get_pipes
452
+
453
+   Parameters:none
454
+
455
+   RPC Command Format:
456
+                kamcmd rl.get_pipes
457
+
458
+7.4.  rl.set_queue
459
+
460
+   Sets the queue parameters for the given queue id.
461
+
462
+   Name: rl.set_queue
463
+
464
+   Parameters:
465
+     * queue_id - queue id.
466
+     * queue_method - the method assigned to the given queue id.
467
+     * pipe_id - the pipe id assigned to the given queue id.
468
+
469
+   RPC Command Format:
470
+                kamcmd rl.set_queue 3 INVITE 2
471
+
472
+7.5.  rl.get_queues
473
+
474
+   Gets the list of in use queues.
475
+
476
+   Name: rl.get_queues
477
+
478
+   Parameters: none
479
+
480
+   RPC Command Format:
481
+                kamcmd rl.get_queues
482
+
483
+7.6.  rl.set_pid
484
+
485
+   Sets the PID Controller parameters for the Feedback Algorithm.
486
+
487
+   Name: rl.set_pid
488
+
489
+   Parameters:
490
+     * ki - the integral parameter.
491
+     * kp - the proportional parameter.
492
+     * kd - the derivative parameter.
493
+
494
+   RPC Command Format:
495
+                kamcmd rl.set_pid 0.5 0.5 0.5
496
+
497
+7.7.  rl.get_pid
498
+
499
+   Gets the list of in use PID Controller parameters.
500
+
501
+   Name: rl.get_pid
502
+
503
+   Parameters: none
504
+
505
+   RPC Command Format:
506
+                kamcmd rl.get_pid
507
+
508
+7.8.  rl.push_load
509
+
510
+   Force the value of the load parameter. This method is useful for
511
+   testing the Feedback algorithm.
512
+
513
+   Name: rl.push_load
514
+
515
+   Parameters:
516
+     * load - the forced value of load (it must be greater then 0.0 and
517
+       smaller then 1.0).
518
+
519
+   RPC Command Format:
520
+                kamcmd rl.push_load 0.85
521
+
522
+7.9.  rl.set_dbg
523
+
524
+   This function will enable/disable a WARNING debug log exposing the
525
+   internal counters for each pipe (useful in monitoring the ratelimit
526
+   internals).
527
+
528
+   Name: rl.set_dbg
529
+
530
+   Parameters:
531
+     * dbg - the debug value (0 means disable and 1 means enable).
532
+
533
+   RPC Command Format:
534
+                kamcmd rl.set_dbg 1
535
+
536
+8. Known limitations
537
+
538
+   The pipes and queues are stored as static vectors, so no more than
539
+   MAX_PIPES/MAX_QUEUES can be added without recompilation.
540
+     * MAX_PIPES - 16
541
+     * MAX_QUEUES - 10