# An Enhanced Message Distribution Mechanism for
## 4 Message Distribution Mechanism
### Message Queue Model  
We notice that the cause of the problem that is described in Section 3.2 is that the NBI ignores the apps' demand for messages. Taking the controller that supports OpenFlow as  
Figure 2: Latency Test under Various App Combinations And Switch Numbers. an example, most of the controllers can distribute events according to OpenFlow message types, so each app can register a handler to receive the corresponding event when the app is implemented. We integrate the message queue into the NBI of the controller to further divide the types of messages. The app subscribes to topics of interest by the message queue, then, in addition to general messages, the controller will only send messages under this topic to the app. EMD runs in parallel with the core module of the controller in the controller program, as shown in Figure 3. We do not make too many changes to the core module of the conventional controller, but just take over the delivery mode of data messages, which is the most in the NBI through the message queue. The details will be further introduced in the form of pseudo-code in the follow-up. Taking the most important asynchronous message packet-in in OpenFlow as an example, Algorithm 1 shows the improved northbound message distribution mechanism. And Table 1 is an explanation of some symbols and nouns in Algorithm 1  
The main idea of Algorithm 1 is to use the publish-subscribe model of the message queue to subdivide the message distribution, which is more like a pre-classifier for the NBI. The first part (which is from Line 6 to Line 11) is mainly for the processing of general messages, which is the same as the usual controller; the second part (which is from Line 13 to Line 28) uses the match field, part of the message in OpenFlow protocol, to define the topic of the message queue. When the Apps are installed and the subscription action is then completed, the controller is responsible for parsing the message's match field, and the message queue is responsible for completing the task of distribution by category (using match field). \begin{table}
\begin{tabular}{c l} \hline \hline
**Symbol** & **Description** \\ \hline _msg_ & The structure of south-north control message \\ _match_ & The match field of OpenFlow protocol \\ \(\{\)_vid_ : _mmit\_app_\(\}\) & A dictionary that the key is _msg\(\_\)_vid_ and the value is a book value indicating whether to send to multiple apps \\ _FOR\(\_\)ALL_ & A match collection of messages that need to send to all apps \\ _REPU_ & A match collection of simple messages that can be directly responded to \\ _send\(\_\)msg\(\_\)all_ & Function that sends messages to all apps \\ _send\(\_\)msg\(\_\)\(\_\)\(\_\)\(\_\)\(\_\) & Function that sends prefix topic message \\ \hline \hline \end{tabular}
\end{table} 
Table 1: The symbols of Algorithm 1. Figure 3: The Overall Structure of SDN with EMD Module. ```
1:\(msg\)
2:\(\{xid:\ multi\_app\}\)
3:initialization:
4: apps register and add the topics to the list TOPIC. 5:endif initialization
6:for each msg in southbound interface do
7: parsing the msg in core module and set the match filed
8:if msg is in [Handshake, Config, Status, or other specific type] then
9: call for correspond event handler
10: continue
11:else if msg is FORALL then
12: send_msg_all(msg)
13: continue
14:else
15:for each match in msg do
16:if match is in REPLY then
17: generate the reply msg named resp_msg
18: packet_out(resp_msg)
19: notify_core_module(\(\mathit{dpid},\mathit{match},\mathit{msg}.\mathit{xid}\))
20: msg_topic = NULL
21: break
22:else if match is in TOPIC then
23: msg_topic \(|\) = match
24:endif
25:endfor
26:if msg_topic \(\
eq\) NULL then
27: send_msg_topic(msg_topic)
28: send_msg(msg)
29:endif
30: add (msg_xid, 1 if msg_topic \(\geq\) 2 \(\mathit{else}\) 0) to \(\{xid:\ multi\_app\}\)
31:endif
32: update the data plane's topology
33:endfor
34:return\(\{xid:\ multi\_app\}\)
```  
**Algorithm 1** Enhanced Message Distribution Mechanism.