Team indes

Members
Overall Objectives
Scientific Foundations
Application Domains
Software
New Results
Contracts and Grants with Industry
Other Grants and Activities
Dissemination
Bibliography

Section: New Results

Web programming

Participants : Marcos Dione, Florian Loitsch, Zhengqin Luo, Cyprien Nicolas, Tamara Rezk, Bernard Serpette, Manuel Serrano.

Hop

Software distribution: Two new major branches have been released this year: Hop 1.10.x and 1.11.x. Branch 1.10.x has carried new APIs and new features. Hop 1.11.x has focused on the implementation. In particular it has deployed a new version of the client-side compiler.

Multimedia Applications: We have completed HopAudio, the ubiquitous home media center started in 2008 and presented at the conference MMCN'09 [14] . Taking advantage of the ubiquity of the Web, this application implements features that other programs used for playing music rarely propose. HopAudio can use many sources of music and radios and it can control several output speakers. All the electronic devices that can run a Hop broker (i.e., a dedicated Web server) can be used to serve musical content. All the devices that can run a stock web browser can be used to control the music being played back. HopAudio can be considered as a realistic prototype . It is operational and used on a daily basis although some implementation details must still be polished and some minor features must still be added.

Fast server events:server events , or server push is a central element of reactive Web applications. They enable servers to notify clients when some informations need to be updated. Server events simplify the programming of applications and they avoid inefficient client pulls that clutter network traffic. Unfortunately, HTTP is not well suited for server events. According to HTTP, only clients may initiate communications and the protocol is stateless. As a consequence, it is difficult to implement server push efficiently. Hop now contains three different implementations that are chosen dynamically according to the characteristics of the client the program executes on.

Hop, a Fast Server for the Diffuse Web: Diffuse Web applications have similarities with Web 2.0 applications: first, they rely on fast bi-directional interactions between servers and clients, and second, they make extensive use of non-cachable dynamic contents. On the other hand, diffuse applications have also an important difference with respect to traditional Web applications: they generally do not need to deal with a huge number of simultaneous users. That is, diffuse Web applications are built on top of standard technologies but they use them differently. Therefore they demand different optimizations and tunings.

The Hop software development kit contains two compilers, one interpreter, and a bootstrapped Web server. That is, the Hop Web server is implemented in Hop . We have implemented a new strategy that allows Hop to dramatically outperform the popular mainstream Web servers for delivering dynamic contents. Contrary to most servers, Hop delivers static and dynamic contents at a comparable pace. This has been described in an invited paper presented at the COORDINATION'09 conference [9]

HSS css compiler: HSS is a compiler for CSS. It can be either used as a stand-alone HSS-to-CSS compiler in the goal of enriching CSS with user defined variables, functions, and element types. It can also be used with the Hop web development kit in which case, working hand in hand with the Hop programming language, it can be used to implement skinning or theming of web applications. HSS has been described in a paper currently submitted [22] .

Scm2Js

We have continued the development of Scm2JS , our Scheme to JavaScript compiler. In particular we improved the code generation. A pretty-printing pass produces clean code, or, alternatively, obfuscated short code. We furthermore worked on error handling. Compared to previous versions, error messages contain much more useful information that helps developers debug their program. In a similar vein we have introduced runtime-checks (activated by the -g flag).

Ordered networks

A network is a graph of nodes where edges represent physical or logical connections. The main role of the network is to dispatch messages between nodes, a mechanism known as the routing process. To locate the destination of a message, each node has its own identifiers , e.g. IP addresses are the identifiers for the Internet. In logical networks, nodes also manage a set of identifiers. Thus, such a network does not resolve only queries like send a message to the node whose identifier is id , but also more general queries like send a message to the node who manages the identifier (or key) id . In the networks we have studied, we force, by construction, the uniqueness of identifiers: an identifier is managed by one and only one node. Moreover, we want to guarantee that messages reach their destinations, that is, that the network does not lose messages during the routing process. The approach we have followed is to consider a hamiltonian cycle over the network: a cycle which traverses all nodes of the graph once and only once.

Hamiltonian cycles are generally extracted from an existing graph, which is known to be an NP-complete problem. In our case, the cycle is established at the beginning, when the network is initiated with a first node, and preserved during insertion and deletion of nodes. As we consider oriented graphs, each node is only required to maintain its successor in the cycle. It is particularly convenient to consider a strict order < over nodes. Given this order, a finite set of nodes can be sorted, thus giving an Hamiltonian path. The cycle is then achieved by artificially connecting the two bounds of the path.

We have experimented several orders,

  1. natural: the basic order on natural numbers,

  2. gray code: also based on natural numbers, it forms a Hamiltonian cycle on a hypercube, where each bit is seen as one dimension,

  3. space-filling curve: based on 2D points with the Hilbert curve,

  4. alphabetic: the basic order on strings.

To avoid a routing proportional to the number of nodes, each node has a set of perfect identifiers used to build shortcuts over the hamiltonian cycle. The general aim is, having a logarithmic number of perfect identifiers per node, to insure a logarithmic routing. We have experimented several functions computing the perfect identifiers,

  1. exponential: associated to the natural order, it gives the well established Chord network.

  2. symmetrical: with 2D points, perfects are chosen in symmetric sub-squares.

  3. hypercube: all identifiers differ by only one bit.

Figure 1. Performance of some ordered networks
IMG/perf

The figureĀ 1 shows the general performance of some ordered networks. All have the desired logarithmic behavior. Pictures on the right are snapshots of networks in stable state. The pixel at position i,j represents the number of nodes a message has to go through during the routing process (i.e. the number of hops), when this message starts from the ith node and wants to reach the jth successors of this node. Blue pixels represent a low number of hops, while green ones are used for a high number of hops. Thus the first column is in dark blue since a direct successor is always at one hop.

The attribution of a node for a perfect identifier, i.e. a shortcut, is done during the routing process. Some extra informations are added during message exchanges in order to share informations between neighbors in the networks. Th experiences we have made show that this strategy is relevant even in the case of a large amount of insertions and deletions of nodes.

Independently of the order and of the perfect identifier calculation, we have formalized the protocols for routing processes and for insertion and deletion of nodes. We have partially proven that messages reach their destination, as well as the absence of dead-locks and live-locks.


previous
next

Logo Inria