| 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. |