# Fog-Based CDN Framework for Minimizing Latency of Web Services Using Fog-Based HTTP Browser
## 3 Proposed Fog-Based CDN Framework
### Fog-Based CDN Framework Workflow
#### 3.2.1 Offloading and Serving as a CDN Node Using Fog Worker (FW)  
We present the proposed framework workflow with the Fog Worker (_FW_) as the first component. The _FW_ has four main functions: self-registration to the _FR_, joining the local network nodes, pulling the resources, and serving the offloaded resources. The _FW_ is software installed on fog nodes. Here, fog nodes are referred to as hosts. Once the _FW_ is turned on, it sends a registration request to the _FR_. The registration request contains the following data about the fog node: node key, memory size, host operating system, longitude, and latitude. The self-registration function starts with a registration request sent by a post request following the Restful API standards made available by the _FR_. The _FR_ then responds back with the registration details and with a universal unique identifier (UUID). The UUID can then be used by the _FW_ to update any host information afterwards. If the FN is already registered, the _FR_ will detect this via the node key and return the previously registered information. After a successful registration, the FN announces its availability in the network for other nodes and edge devices. This is done by a broadcast message in the same local network. After this step, edge devices, more specifically the Fog Browser, know that there is a fog node available in the same network. The _FW_ then subscribes to the event channels. When any new web service is deployed in the cloud servers with fog-CDN enabled, it is published in the event channels and the _FW_ starts pulling all the resources in parallel. If the _FW_ successfully pulls all the available resources, it stores them locally and makes them accessible to the local network via the same cloud URL prefixed with the fog node host IP. For example, if a resource URL such as [[https://example-service.com/images/fog.png](https://example-service.com/images/fog.png)]([https://example-service.com/images/fog.png](https://example-service.com/images/fog.png)) (14 December 2021) is used, it will be made accessible in the local network via [[http://192.168.1.6/example-service.com/images/fog.png](http://192.168.1.6/example-service.com/images/fog.png)]([http://192.168.1.6/example-service.com/images/fog.png](http://192.168.1.6/example-service.com/images/fog.png)) (14 December 2021). Furthermore, the _FW_ reports to the _FR_ that it can serve these resources. Accessing the resources from a local network in this manner provides direct quick access to the resource for all the other devices in the same network. The _FW_ has a microservice running in the background to provide these resources in HTTP. Providing the resources via HTTP, the same protocol they get requested from the cloud, makes the Fog Browser implementation much simpler, as it would only prefix the requested resource with the FN IP. Figure 5 explains all the _FW_ functions in a sequence diagram and the communications with other framework components. The _FW_ and the Fog Browser are both software installed on the fog nodes and edge devices, respectively. This why the host device is outlined by a blue rectangle. Figure 4: High-level architecture of the fog-based CDN. 3.2.2. The Fog Registry (_FR_) Workflow  
As shown in the abstract architecture of the proposed framework in Figure 4, the _FR_ is the knowledge base of the proposed framework. The _FR_ stores the fog nodes connected to the cloud providers and the services deployed in the cloud provider's servers. Each fog node in the outer layer of the network spectrum registers itself to the _FR_ by the _FW_ operating on them. Web service engineers who want to utilize the fog architecture to provide better resource availability need to register their service in the _FR_ with each service deployment. This can easily be part of the web service Continuous Delivery (CI/CD) pipelines. During the deployment stage, the web service (WS) registers itself to the _FR_. The WS registration requires the following data: service name, resources endpoint, HTTP method, and response schema.