# A Multilayer Data Processing and Aggregating Fog-Based Framework for Latency-Sensitive IoT Services
## 3 Design and Implementation
### System Implementation
#### 3.2.2 Fog Server  
Node.js is used to implement the accessing module in the proposed prototype. Because of the characteristic of event-driven and non-blocking Input/Output (I/O) model, node.js is considered as an effective way to handle the network connections. Four main sub-modules are included in the accessing module. * Network Request Handler  
It handles the network connections by receiving the requests and delivering them to the corresponding backend module according to the type of the received request. After processing data via the backend modules, the network request handler sends the response back to the clients. Figure 4: Detailed architecture of the fog server. * AuthTracker  
Authentication is one of the main functions that is applied by the device module in the fog server. Authentication of the device module is considered as a strong authentication since the device module employs the complete authentication to generate a ticket that will be stored in the AuthTracker upon finishing the complete flow. To reduce the response time, there is no need for strong authentication whenever an authenticated device would like to connect to the fog server, instead the ticket stored in the AuthTracker can perform quick authentication. Data processing by the fog server will be performed after passing the authentication process. Note that a ticket will be invalid when there is no connection between the device and the fog server for a defined period of time. * Data Sync Handler  
It periodically synchronizes data. The synchronization time period is a user-defined parameter (i.e., default is 5 min). * Query Tracker  
It caches the newest data by sending requests to the database to retrieve all the newest data every second. The query tracker plays a key role in achieving a promising response time. Retrieved data will be maintained in the accessing module. Consequently, when the accessing module receives queries from clients, it can return the response immediately without passing the request to the database through the message broker. Therefore, the overhead will be reduced and the response time will be more stable. Assume that there are 1000 clients who send queries simultaneously for every second. In that case, without the query tracker, the fog server has to send 1000 requests to the database which in turn has to retrieve each response individually. On the other hand, by implementing the fog server with the query tracker, the fog server only sends a request to the database that in turn retrieves 1000 data collectively. 2. Device Module  
This module is responsible for authentication and registration. The challenge-response protocol is applied for authentication. Clients generate a challenge that will be uploaded to the device module which in turn calculates the response accordingly with the help of the security module. This module includes two sub-modules as detailed in the following points. * Device Handler  
It handles incoming requests. It communicates with the storage module for registration requests to verify whether the database stores the registration information of that device. For authentication requests, the device handler, first, checks the registration information of the device and then communicates with the security module in order to calculate the corresponding response. * Device Tracker  
It caches the device information after registration in order to minimize the authentication overhead by reducing the database operations. 3. Processing Module  
It performs data processing and filtering before relaying data to the storage module. The processing module consists of:  
* Processing Handler: It receives the transferred data from the accessing module. * Processing Unit: It processes data and returns response when needed. It handles the database operations. Database manipulation can be performed only by the storage module. This module consists of:  
* DBHandler: It receives requests from the other modules and performs the corresponding operation according to the request types.