Chapter 4 – Design and Implementation of A Middleware Application
4.3 Middleware Application Design
4.3.3 Event Handling to Switch IP Protocol
The previous two sections provided brief descriptions of the middleware application functions and their capability to switch between the IP protocols on the fly when a request is received. But the question is how to notify an application
to switch the IP protocol during its execution? This is achieved through the use of signals and a corresponding signal handler. The middleware application function fn_socket() creates a detached thread called event handler thread as shown in Figure 4.2. The event handler thread is a simple signal handler that checks on incoming requests in form of signals to set flags. These flags are set to indicate to switch the IP protocol and also to specify which IP protocol is desired based on the signal received. These flags are then used by the control thread and middleware application functions fn_send()/fn_write() and fn_recv()/fn_read() to switch to the socket descriptor of the desired IP protocol as described earlier.
LINUX supports a wide range of POSIX and non-POSIX signals. Each signal has a default action that determines how a process behaves when that signal is delivered. The signal handlers are set to identify and handle received signals. In this application, the signal handlers are set in the event handing thread to identify two kinds of signals namely SIGUSR1 and SIGUSR2. Apart from signal handlers set in the event handling thread, the middleware application also has a few other signal handlers to perform the tasks of cleaning up threads and resources when those signals are delivered. Table 4.3 below shows the signal numbers, default action and corresponding IP protocol to switch to when these signals are delivered. These signal values are obtained from the host web.rnet.missouri.edu and can change from OS to OS.
Signal Value Action Comment IP Protocol to switch to
SIGUSR1 10 Term User-defined signal 1 IPv4
SIGUSR2 12 Term User-defined signal 2 IPv6
Table 4.3: Signal Values and Action
SIGUSR1 and SIGUSR2 are user-defined signals and are not triggered from within the OS kernel. These are left for the developers to use programmatically as needed. The action value term in Table 4.3 means the default action is to terminate the process it is delivered to, unless it is caught and handled by a signal handler. When SIGUSR1 is received, the signal handlers set the flags to indicate to switch to IPv4 protocol while for SIGUSR2 it is set to use IPv6 protocol. These signals can be sent to an application while in execution by simply using command line utility kill as shown below. SIGUSR1 is the name of signal to be sent while pid is process id of the executing application. Instead of using SIGUSR1, its corresponding number can also be used. For example on web.rnet.missouri.edu, the number 10 can be used instead of SIGUSR1.
kill -SIGUSR1 pid
Another way of sending signals is through the use of the system call named kill() from within the same or another application. An example below shows on how to use this option.
vlError = kill(pid, SIGUSR1);
pid is again the process id of the application the signal is to be sent to and SIGUSR1 is signal name itself. This option is useful in the case where the IP protocol of an application like a file transfer application that transfers very large files across the network needs to be changed on the fly to enhance the transfer performance. A measurement tool running in parallel can measure the performance of the network path between the same hosts as that of the file transfer application. The measurement tool can send either SIGUSR1 or SIGUSR2 signals to the file transfer application based on measured performance, to switch to the desired IP protocol. A sample prototype is built to test the middleware application switching capability on receiving SIGUSR1 or SIGUSR2 from either a user through a command line terminal or from another program running on the same machine as that of the file transfer application. Thus with the combined use of the event handler thread, the control thread and the protocol followed by the middleware application functions while switching the IP protocol, an application using the middleware application can switch between IP protocols on the fly.
With the middleware application built as part of this thesis, the overall aim is to help applications leverage the existence of both IP protocols and gain performance by using an IP protocol offering better performance. The switching capability built as part of the middleware helps an application to gain this performance benefit by switching between the IP protocols on the fly, without impacting the application’s functionality. Additionally, the use of middleware
application also helps an application deal with minimum code for interprocess communication across network using sockets. The application just needs to initialize few variables and pass it to middleware application functions. The middleware application then takes care of creating and using socket connections to use the preferred IP protocol. The measurement tool built helps to measure performance for both IP protocols as part of single tool. Based on measured performance, the application using the middleware application can be requested to switch the IP protocol if desired. The next chapter provides details on the design and implementation of this measurement tool, the algorithm used to measure each performance parameters and the corresponding client server communication involved. The tool uses the middleware application functions and constants whereever sockets are involved to transfer the data over both IP protocols as a proof of concept of the middleware application built.