iExec network virtualization

Oleg Lodygensky
iExec
Published in
3 min readMar 13, 2017

To continue our series of articles to introduce the technology behind the iEx.ec Blockchain-based Distributed Cloud, this article presents the iExec network virtualization.

Introduction

As described in a previous article, iExec belongs to the well known paradigm of global computing platforms that implement a three tier architecture, where a set of centralized services are instantiated and reachable through an Internet connection by decentralized services: the “client” and the “worker”.

The client, on the one hand, offers the needed interface that permits users to interact with the platform; using the client, one can easily register applications as shown in the next sections. The worker, on another hand, aggregates volunteer IT resources to run applications that process end user data.

Architecture

The architecture shown in previous articles has not been fully introduced yet to facilitate the understanding of the general idea. The next figure digs more deeply into detail by introducing virtualization networking services and protocols. One can certainly retrieve what has already be introduced in previous articles where XWHEP services were shown: the scheduler, data repository, client and worker.

The next figure specifically introduces the Ibis Smartsocket services and protocols that permit interconnection between decentralized services in all possible directions: client can connect to workers, workers can connect to each other etc. Without SmartSockets, there is no chance to connect to distributed resources since they are protected by firewall, not mentioning they certainly don’t have public IP address, but local one only with the NAT protocol.

Use case

In this article, we propose a very simple client-server use case instead of describing the internal technology, for which one can refer to the documentation. The use case necessitates deploying a data server and clients that will connect retrieve data from this deployed server. In the next figure, the server is depicted by the “Apache” icon and the client by the the “Firefox” icon. To deploy such an infrastructure, the user must:

  1. submit the server
  2. the server is deployed over a worker
  3. the server automatically obtains a socket to listen to. The server itself is not aware that this socket is a virtual socket from Ibis SmartSocket Hub. This is automatically translated by iEx.ec middleware.
  4. retrieve the server virtual SmartSocket address
  5. launch a client providing the server virtual SmartSocket address
  6. the client is deployed over a worker
  7. the client can connect as usual (e.g http://whatever:80). The client itself is not aware about virtual SmartSocket. iEx.ec middleware automatically translates the client request to a virtual SmartSocket

Conclusion

This article introduced the iEx.ec application deployment. We will introduce data management in the next article.

Media

You are kindly invited to:

Resources

--

--