| | 304 | |
| | 305 | ==== (11/3) ==== |
| | 306 | Process chain alterations based on request should be done at a per-event-category basis. The rationale comes from a few points, such as the how Floodlight processes events categorically, in separate modules, and not every event that may be subscribed to by one controller necessarily should be treated in the same manner. An example of this is for the authenticator, which subscribes to packet_Ins and new_device events; while packet_ins from a blacklisted host must not be processed by any other module capable of causing denied host traffic to be forwarded, new_device messages can be passed to other modules with little risk. |
| | 307 | |
| | 308 | Several concerns are still up in the air, some of which may alter how sensible the above statement is: |
| | 309 | * stub module(s) - one for each event category versus one for all categories. Former makes each simpler, but probably requires more context passing, while the latter makes shared data easier to manage but the module itself more complicated e.g. makes a second level scheduler necessary. |
| | 310 | * multiple remote controllers with conflicting requests - For the same event. Strongly implies diversion should /not/ drop a event after it passes through one. |
| | 311 | |
| | 312 | For starters, the most basic structure would be a diverting module(work on one at a time, the default dispatcher behavior) |
