| 287 | | |
| | 287 | |
| | 288 | ==== (11/2) ==== #w8 |
| | 289 | Concept work for the module front end to remote connections: [[BR]] |
| | 290 | 1.3 types of message processing chain behaviors, according to application type at remote end. |
| | 291 | |
| | 292 | 1. Proxy : messages cannot be passed down chain until the remote module has processed things, and returned a decision. This includes firewalls and authentication. |
| | 293 | 1. Concurrent : messages being processed by the remote module can also be processed by the others down the chain even while it is being remotely processed. |
| | 294 | 1. Both : some modules may be required to wait for the results of the remote module, while others may work concurrently. |
| | 295 | |
| | 296 | In terms of communicating the specific type, there can be a field that specifies preferred processing options in the !ExportsReply messages. |
| | 297 | |
| | 298 | 2.Implementation wise, static modules makes dynamic connection additions difficult. In dynamic controllers, a module-per-connection may be added as connections are introduced, so tacking this problem is not considered to be a topic of interest. (However, it has to be done) |
| | 299 | |
| | 300 | 3.Flow entry merging is a nontrivial topic that is not covered due to its extensiveness. Once a flow entry is added, it is assumed to: |
| | 301 | |
| | 302 | 1. aside from removal, never be modified |
| | 303 | 2. not conflict with any others. |