Middleware Application Functions

The socket API provides various system calls for inter-host, client-server communication across a network. The important and frequently used ones are listed in Table 4.1. Table 4.2 provides a list of middleware application functions, their purpose, input parameters and corresponding return types. Based on the parameters passed to a middleware application function, the middleware application function then internally make use of the corresponding socket API system call to operate on either IPv4 or IPv6 socket ids. For example, the middleware application function fn_send() internally calls the socket API system call send() to achieve the same functionality of sending data over sockets but with added logic that determines which IP protocol (IPv4 or IPv6) is to be used based on its input parameter values. Similarly, the middleware application function fn_recv() makes use of the system call recv() to receive data over either an IPv4 or IPv6 socket id. The middleware application is currently built to work with both TCP and UDP. A detailed description of each of the middleware application functions can be found in Appendix B.

Functions Purpose Input Parameters Return type

fn_write() Writes data to a connection

fn_sendto() Sends data (UDP:

connectionless)

fn_read() Reads data from a

fn_recv() Receives data (TCP:

connection based)

fn_recvfrom() Receives data (UDP:

connectionless)

int IP version, int opt level, int opt name

The structure named st_mySocket is the most important structure used by all middleware application functions used to build applications with the developed middleware application services. This structure is required as an input parameter for all middleware application functions. It is a structure that holds the socket descriptors, socket type, IP version, port numbers, host addresses and other information for both IP protocols. This structure can be used for creating socket connections for either TCP or UDP. It encapsulates the connection properties of both IPv4 and IPv6 connections and can be treated as a socket object for both of the IP protocols. The application using the middleware

application has to initialize a few of the structure members once and then use it wherever the middleware application functions are called in an application. The structure members that need to be initialized with values are the members holding the port numbers, host name, the preferred IP protocol to be used and a member variable that indicates whether an application is a client or a server. A set of constants having meaningful names are included as part of the middleware application to ease the socket structure initialization and also for the internal use of the middleware application. A complete list of middleware application constants can be found in Appendix B. Initializing the socket structure with appropriate values and using it across all the middleware application functions helps an application to deal with minimal code while using sockets.Creating and using socket connections requires an application to use socket API calls with specific parameters for each IP protocol. If the application desires to use both IP protocols, it would need to have separate socket API system calls within its code with individual parameters for both IP protocols. The middleware application provided here helps ease the use of sockets by initializing socket structure once and using it across all the middleware application functions. Based on the values assigned to the socket structure, the middleware application internally takes care of creating and using socket connections for the IPv4 or IPv6 protocol. This allows developers to focus on the core functionality of an application. For example, the application just needs to call the middleware application functions fn_read()/fn_write() with the socket structure as one of the input parameters to read and write data respectively using either IP protocol. This would otherwise

require two separate system calls read() and write() for IPv4 and IPv6 respectively. The same applies through the use of the other middleware application functions listed in Table 4.2. Apart from the member variables that need to be initialized by an application, the structure also holds other member variables used for the internal working of the middleware application. The middleware application takes care of assigning and changing the values of these remaining structure members once the socket structure is passed to it. The socket structure st_mySocket and all its members are outlined in Appendix B.

The starting point of using the middleware application is the middleware application function fn_socket(). As with any network application that calls the socket API function socket() as the first function call, fn_socket() also needs to be the first middleware application function to be called to use the middleware application version of the API. This applies to an application running as either a server or a client. This middleware application function is responsible for internally assigning values to the remaining members of the socket structure st_mySocket passed to it. Based on the parameters passed to this function, it creates a socket connection for either IPv4 or IPv6 or both IP protocols. Once the socket connection(s) is/are created by fn_socket(), the socket properties like the socket ids, and remote host addresses are stored in the socket structure st_mySocket. Once the call to fn_socket() is successful and the socket connections are created, the socket structure can then be used by other middleware application functions to operate using either IP protocol. In order to use the middleware application capability to switch between the IP protocols, the

function fn_socket() needs to create socket connections over both IP protocols.

This occurs by initializing socket structures with appropriate values before calling fn_socket(). These values then mark the socket object, to be available for switching the IP protocol. The application can choose to either use or not to use the middleware application switching capability by controlling the values assigned to socket structure members. By default, the middleware application starts by using the IPv4 protocol until the middleware application is told to switch to the IPv6 protocol. The application developer also has an option to specify the preferred IP protocol to be used. The middleware application internally keeps track of which protocol is to be used. Both IPv4 and IPv6 socket connections are maintained throughout the application, as making and breaking of connections causes extra overhead while switching IP protocols. Moreover the application can also specify to strictly create and use either an IPv4 or an IPv6 network connection. In case fn_socket() is not able to create a socket connection for the specified protocol, it returns an appropriate error message. Figure 4.2 provides a high level flow diagram of the internal working of fn_socket(). The middleware application function fn_socket() further helps an application to have minimum code by internally calling the middleware application functions fn_bind(), fn_listen() and fn_connect() for TCP. For a server application, the functions fn_bind() and fn_listen() are called to bind a socket descriptor to an address:port pair and listens for incoming connection calls respectively. For client applications, the function fn_connect() is called internally to connect the client socket to the one on the server. Appendix B provides a detailed example on

how to initialize the socket structure and use of middleware application functions to use the desired IP protocol. It also provides more details on the use and significance of each of the socket structure member variables.

The middleware application provides code modularity in two ways. The middleware application functions have the function name, input parameters and the return type similar to that of the base socket API system calls. This is to make it easy to integrate the middleware application in existing applications or while building a new application. The second way code modularity is achieved is through the use of a shared library. In case the internal working of any of the middleware application functions is changed, the application using the middleware application does not need to be changed or recompiled. The shared library just needs to be recompiled to be available for use. The next section explains the client server communication involved to switch between the IP protocols for TCP connection in the main application thread.

Call fn_bind() to bind the socket to the host address:port Fill in socket structure

members for addrinfo with TCP, IPv4 and IPv6 protocol

details

to be used for IPv6 protocol Fill in socket structure member for addrinfo

Call the middleware function fn_socket() with input parameters -socket structure, -socket type (TCP or UDP) and IP version

Initialize socket structure st_mySocket members

Assign input parameters values to the socket structure members for further reference

Main thread

YES NO

YES NO

YES

Figure 4.2: fn_socket() Flow Diagram