<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE raweb PUBLIC "-//INRIA//DTD " "raweb2.dtd">
<raweb xml:lang="en" year="2009">
  <identification id="lognet" isproject="false">
    <shortname>LogNet</shortname>
    <projectName>Logical Networks: Self-organizing Overlay Networks and Generic Overlay Computing Systems</projectName>
    <domaine-de-recherche>Networks, Systems and Services, Distributed Computing</domaine-de-recherche>
    <theme-de-recherche>Distributed Systems and Services</theme-de-recherche>
    <UR name="Sophia"/>
    <moreinfo>
      <p>LogNet is an INRIA team.</p>
    </moreinfo>
  </identification>
  <team id="uid1">
    <person key="mascotte-2006-idm166461066608">
      <firstname>Luigi</firstname>
      <lastname>Liquori</lastname>
      <affiliation>INRIA</affiliation>
      <categoryPro>Chercheur</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>Team Leader, Research associate, CR INRIA</moreinfo>
      <hdr>oui</hdr>
    </person>
    <person key="mascotte-2007-idm304854251264">
      <firstname>Claudio</firstname>
      <lastname>Casetti</lastname>
      <affiliation>UnivEtrangere</affiliation>
      <categoryPro>CollaborateurExterieur</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>Assistant professor, Politecnico di Torino, Italy</moreinfo>
    </person>
    <person key="lognet-2009-idm468886189392">
      <firstname>Carla-Fabiana</firstname>
      <lastname>Chiasserini</lastname>
      <affiliation>UnivEtrangere</affiliation>
      <categoryPro>CollaborateurExterieur</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>Associate professor, Politecnico di Torino, Italy</moreinfo>
    </person>
    <person key="mascotte-2006-idm166461072400">
      <firstname>Michel</firstname>
      <lastname>Cosnard</lastname>
      <affiliation>INRIA</affiliation>
      <categoryPro>CollaborateurExterieur</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>CEO INRIA</moreinfo>
      <hdr>oui</hdr>
    </person>
    <person key="graal-2006-idm329937212304">
      <firstname>Cédric</firstname>
      <lastname>Tedeschi</lastname>
      <affiliation>INRIA</affiliation>
      <categoryPro>PostDoc</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>INRIA grant, from October 1st 2008 to September 1st 2009</moreinfo>
    </person>
    <person key="lognet-2008-idm279446248480">
      <firstname>Francesco</firstname>
      <lastname>Bongiovanni</lastname>
      <affiliation>INRIA</affiliation>
      <categoryPro>PhD</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>INRIA-PACA grant, from October 1st 2008 to October 1st 2009</moreinfo>
    </person>
    <person key="lognet-2009-idm468886176688">
      <firstname>Vincenzo</firstname>
      <lastname>Ciancaglini</lastname>
      <affiliation>INRIA</affiliation>
      <categoryPro>PhD</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>MENRT grant, since October 1st 2009, defense planned in 2012</moreinfo>
    </person>
    <person key="lognet-2008-idm279446242320">
      <firstname>Petar</firstname>
      <lastname>Maksimovic</lastname>
      <affiliation>UnivEtrangere</affiliation>
      <categoryPro>PhD</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>TEMPUS-BASILEUS grant, since December 1st 2008, defense planned in 2011</moreinfo>
    </person>
    <person key="lognet-2009-idm468886170528">
      <firstname>Bojan</firstname>
      <lastname>Marinkovic</lastname>
      <affiliation>UnivEtrangere</affiliation>
      <categoryPro>PhD</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>INRIA-TEMPUS grant, MISANU, Serbia, from February 2009 to May 2009</moreinfo>
    </person>
    <person key="oasis-2008-idm355833861312">
      <firstname>Laurent</firstname>
      <lastname>Vanni</lastname>
      <affiliation>CNRS</affiliation>
      <categoryPro>Technique</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>from September 1st 2009 to December 31th 2009</moreinfo>
    </person>
    <person key="lognet-2009-idm468886164368">
      <firstname>Marthe</firstname>
      <lastname>Bonamy</lastname>
      <affiliation>UnivFr</affiliation>
      <categoryPro>AutreCategorie</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>ENSL, from June 1st 2009 to July 15th 2009</moreinfo>
    </person>
    <person key="lognet-2009-idm468886161296">
      <firstname>Luc</firstname>
      <lastname>Marongiu</lastname>
      <affiliation>UnivFr</affiliation>
      <categoryPro>AutreCategorie</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>IUT, from April 10th 2009 to June 12th 2009</moreinfo>
    </person>
    <person key="lognet-2009-idm468886158208">
      <firstname>Alexis</firstname>
      <lastname>Paoleschi</lastname>
      <affiliation>UnivFr</affiliation>
      <categoryPro>AutreCategorie</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>IUT, from April 10th 2009 to June 12th 2009</moreinfo>
    </person>
    <person key="everest-2006-idm306718603216">
      <firstname>Nathalie</firstname>
      <lastname>Bellesso</lastname>
      <affiliation>INRIA</affiliation>
      <categoryPro>Assistant</categoryPro>
      <research-centre>Sophia</research-centre>
      <moreinfo>INRIA</moreinfo>
    </person>
  </team>
  <presentation id="uid2">
    <bodyTitle>Overall Objectives</bodyTitle>
    <subsection id="uid3" level="1">
      <bodyTitle>LogNet's Motto and Logo</bodyTitle>
      <p>Our Motto is 
      <i>“Computer is moving on the edge of the Network...”</i>by Jan Bosch, Nokia Labs, [LNCS 4415, 2007] and our logo is in Figure 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#uid4" location="intern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
      <object id="uid4">
        <table>
          <tr>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/LogNet-Logo3.jpg" xylemeAttach="1" xlink:href="IMG/LogNet-Logo3" type="float" width="192.1487pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
          </tr>
        </table>
        <caption>Our logo</caption>
      </object>
    </subsection>
    <subsection id="uid5" level="1">
      <bodyTitle>Overall objectives</bodyTitle>
      <p>We propose foundations for 
      <i>generic overlay networks</i>and 
      <i>overlay computing systems</i>. Such overlays are built over a large number of distributed 
      <i>computational agents</i>, virtually organized in 
      <i>colonies</i>, and ruled by a leader (
      <i>broker</i>) who is elected democratically (
      <i>vox populi, vox dei</i>) or imposed by system administrators (
      <i>primus inter pares</i>). Every agent asks the broker to log into the colony by declaring the resources that can be offered (with variable guarantees). Once logged in, an agent can ask the
      broker for other resources. Colonies can recursively be considered as 
      <i>evolved agents</i>who can log into an outermost colony governed by another super-leader. Communications and routing intra-colonies goes through a broker-2-broker 
      <i>PKI</i>-based negotiation. Every broker routes intra- and inter- 
      <i>service requests</i>by filtering its 
      <i>resource routing table</i>, and then forwarding the request firstly inside its colony, and secondly outside, via the proper super-leader (thus applying an 
      <i>endogenous-first-estrogen-last</i>strategy). Theoretically, queries are formulæ in first-order logic equipped with a small program used to 
      <i>orchestrate</i>and 
      <i>synchronize</i>atomic formulæ (atomic services). When the client agent receives notification of all of (or part of) the requested resources, then the real resource exchange is performed
      directly by the server(s) agents, without any further mediation of the broker, in a pure peer-to-peer fashion. The proposed overlay promotes an 
      <i>intermittent</i>participation in the colony, since peers can appear, disappear, and organize themselves dynamically. This implies that the routing process may lead to 
      <i>failures</i>, because some agents have quit or are temporarily unavailable, or they were logged out 
      <i>manu militari</i>by the broker due to their poor performance or greediness. We aim to design, validate through simulation, and implement these foundations in a generic overlay network
      computer system.</p>
    </subsection>
    <subsection id="uid6" level="1">
      <bodyTitle>Highlights of the year</bodyTitle>
      <object id="uid7">
        <table>
          <tr>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/one.jpg" xylemeAttach="2" xlink:href="IMG/one" type="inline" width="192.1487pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/Highlights.jpg" xylemeAttach="3" xlink:href="IMG/Highlights" type="inline" width="192.1487pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
          </tr>
        </table>
        <caption>The 
        <i>Ariwheels</i>simulator and the European Commission point of view</caption>
      </object>
      <object id="uid8">
        <table>
          <tr>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/myMed.jpg" xylemeAttach="4" xlink:href="IMG/myMed" type="float" width="341.6013pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
          </tr>
        </table>
        <caption>The myMed social network</caption>
      </object>
      <simplelist>
        <li id="uid9">
          <p noindent="true">The 
          <i>Ariwheels</i>overlay network is being proposed as a publish &amp; subscribe protocol in the vehicular platform under development in the VICSUM project (2Meur, founded by the Regione
          Piemonte) led by Politecnico di Torino and involving the Centro Ricerche Fiat (CRF) and the Centro Supercalcolo Piemonte 
          <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid0" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
          <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid1" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. The project ended successfully with a demo in front of Piemonte
          authorities and members of the press, see 
          <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.lastampa.it/_web/cmstp/tmplrubriche/tecnologia/grubrica.asp?ID_blog=30&amp;ID_articolo=6876&amp;ID_sezione=38&amp;sezione=News" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
          <allowbreak/>www.
          <allowbreak/>lastampa.
          <allowbreak/>it/
          <allowbreak/>_web/
          <allowbreak/>cmstp/
          <allowbreak/>tmplrubriche/
          <allowbreak/>tecnologia/
          <allowbreak/>grubrica.
          <allowbreak/>asp?ID_blog=30&amp;ID_articolo=6876&amp;ID_sezione=38&amp;sezione=News</ref>. The 
          <i>Arigatoni</i>and the 
          <i>Ariwheels</i>projects have been highlighted in the third year report of the IST Project AEOLUS, covering the period from 01/09/2007 to 31/08/2008</p>
        </li>
        <li id="uid10">
          <p noindent="true">Another outcome of the 
          <i>Arigatoni</i>research conducted in the team is the founding by the Interreg Alcotra office of the three-year project 
          <i>myMed : un réseau informatique transfrontalier pour léchange de contenus dans un environnement fixe et mobile</i>. LogNet will head the project; other partners are Vulog PME, GIR
          Maralpin, Politecnico di Torino, Uni. Torino, Uni. Piemonte Orientale. The total budget 1380Keur (796Keur for l'INRIA) - the external founding is 932Keur (526Keur for l'INRIA). The founders
          are UE, PACA, CG06, PREF06, and INRIA, see 
          <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/mymed" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
          <allowbreak/>www-sop.
          <allowbreak/>inria.
          <allowbreak/>fr/
          <allowbreak/>mymed</ref>.</p>
        </li>
      </simplelist>
    </subsection>
  </presentation>
  <fondements id="uid11">
    <bodyTitle>Scientific Foundations</bodyTitle>
    <subsection id="uid12" level="1">
      <bodyTitle>Lognet's general context</bodyTitle>
      <p>The explosive growth of the Internet gives rise to the possibility of designing large 
      <i>overlay networks</i>and 
      <i>virtual organizations</i>consisting of Internet-connected computers units, able to provide a rich functionality of services which make use of aggregated computational power, storage,
      information resources, etc. We would like to start our first activity report with the standard definition of a 
      <i>Computer System</i>.</p>
      <p id="uid13" id-text="1">
        <b>Definition 1 (Computer System)</b>
      </p>
      <p noindent="true">A computer system consists of computer hardware and computer software.</p>
      <simplelist>
        <li id="uid14">
          <p noindent="true">Computer Hardware is the physical part of a computer, including the digital circuitry, as distinguished from the computer software that is executed within the hardware.
          The hardware of a computer is 
          <em style="UNDERLINE">infrequently changed</em>, in comparison with software and data.</p>
        </li>
        <li id="uid15">
          <p noindent="true">Computer Software consists of three parts, namely: system software, program software, and application software.</p>
          <simplelist>
            <li id="uid16">
              <p noindent="true">System Software helps run the computer hardware and the computer system. Examples are 
              <em style="UNDERLINE">operating systems (OS)</em>, device drivers, diagnostic tools, servers, windowing systems...</p>
            </li>
            <li id="uid17">
              <p noindent="true">Program Software usually provides tools to assist the programmer in writing computer programs and software using different programming languages. Examples are text
              editors, 
              <em style="UNDERLINE">compilers</em>, 
              <em style="UNDERLINE">interpreters</em>, linkers, debuggers for 
              <em style="UNDERLINE">general purpose languages</em>...</p>
            </li>
            <li id="uid18">
              <p noindent="true">Application Software allows end-users to accomplish one or more specific (non computer-related) tasks, pertaining to fields such as industrial automation, business
              software, educational software, medical software, databases, computer games...</p>
            </li>
          </simplelist>
        </li>
      </simplelist>
      <p>Starting from the previous basic skeleton definition, we elaborate the LogNet's vision of what an 
      <i>Overlay Network Computer System</i>is. The reader can focus on the tiny, yet crucial differences.</p>
      <p id="uid19" id-text="2">
        <b>Definition 2 (Overlay Computer System)</b>
      </p>
      <p noindent="true">An overlay computer system consists of overlay computer hardware and overlay computer software.</p>
      <simplelist>
        <li id="uid20">
          <p noindent="true">Overlay Computer Hardware is the physical part of an overlay computer, including the digital circuitry, as distinguished from overlay computer software that is executed
          within the hardware. The hardware of an overlay computer 
          <em style="UNDERLINE">changes frequently</em>and it is 
          <em style="UNDERLINE">distributed in space and in time</em>. Hardware is organized in a network of collaborative computing agents connected via 
          <i>IP</i>or ad-hoc networks; hardware must be 
          <em style="UNDERLINE">negotiated</em>before being used.</p>
        </li>
        <li id="uid21">
          <p noindent="true">Overlay Computer Software consists of three parts, namely: overlay system software, overlay program software, and overlay application software.</p>
          <simplelist>
            <li id="uid22">
              <p noindent="true">Overlay System Software helps run the overlay computer hardware and the overlay computer system. Examples are 
              <em style="UNDERLINE">network middleware</em>playing as a 
              <em style="UNDERLINE">distributed opera-</em>
              <em style="UNDERLINE">ting system (dOS)</em>, resource discovery protocols, virtual intermittent protocols, security protocols, reputation protocols...</p>
            </li>
            <li id="uid23">
              <p noindent="true">Overlay Program Software usually provides tools to assist a programmer in writing overlay computer programs and software using different overlay programming
              languages. Examples are 
              <em style="UNDERLINE">compilers</em>, 
              <em style="UNDERLINE">interpreters</em>, linkers, debuggers for 
              <em style="UNDERLINE">workflow-</em>, 
              <em style="UNDERLINE">coordination-</em>, and 
              <em style="UNDERLINE">query-languages</em>.</p>
            </li>
            <li id="uid24">
              <p noindent="true">Overlay Application Software allows end-users to accomplish one or more specific (non-computer related) tasks, pertaining to fields such as industrial automation,
              business software, educational software, medical software, databases, and computer games...These classes of applications deal with computational power (
              <i>Grid</i>), file and storage retrieval (
              <i>P2P</i>), web services (
              <i>Web2.0</i>), band-services (
              <i>VoIP</i>), computation migrations...</p>
            </li>
          </simplelist>
        </li>
      </simplelist>
      <p>Therefore, LogNet's objectives can be summarized as follows:</p>
      <simplelist>
        <li id="uid25">
          <p noindent="true">to provide adequate notions and definitions of a generic overlay network computer; from a desktop distributed calculator to a programmable distributed overlay
          computer;</p>
        </li>
        <li id="uid26">
          <p noindent="true">on the basis of these definitions, to propose a precise architecture of a generic overlay network computer and implement it;</p>
        </li>
        <li id="uid27">
          <p noindent="true">on the basis of these definitions, to implement an overlay software factory suitable to help the logical and software assembling of an overlay network computer.</p>
        </li>
      </simplelist>
    </subsection>
    <subsection id="uid28" level="1">
      <bodyTitle>General definitions</bodyTitle>
      <p>An overlay network is a computer network which is built on top of another network. Overlay networks can be constructed in order to permit routing messages to destinations not specified by an
      
      <i>IP</i>address. In what follows, we briefly describe the main entities underneath a virtual organization.</p>
      <p noindent="true"><b>Agents.</b>An agent in the overlay is the basic computational entity of the overlay: it is typically a device, like a 
      <i>PDA</i>, a laptop, a 
      <i>PC</i>, or smaller devices, connected through 
      <i>IP</i>or other 
      <i>ad hoc</i>communication protocols in different fashion (wired, wireless). Agents in the overlay can be thought of as being connected by virtual or logical links, each of which corresponds to
      a path, through many physical links, in the underlying network. For example, many peer-to-peer networks are overlay networks because they run on top of the Internet.</p>
      <p noindent="true"><b>Colonies and colony leaders.</b>Agents in the overlay are regrouped in 
      <i>Colonies</i>. A colony is a simple virtual organization consists of exactly one 
      <i>leader</i>, offering some broker-like services, and some set of 
      <i>agents</i>. The leader, being also an agent, can be an agent of a colony different of the one he manages. Thus, agents are simple computers (think of them as 
      <i>amoebas</i>), or sub-colonies (think of them as 
      <i>protozoas</i>). Every colony has 
      <i>exactly</i>one leader and at least one agent (the leader itself). Logically, an agent can be seen as a 
      <i>collapsed colony</i>, or a 
      <i>leader managing itself</i>. The leader is the only one who knows all of the agents in its colony. One of the tasks of the leader is to manage (un)subscriptions to its colony.</p>
      <p noindent="true"><b>Resource discovery.</b>By adhering to a colony, an agent can expose resources he has and/or ask for resources it requires. Another task of a leader is to manage the resources available in
      its colony. Thus, when an agent of the overlay needs a specific resource, he makes a request to its leader. A leader is devoted to contacting and negotiating with potential servers, to
      authenticating clients and servers, and to routing requests. The rationale ensuring scalability is that every request is handled firstly inside its colony, and then forwarded through the proper
      super-leader (thus applying an 
      <i>endogenous-first-exogenous-last</i>strategy).</p>
      <p noindent="true"><b>Orchestration.</b>When an agent receives an acknowledgment of a service request from the direct leader, then the agent is served directly by the server(s) agents, 
      <i>i</i>.
      <i>e</i>. without further mediation of the leader, in a pure 
      <i>P2P</i>fashion. Thus, the “main” program will be run on the agent computer machine that launched the service request and received the resources availability: it will orchestrate and
      coordinate data and program resources executed on others agent computers.</p>
    </subsection>
    <subsection id="uid29" level="1">
      <bodyTitle>Background: Arigatoni overlay network computer</bodyTitle>
      <p>As suggested by our previous definitions, we are mainly concerned by three topics: network organization, resource discovery and orchestration. These topics are studied in a complementary way
      by 
      <i>Arigatoni</i>(work started by Luigi Liquori and Michel Cosnard). In this section we will describe the current status of 
      <i>Arigatoni</i>.</p>
      <p>The 
      <i>Arigatoni</i>overlay network computer, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid2" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid3" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid4" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid5" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid6" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid7" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid8" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>developed since 2006 in the Mascotte Project Team by Luigi Liquori and
      Michel Cosnard, and then in the LogNet team, is a structured multi-layer overlay network which provides resource discovery with variable guarantees in a virtual organization where peers can
      appear, disappear, and self-organize themselves dynamically. 
      <i>Arigatoni</i>is 
      <i>universal</i>in the sense of Turing machines, or 
      <i>generic</i>as the von Neumann computer architecture is.</p>
      <p>Every agent asks the broker to log into the colony by declaring the resources that it provides (with variable guarantees). Once logged in, an agent can ask the broker for other resources.
      Colonies can recursively be considered as 
      <i>evolved agents</i>who can log into an outermost colony, which is governed by another super-leader. Communications and routing intra-colonies go through a broker-2-broker 
      <i>PKI</i>-based negotiation. Every broker routes intra- and inter- 
      <i>service requests</i>by filtering its 
      <i>resource routing table</i>, and then forwarding the request firstly inside its colony, and secondly outside, via the proper super-leader (thus applying an 
      <i>endogenous-first-estrogen-last</i>strategy).</p>
      <p>Theoretically, queries are formulæ in first-order logic. When the client agent receives notification of all of (or part of) the requested resources, then the real resource exchange is
      performed directly by the server(s) agents, without any further mediation of the broker, in a pure peer-to-peer fashion. The proposed overlay promotes an 
      <i>intermittent</i>participation in the colony. Therefore, the routing process may lead to 
      <i>failures</i>, because some agents have quit, or are temporarily unavailable, or they were logged out by the broker due to their poor performance or greediness.</p>
      <p><i>Arigatoni</i>features essentially two protocols: the 
      <i>resource discovery protocol</i>dealing with the process of an agent broker to find and negotiate resources to serve an agent request in its own colony, and the 
      <i>virtual intermittent protocol</i>dealing with (un)registrations of agents to colonies.</p>
      <p>Dealing essentially with resource discovery and peers' churn has one important advantage: the complete generality and independence of any offered and requested resource. 
      <i>Arigatoni</i>can fit with various scenarios in the global computing arena, from classical 
      <i>P2P</i>applications (file- or bandwidth-sharing), to new 
      <i>Web2.0</i>applications, to new 
      <i>V2V</i>and 
      <i>V2I</i>over 
      <i>MANET</i>applications, to more sophisticated 
      <i>Grid</i>applications, until possible, futuristic 
      <i>migration computations</i>, 
      <i>i</i>.
      <i>e</i>. transfer of a non-completed local run to another agent, the latter being useful in case of catastrophic scenarios, such as fire, a terrorist attack, an earthquake, etc.</p>
      <subsection id="uid30" level="2">
        <bodyTitle>Arigatoni units</bodyTitle>
        <p>In what follows, we briefly introduce the logic units underneath a generic overlay network.</p>
        <p>Peers' participation in 
        <i>Arigatoni</i>'s colonies is managed by the 
        <i>Virtual Intermittent Protocol (</i>
        <i>VIP</i>
        <i>)</i>; the protocol deals with the 
        <i>dynamic topology</i>of the overlay, by allowing agent computers to login/logout to/from a colony (using the 
        <i>SREG</i>message). Due to this high node churn, the routing process may lead to 
        <i>failures</i>, because some agents have logged out, or because they are temporarily unavailable, or because they have logged out 
        <i>manu militari</i>by the broker for their poor performance or greediness.</p>
        <p>The total decoupling between peers in 
        <i>space</i>(peers do not know other peers' locations), 
        <i>time</i>(peers do not participate in the interaction at the same time), 
        <i>synchronization</i>(peers can issue service requests and do something else, or may be doing something else when being asked for services), and 
        <i>encapsulation</i>(peers do not know each other) are key features of 
        <i>Arigatoni</i>'s scalability.</p>
        <p noindent="true"><b>Agent computer (AC).</b>This unit can be, 
        <i>e</i>.
        <i>g</i>., a cheap computer device consisting of a small 
        <i>RAM-ROM-HD</i>memory capacity, a modest 
        <i>CPU</i>, a 
        <span class="math"><img width="14" height="24" align="middle" border="0" src="../../images/img_other_le.png" alt="$ \le$"/>40</span>keystrokes keyboard (or touchscreen), a tiny screen (
        <span class="math"><img width="14" height="24" align="middle" border="0" src="../../images/img_other_le.png" alt="$ \le$"/></span>4 inch), an 
        <i>IP</i>or 
        <i>ad hoc</i>connection (via 
        <i>DHCP</i>, 
        <i>BLUETOOTH</i>, 
        <i>WIFI</i>, 
        <i>WIMAX</i>...), a 
        <i>USB</i>port, and very few programs installed inside, 
        <i>e</i>.
        <i>g</i>. one simple editor, one or two compilers, a 
        <tt>mail</tt>client, a mini browser... Our favorite device actually is the Internet terminal 
        <i>Nokia N810</i>. Of course, a 
        <i>AC</i>can be a supercomputer, or an high performance 
        <i>PC</i>-cluster, a large database server, a high performance visualizer (
        <i>e</i>.
        <i>g</i>. connected to a virtual reality center), or any particular resource provider, even a 
        <i>smart-dust</i>. The operating system (if any) installed within the 
        <i>AC</i>is not important. The computer should be able to work in 
        <i>local mode</i>for all of the tasks that it could do locally, or in 
        <i>global mode</i>, by first registering itself to one or many colonies of the overlay, and then by asking and serving global requests via the colony leaders. In a nutshell, the tasks of an 
        <i>AC</i>are:</p>
        <simplelist>
          <li id="uid31">
            <p noindent="true">Discover the address of one or many agent brokers (
            <i>AB</i>s), playing as colony leaders, upon its arrival in a “connected area”; this can be done using the underlay network and related technologies;</p>
          </li>
          <li id="uid32">
            <p noindent="true">Register on one or many 
            <i>AB</i>s, thus 
            <i>de facto</i>entering the 
            <i>Arigatoni</i>'s virtual organization;</p>
          </li>
          <li id="uid33">
            <p noindent="true">Ask and offer some services to others 
            <i>AC</i>s, via the leaders' 
            <i>AB</i>s;</p>
          </li>
          <li id="uid34">
            <p noindent="true">Connect directly with other 
            <i>AC</i>s in a 
            <i>P2P</i>fashion, and offer/receive some services. Note that an 
            <i>AC</i>can also be a resource provider. This symmetry is one of the key features of 
            <i>Arigatoni</i>. For security reasons, we assume that all 
            <i>AC</i>s come with their proper 
            <i>PKI</i>certificate.</p>
          </li>
        </simplelist>
        <p noindent="true"><b>Agent Broker (AB).</b>This unit can be, 
        <i>e</i>.
        <i>g</i>., a computer device made up of a high speed 
        <i>CPU</i>, an 
        <i>IP</i>or 
        <i>ad hoc</i>connection (via 
        <i>DHCP</i>, 
        <i>BLUETOOTH</i>, 
        <i>WIFI</i>, 
        <i>WIMAX</i>...), a high speed hard-disk with a 
        <i>resource routing table</i>to route queries, and an efficient program to match and filter the routing table. The computer should be able to work in 
        <i>global mode</i>, by first registering itself in the overlay and then receiving, filtering and dispatching global requests through the network. The tasks of a 
        <i>AB</i>are:</p>
        <simplelist>
          <li id="uid35">
            <p noindent="true">Discover the address of another 
            <i>super</i>-
            <i>AB</i>, representing the 
            <i>super-leader</i>of the 
            <i>super-colony</i>, where the 
            <i>AB</i>colony is embedded. We assume that every 
            <i>AB</i>comes with its proper 
            <i>PKI</i>certificate. The policy to accept or refuse the registration of an 
            <i>AC</i>with a different 
            <i>PKI</i>is left open to the level of security requested by the colony;</p>
          </li>
          <li id="uid36">
            <p noindent="true">Register/unregister the proper colony with the 
            <i>leader</i>
            <i>AB</i>which manages the super-colony;</p>
          </li>
          <li id="uid37">
            <p noindent="true">Register/unregister clients and servants 
            <i>AC</i>in its colony, and update the internal resource routing table accordingly;</p>
          </li>
          <li id="uid38">
            <p noindent="true">Receive the request for servicing of the client 
            <i>AC</i>;</p>
          </li>
          <li id="uid39">
            <p noindent="true">Discover the resources that satisfy an 
            <i>AC</i>request in its local base (local colony), according to its resource routing table;</p>
          </li>
          <li id="uid40">
            <p noindent="true">Delegate the request to an 
            <i>AB</i>leader of the direct super-colony in case the resource cannot be satisfied in its proper colony; it must register itself (and by product its colony) with another
            super-colony;</p>
          </li>
          <li id="uid41">
            <p noindent="true">Perform a combination of the last two actions mentioned above;</p>
          </li>
          <li id="uid42">
            <p noindent="true">Deal with all 
            <i>PKI</i>intra- and inter-colony policies;</p>
          </li>
          <li id="uid43">
            <p noindent="true">Notify, after a fixed 
            <i>timeout period</i>, or when all 
            <i>AC</i>s failed to satisfy the delegated request, the 
            <i>AC</i>client of the 
            <i>denial of service</i>requested by the 
            <i>AC</i>client;</p>
          </li>
          <li id="uid44">
            <p noindent="true">Send all the information necessary to make the 
            <i>AC</i>client able to communicate with the 
            <i>AC</i>servants. This notification is encoded using the resource discovery protocol. (Finally, the 
            <i>AC</i>client will directly talk with the 
            <i>AC</i>s servants).</p>
          </li>
        </simplelist>
        <p noindent="true"><b>Agent Router (AR).</b>This unit implements all the low-level overlay network routines, those which really have access to the 
        <i>IP</i>or to the 
        <i>ad-hoc</i>connections. In a nutshell, an 
        <i>AR</i>is a shared library dynamically linked with an 
        <i>AC</i>or an 
        <i>AB</i>. The 
        <i>AR</i>is devoted to the following tasks:</p>
        <simplelist>
          <li id="uid45">
            <p noindent="true">Upon the initial start-up of an 
            <i>AC</i>(resp. 
            <i>AB</i>) it helps to register the unit with one or many 
            <i>AB</i>s that it knows or discovers;</p>
          </li>
          <li id="uid46">
            <p noindent="true">Checks the well-formedness and forwards packets of the two 
            <i>Arigatoni</i>'s protocols across the overlay toward their destinations.</p>
          </li>
        </simplelist>
      </subsection>
      <subsection id="uid47" level="2">
        <bodyTitle>Virtual organizations</bodyTitle>
        <p>Agent computers communicate by first registering with the colony and then by asking and offering services. The leader agent broker analyzes service requests/responses, coming from its own
        colony or arriving from a surrounding colony, and routes requests/responses to other agents. Agent computers get in touch with each other without any further intervention from the system, in
        a 
        <i>P2P</i>fashion. Peers' coordination is achieved by a simple program written in an orchestration/business language 
        <i>à la</i>
        <i>BPEL</i>, or 
        <i>JOpera</i>.</p>
        <p>Symmetrically, the leader of a colony can arbitrarily unregister an agent from its colony, 
        <i>e</i>.
        <i>g</i>., because of its bad performance when dealing with some requests or because of its high number of “embarrassing” requests for the colony. This strategy, reminiscent of the Roman 
        <i>do ut des</i>, is nowadays called, in Game Theory, Rapoport's 
        <i>tit-for-tat</i>strategy 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid9" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>of cooperation based on reciprocity. Tit-for-tat is commonly used in
        economics, social sciences, and it has been implemented by a computer program as a winning strategy in a chess-play challenge against humans (see also the well known 
        <i>prisoner dilemma</i>). In computer science, the tit-for-tat strategy is the stability (
        <i>i</i>.
        <i>e</i>. balanced uploads and downloads) policy of the 
        <i>Bittorrent</i>
        <i>P2P</i>protocol.</p>
        <p>Once an agent computer has issued a request for some service, the system finds some agent computers (or, recursively, some sub-colonies) that can offer the resources needed, and
        communicates their identities to the (client) agent computer as soon as they are found.</p>
        <p>The model also offers some mechanisms to dynamically adapt to 
        <i>dynamic topology changes</i>of the overlay network, by allowing an agent (computer or broker, representing a sub-colony) to login/logout to/from a colony. This essentially means that the
        process of routing request/responses may lead to failure, because some agents logged out or because they are temporarily unavailable (recall that agents are not slaves). This may also lead to
        temporary denials of service or, more drastically, to the complete logout of an agent from a given colony in the case where the former does not provide enough services to the latter.</p>
      </subsection>
      <subsection id="uid48" level="2">
        <bodyTitle>Resource discovery protocol (RDP)</bodyTitle>
        <p noindent="true"><b>Kind of discovery.</b>The are mostly two mechanisms of resource discovery, namely:</p>
        <simplelist>
          <li id="uid49">
            <p noindent="true">The process of an 
            <i>AB</i>to find and negotiate resources to serve an 
            <i>AC</i>request in its own colony;</p>
          </li>
          <li id="uid50">
            <p noindent="true">The process of an 
            <i>AC</i>(resp. 
            <i>AB</i>) to discover an 
            <i>AB</i>, upon physical/logical insertion in a colony.</p>
          </li>
        </simplelist>
        <p>The first discovery is processed by 
        <i>Arigatoni</i>'s resource discovery protocol, while the second is processed out of the 
        <i>Arigatoni</i>overlay, using well-known network protocols, like 
        <i>DHCP</i>, 
        <i>DNS</i>, the service discovery protocol 
        <i>SLP</i>of 
        <i>BLUETOOTH</i>, or Active/Passive Scanning in 
        <i>WIFI</i>.</p>
        <p>The current 
        <i>RDP</i>protocol version allows the request for 
        <i>multiple services</i>and 
        <i>service conjunctions</i>. Adding service conjunctions allows an 
        <i>AC</i>to offer several services at the same time. Multiple service requests can be also asked of an 
        <i>AB</i>; each service is processed sequentially and independently of the others. As an example of multiple instances, an 
        <i>AC</i>may ask for three 
        <i>CPU</i>s, 
        <i>or</i>one chunk of 
        <i>10GB</i>of 
        <i>HD</i>, 
        <i>or</i>one 
        <tt>gcc</tt>compiler. As an example of a service conjunction, an 
        <i>AC</i>may ask for another 
        <i>AC</i>offering 
        <i>at the same time</i>one 
        <i>CPU</i>s, 
        <i>and</i>one chunk of 
        <i>1GB</i>of 
        <i>RAM</i>, 
        <i>and</i>one chunk of 
        <i>10GB</i>of 
        <i>HD</i>, 
        <i>and</i>one 
        <tt>gcc</tt>compiler. If a request succeeds, then, using a simple orchestration language, the 
        <i>AC</i>client will use all resources offered by the servers 
        <i>AC</i>s.</p>
        <p>The 
        <i>RDP</i>protocol proceeds as follows: suppose an 
        <i>AC</i>
        <span class="math"><img align="bottom" width="9" height="10" src="math_image_1.png" xylemeAttach="9" border="0" alt="Im1 $\#120247 $"/></span>registers – using the intermittent protocol 
        <i>VIP</i>presented below – with an 
        <i>AB</i>and declares its availability to offer a service 
        <span class="math"><img align="bottom" width="7" height="10" src="math_image_2.png" xylemeAttach="10" border="0" alt="Im2 $\#120242 $"/></span>, while another 
        <i>AC</i>
        <span class="math"><img align="bottom" width="9" height="10" src="math_image_3.png" xylemeAttach="11" border="0" alt="Im3 $\#120248 $"/></span>, already registered, issues a request for a service 
        <span class="math"><img align="bottom" width="11" height="10" src="math_image_4.png" xylemeAttach="12" border="0" alt="Im4 ${\#120242 }^'$"/></span>. Then, the 
        <i>AB</i>looks in its 
        <i>routing table</i>and 
        <i>filters</i>
        <span class="math"><img align="bottom" width="11" height="10" src="math_image_4.png" xylemeAttach="12" border="0" alt="Im4 ${\#120242 }^'$"/></span>against 
        <span class="math"><img align="bottom" width="7" height="10" src="math_image_2.png" xylemeAttach="10" border="0" alt="Im2 $\#120242 $"/></span>. If there exists a solution to this filter equation, then 
        <span class="math"><img align="bottom" width="9" height="10" src="math_image_1.png" xylemeAttach="9" border="0" alt="Im1 $\#120247 $"/></span>can provide a resource to 
        <span class="math"><img align="bottom" width="9" height="10" src="math_image_3.png" xylemeAttach="11" border="0" alt="Im3 $\#120248 $"/></span>. For example, the resource 
        <span class="math"><img align="middle" width="192" height="18" src="math_image_5.png" xylemeAttach="13" border="0" alt="Im5 ${\#120242 {~\mover =\#9653 ~}[\#120226 \#120239 \#120244 =\#120232 \#120263 \#120269 \#120254 \#120261 ,\#120243 \#120258 \#120262 \#120254 \#8804 10\#120268 \#120254 \#120252 ]}$"/></span>filters against 
        <span class="math"><img align="middle" width="189" height="18" src="math_image_6.png" xylemeAttach="14" border="0" alt="Im6 ${{\#120242 }^'{~\mover =\#9653 ~}{[\#120226 \#120239 \#120244 =\#120232 \#120263 \#120269 \#120254 \#120261 ,\#120243 \#120258 \#120262 \#120254 \#8805 5\#120268 \#120254 \#120252 ]}}$"/></span>, with attribute values 
        <span class="math"><img align="bottom" width="22" height="10" src="math_image_7.png" xylemeAttach="15" border="0" alt="Im7 $\#120232 \#120263 \#120269 \#120254 \#120261 $"/></span>and 
        <span class="math"><img align="bottom" width="30" height="10" src="math_image_8.png" xylemeAttach="16" border="0" alt="Im8 $\#120243 \#120258 \#120262 \#120254 $"/></span>between 
        <span class="math">5</span>and 
        <span class="math">10</span>seconds.</p>
        <p noindent="true"><b>Routing tables in RDP.</b>In 
        <i>Arigatoni</i>, each 
        <i>AB</i>maintains a 
        <i>routing table</i><span class="math"><img align="bottom" width="9" height="10" src="math_image_9.png" xylemeAttach="17" border="0" alt="Im9 $\#120243 $"/></span>locating the 
        <i>services</i>that are registered in its colony. The table is updated according to the 
        <i>dynamic registration and unregistration</i>of 
        <i>AC</i>s in the overlay; thus, each 
        <i>AB</i>maintains a partition of the data space. When an 
        <i>AC</i>asks for a resource (service request), then the query is 
        <i>filtered</i>against the routing tables of the 
        <i>AB</i>s where the query has arrived and the 
        <i>AC</i>is registered; in case of a 
        <i>filter-failure</i>, the 
        <i>AB</i>s forward the query to their direct super-
        <i>AB</i>s. Any answer of the query must follow the reverse path.</p>
        <p>Thus, resource lookup overhead reduces when a query is satisfied in the current colony. Most structured overlays guarantee lookup operations that are logarithmic in the number of nodes. To
        improve routing performance, caching and replication of data and search paths can be adopted. Replication also improves load balancing, fault tolerance, and the durability of data items.</p>
      </subsection>
      <subsection id="uid51" level="2">
        <bodyTitle>Virtual Intermittent Protocol (VIP)</bodyTitle>
        <p>There are essentially two ways in which an 
        <i>AC</i>can register to an 
        <i>AB</i>(sensible to its physical position in the network topology), the latter not being enforced by the 
        <i>Arigatoni</i>model (see 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid7" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>):</p>
        <orderedlist>
          <li id="uid52">
            <p noindent="true">Registration of an 
            <i>AC</i>to an 
            <i>AB</i>belonging to the same 
            <i>current administrative domain</i>;</p>
          </li>
          <li id="uid53">
            <p noindent="true">Registration via 
            <i>tunneling</i>of an 
            <i>AC</i>to another 
            <i>AB</i>belonging to a 
            <i>different administrative domain</i>.</p>
          </li>
        </orderedlist>
        <p>If both registrations apply, the 
        <i>AC</i>is 
        <i>de facto</i>working in local mode 
        <i>in the current administrative domain</i>and working in global mode 
        <i>in another administrative domain</i>. Symmetrically, an 
        <i>AC</i>can unregister according to the following simple rules 
        <i>“d'étiquette”</i>:</p>
        <simplelist>
          <li id="uid54">
            <p noindent="true">Unregistration of an 
            <i>AC</i>is allowed only when there are no pending services demanded of or requested from the leader 
            <i>AB</i>of the colony: agent computers must always wait for an answer of the 
            <i>AB</i>or for a direct connection of the 
            <i>AC</i>requesting or offering the promised service, or wait for an internal timeout (the time-frame must be negotiated with the 
            <i>AB</i>);</p>
          </li>
          <li id="uid55">
            <p noindent="true">(As a corollary of the above) an 
            <i>AB</i>cannot unregister from its own colony, 
            <i>i</i>.
            <i>e</i>. it cannot discharge itself. However, for fault tolerance purposes, an 
            <i>AB</i>can be faulty. In that case, the 
            <i>AC</i>s unregister one after the other and the colony disappears;</p>
          </li>
          <li id="uid56">
            <p noindent="true">Once an 
            <i>AC</i>has been disconnected from a colony belonging to any administrative domain, it can physically migrate into another colony belonging to any other administrative domain;</p>
          </li>
          <li id="uid57">
            <p noindent="true">Selfish agents in 
            <i>P2P</i>networks, called “free riders”, that only utilize other peers' resources without providing any contribution in return, can be fired by a leader; if the leader of a colony finds
            that the agent's ratio of fairness is too small (
            <span class="math"><img width="14" height="24" align="middle" border="0" src="../../images/img_other_le.png" alt="$ \le$"/><img width="9" height="12" align="bottom" border="0" src="../../images/img_epsilon.png" alt="$ \epsilon$"/></span>for a given 
            <span class="math"><img width="9" height="12" align="bottom" border="0" src="../../images/img_epsilon.png" alt="$ \epsilon$"/></span>), he can arbitrarily decide to fire that agent without notice. Here, the 
            <i>VIP</i>protocol also checks that the agent has no pending services to offer, or that the timeout of some promised services has expired, the latter case meaning that the free rider
            promised some services but finally did not provide any service at all (untrustworthiness).</p>
          </li>
        </simplelist>
        <p noindent="true"><b>Registration policies in VIP.</b><i>VIP</i>registration policies are usually not specified in the protocol itself; thus, every agent broker is free to choose its acceptance policy. This induces different self-organization
        policies and allows for reasoning on the colony's load-balancing and kind of colonies. Possible politics and are:</p>
        <simplelist>
          <li id="uid58">
            <p noindent="true"><b>(mono-thematic)</b>An agent broker accept an agent into its colony if the latter offers resources 
            <span class="math"><img align="bottom" width="7" height="10" src="math_image_2.png" xylemeAttach="10" border="0" alt="Im2 $\#120242 $"/></span>that the colony already has in quantity 
            <span class="math"><img width="14" height="24" align="middle" border="0" src="../../images/img_other_ge.png" alt="$ \ge$"/><img width="9" height="12" align="bottom" border="0" src="../../images/img_epsilon.png" alt="$ \epsilon$"/></span>, for a given 
            <span class="math"><img width="9" height="12" align="bottom" border="0" src="../../images/img_epsilon.png" alt="$ \epsilon$"/></span>;</p>
          </li>
          <li id="uid59">
            <p noindent="true"><b>(multi-thematic)</b>An agent broker accept an agent if the latter offers resources that the colony has in quantity 
            <span class="math"><img width="14" height="24" align="middle" border="0" src="../../images/img_other_le.png" alt="$ \le$"/><img width="9" height="12" align="bottom" border="0" src="../../images/img_epsilon.png" alt="$ \epsilon$"/></span>, for a given 
            <span class="math"><img width="9" height="12" align="bottom" border="0" src="../../images/img_epsilon.png" alt="$ \epsilon$"/></span>;</p>
          </li>
          <li id="uid60">
            <p noindent="true"><b>(unbalanced)</b>An agent broker accepts an agent always;</p>
          </li>
          <li id="uid61">
            <p noindent="true"><b>(pay-per-service)</b>An agent broker accepts only agents that accept to pay some services;</p>
          </li>
          <li id="uid62">
            <p noindent="true"><b>(metropolis/village)</b>An agent broker accepts an agent into its colony only if the number of citizens is greater/lesser than 
            <span class="math"><hi rend="it">N</hi></span>;</p>
          </li>
          <li id="uid63">
            <p noindent="true"><b>(custom)</b>An agent broker accepts an agent following a mix of the above politics.</p>
          </li>
        </simplelist>
      </subsection>
      <subsection id="uid64" level="2">
        <bodyTitle>Two simple examples</bodyTitle>
        <p>To give an idea of the possible usage of the 
        <i>Arigatoni</i>generic overlay network we present two examples; the first one has a 
        <i>Grid</i>-computing flavor while the second is a nice interweaving of the 
        <i>Arigatoni</i>overlay seated on the top of both 
        <i>IP</i>and 
        <i>MANET</i>underlay network. For more information, the interested reader can have a look on 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid2" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid0" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid1" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
        <object id="uid65">
          <table>
            <tr>
              <td>
                <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/GRID.png" xylemeAttach="5" xlink:href="IMG/GRID" type="float" width="192.1487pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
              </td>
            </tr>
          </table>
          <caption><i>Arigatoni</i>Overlay Network for a 
          <i>Grid</i>Seismic Monitoring Application</caption>
        </object>
        <p noindent="true"><b>GRID: scenario for seismic monitoring.</b>John, chief engineer of the SeismicDataCorp Company, Taiwan, on board of the seismic data collector ship, has to decide on the next data
        collecting campaign. For this he would like to process and analyze 100 TeraBytes of seismic data that have been recorded on the data mass recorder located in the offshore data repository of
        the company. He has written the processing program for modeling and visualizing the seismic cube using some 
        <i>parallel library</i>like 
        <i>e</i>.
        <i>g</i>. 
        <tt>MPI</tt>or 
        <tt>PVM</tt>: his program can be distributed over different machines that will compute a chunk of the whole processing; however, the amount of computation is so big that a supercomputer and a
        cluster of PCs have to be 
        <i>rented</i>by the SeismicDataCorp company. John will ask also for 
        <i>bandwidth</i>in order to get rid of any bottlenecks related to the big amount of data to be transferred. Then, the processed data should be analyzed using the 
        <i>Virtual Reality Center, (</i><i>VRC</i><i>)</i>based in Houston, U.S.A. by a specialist team and the resulting recommendations for the next data collect campaign have to be sent to John. With this in mind:</p>
        <orderedlist>
          <li id="uid66">
            <p noindent="true">John logs onto the 
            <i>Arigatoni</i>Overlay Network in a given colony in Taiwan, and sends a quite complicated service request in order for the data to be processed using his own code. Usually the 
            <i>AB</i>leader of the colony will receive and process the request;</p>
          </li>
          <li id="uid67">
            <p noindent="true">If the Resource Discovery performed by the 
            <i>AB</i>succeeds, 
            <i>i</i>.
            <i>e</i>. a supercomputer and a cluster and an 
            <i>ISP</i>are found, then the data are transferred at a very high speed and the 
            <i>“Sinfonia”</i>begins;</p>
          </li>
          <li id="uid68">
            <p noindent="true">John will also ask (in the 
            <i>RDP</i>request) to the 
            <i>AC</i>containing the seismic data to dispatch suitable chunks of data to the supercomputer and the cluster designated by the 
            <i>AB</i>to perform some pieces of computation;</p>
          </li>
          <li id="uid69">
            <p noindent="true">John will also ask (in the 
            <i>RDP</i>request) to the supercomputer to perform the task of collecting all intermediate results, so calculating the final result of the computation, like a 
            <i>“Maestro di Orchestra”</i>;</p>
          </li>
          <li id="uid70">
            <p noindent="true">The processed data are then sent from the supercomputer, via the high speed 
            <i>ISP</i>, to the Houston center for being visualized and analyzed;</p>
          </li>
          <li id="uid71">
            <p noindent="true">Finally, the specialist team's recommendations will be sent to John's laptop.</p>
          </li>
        </orderedlist>
        <p>This scenario is pictorially presented in Figure 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#uid65" location="intern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>(we suppose a number of sub-colonies with related leaders 
        <i>AB</i>, all registered as agents to a super-
        <i>AB</i>;for example the John's 
        <i>AB</i>could be elected as the super-leader). For simplify security issues, all 
        <i>AB</i>'s are trusted using the same 
        <i>PKI</i>, making all resources of their colonies 
        <i>de facto</i>common. An animation of the coordination program, written in the visual language 
        <i>JOpera</i>can be downloaded at 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/members/Luigi.Liquori/ARIGATONI/arigatoni_animation.wmv" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
        <allowbreak/>www-sop.
        <allowbreak/>inria.
        <allowbreak/>fr/
        <allowbreak/>members/
        <allowbreak/>Luigi.
        <allowbreak/>Liquori/
        <allowbreak/>ARIGATONI/
        <allowbreak/>arigatoni_animation.
        <allowbreak/>wmv</ref>.</p>
      </subsection>
    </subsection>
    <subsection id="uid72" level="1">
      <bodyTitle>General research directions</bodyTitle>
      <p>Following our main three topics, network organization, resource discovery and orchestration, for middle and long term research, we envisage the following studies.</p>
      <subsection id="uid73" level="2">
        <bodyTitle>On Virtual organizations</bodyTitle>
        <simplelist>
          <li id="uid74">
            <p noindent="true"><b>Trees</b><i><b>vs.</b></i><b>graphs: a conflict without a cause</b>. In the first versions of 
            <i>Arigatoni</i>, the network topology was tree- or forest-based. But since agents are not slaves, multiple registrations are in principle possible and unavoidable. This weaves the
            network topology into a 
            <i>dynamic graph</i><ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid10" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, where nodes do not have a complete knowledge of the topology
            itself. As an immediate consequence, our protocols must deal with multiple registrations of the same agent in different colonies, with the natural consequence of resource overbooking,
            routing table update loops (when a service update request comes back to the broker that generates the request itself), and resource discovery loops (when a resource service request comes
            back to the agent that generates the request itself), see 
            <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid4" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
            <p>As an example of resource overbooking, suppose an agent computer registers to two colonies, by declaring and offering the same resource 
            <i>S</i>twice, 
            <i>i</i>.
            <i>e</i>. once for each colony. This phenomenon is well known in the telecommunications industry, as in the “frame-relay” world. For the record, overbooking in telecommunications means
            that a telephone company has sold access to too many customers who basically flood the telephone company lines, resulting in an inability for some customers to use what they purchased.
            Other examples of overbooking can be found in the domain of transportation (airlines) and hotel reservations.</p>
            <p>Resource discovery is a non-trivial problem for large distributed systems featuring a discontinuous amount of resources offered by agent computers and their intermittent participation
            in the overlay. Peers' intermittence lead also to the design of new routing algorithms and protocols stable to agent churn; this scenario can be modeled using dynamic graph theory.</p>
          </li>
          <li id="uid75">
            <p noindent="true"><b>Fault tolerance</b>. The virtual organization model offers some mechanisms to dynamically adapt to 
            <i>dynamic topology changes</i>of the overlay network, by allowing an agent (computer or broker, representing a sub-colony) to login/logout in/from a colony. This essentially means that
            the process of routing requests and responses may lead to failure, because some agents logged out or because they are temporarily unavailable (recall that agents are not slaves). This may
            also lead to temporary denials of service or, more drastically, to the complete “delogging” of an agent from a given colony in the case where the former does not provide enough services
            to the latter.</p>
          </li>
        </simplelist>
      </subsection>
      <subsection id="uid76" level="2">
        <bodyTitle>On Resource discovery</bodyTitle>
        <simplelist>
          <li id="uid77">
            <p noindent="true"><b>Parametricity and universality</b>. Dealing only with resource discovery has one important advantage: the complete generality and independence of any offered and requested resource.
            Thus, 
            <i>Arigatoni</i>can fit with various scenarios in the agent computing arena, from classical 
            <i>P2P</i>applications, like file- or band-sharing, to more sophisticated 
            <i>Grid</i>applications, like remote and distributed big (and small) computations, until possible, futuristic 
            <i>migration computations</i>, 
            <i>i</i>.
            <i>e</i>. transfer of a non completed local run in another agent computer, the latter being useful in case of catastrophic scenarios, such as fire, a terrorist attack, an earthquake,
            etc., in the vein of agent programming languages 
            <i>à la</i><i>Obliq</i>or 
            <i>Telescript</i>. We could envisage at least the following scenarios to be a tight fit for our model:</p>
            <simplelist>
              <li id="uid78">
                <p noindent="true">Request for computational power (
                <i>i</i>.
                <i>e</i>. the 
                <i>Grid</i>);</p>
              </li>
              <li id="uid79">
                <p noindent="true">Request for memory space (
                <i>i</i>.
                <i>e</i>. distributed storage);</p>
              </li>
              <li id="uid80">
                <p noindent="true">Request for bandwidth (
                <i>i</i>.
                <i>e</i>. 
                <i>VoIP</i>);</p>
              </li>
              <li id="uid81">
                <p noindent="true">Request for a distributed file retrieving (
                <i>i</i>.
                <i>e</i>. standard 
                <i>P2P</i>applications);</p>
              </li>
              <li id="uid82">
                <p noindent="true">Request for a (possibly) distributed web service (
                <i>i</i>.
                <i>e</i>. query 
                <i>à la</i>
                <i>G</i>
                <i>o</i>
                <i>o</i>
                <i>g</i>
                <i>l</i>
                <i>e</i>
                <i>or any service available via web-oriented protocols);</i></p>
              </li>
              <li id="uid83">
                <p noindent="true">
                  <i>Orchestration of a distributed execution of an algorithm (</i>
                  <i>
                    <i>i</i>
                  </i>
                  <i>.</i>
                  <i>
                    <i>e</i>
                  </i>
                  <i>. a kind of distributed von Neumann machine);</i>
                </p>
              </li>
              <li id="uid84">
                <p noindent="true">
                  <i>Request for a computation migration (</i>
                  <i>
                    <i>i</i>
                  </i>
                  <i>.</i>
                  <i>
                    <i>e</i>
                  </i>
                  <i>. transfer one partial run in another agent computer, saving the partial results, as in a truly mobile ubiquitous computation);</i>
                </p>
              </li>
              <li id="uid85">
                <p noindent="true">
                  <i>Request for a</i>
                  <i>
                    <i>human computer interaction</i>
                  </i>
                  <i>(the human playing the role of an agent)...</i>
                </p>
              </li>
            </simplelist>
          </li>
        </simplelist>
        <simplelist>
          <li id="uid86">
            <p noindent="true"><b>Social model underneath an overlay network computer</b>. The 
            <i>Arigatoni</i>overlay network computer defines mechanisms for devices to inter-operate, by offering services, in a way that is reminiscent to Rapoport's 
            <i>tit-for-tat</i>strategy of co-operation based on reciprocity. This way to understand common behavior of virtual organizations has some theoretical basis on Game Theory. Classical
            results from game theory are based on the assumption that a shared amount of resources is available and then users have an incentive to collaborate. The very first design of 
            <i>Arigatoni</i>forced each 
            <i>AC</i>to register to only one 
            <i>AB</i>. But, recent studies showed that the 
            <i>Arigatoni</i>overlay can be smoothly scaled up to a more general topology where each 
            <i>AC</i>may simultaneously be registered to several 
            <i>AB</i>, and where a 
            <i>colony</i>is just one possible 
            <i>social scheme</i><ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid11" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
            <p>This means that 
            <i>Arigatoni</i>fits with motivations and cooperation behavior of different communities. It tries to be 
            <i>policy neutral</i>, leaving policy choices for each agent at the implementation or configuration level, or at the community or organization level. Policy domains can overlap (one agent
            can define himself as belonging “much” to the colony 
            <i>foo</i>and “a little bit” to the colony 
            <i>bar</i>). This denotes a decentralized non-exclusive policy model. As such, one question can arise: who is 
            <i>Arigatoni</i>designed for? We believe the overlay is flexible enough to serve a mix of different “social structures” and “end-users”:</p>
            <simplelist>
              <li id="uid87">
                <p noindent="true">Independent end-user connecting through his 
                <i>ISP</i>or migrating from hot-spot to hot-spot;</p>
              </li>
              <li id="uid88">
                <p noindent="true">Cooperative communities of disseminated agents;</p>
              </li>
              <li id="uid89">
                <p noindent="true">More regulated or hierarchical communities (maybe a better view of a corporate network);</p>
              </li>
              <li id="uid90">
                <p noindent="true">Cooperative or competitive resource providers and resource brokers.</p>
              </li>
            </simplelist>
          </li>
          <li id="uid91">
            <p noindent="true"><b>Quality metrics underneath an overlay network computer</b>. The 
            <i>Arigatoni</i>overlay network computer is suitable to support various extended trust models. Moreover, the reputation score could be expanded to a multi-dimensional value, for example,
            by adding a score for quality of the service offered by an agent. However, 
            <i>Arigatoni</i>encourages cooperation and enables gratuitous resource offering. But it may also suit business extensions, 
            <i>e</i>.
            <i>g</i>.:</p>
            <simplelist>
              <li id="uid92">
                <p noindent="true">An agent computer can sell resource usage, creating a resource business;</p>
              </li>
              <li id="uid93">
                <p noindent="true">An agent broker can sell a resource discovery service, creating a brokering business (
                <i>“I point you to the best resources, more quickly than anyone else”</i>).</p>
              </li>
            </simplelist>
            <p>The 
            <i>Arigatoni</i>overlay network computer is suitable of a number of service extensions – among others:</p>
            <simplelist>
              <li id="uid94">
                <p noindent="true">How to create and call third party services for on-line payment of services;</p>
              </li>
              <li id="uid95">
                <p noindent="true">How to exchange digital cash for payment of services;</p>
              </li>
              <li id="uid96">
                <p noindent="true">How to negotiate service conditions between client and servants, including the price and quality of service.</p>
              </li>
            </simplelist>
            <p>The one-to-many nature of the 
            <i>RDP</i>protocol service request (
            <i>SREQ</i>) are of particular interest in this case. Another possible 
            <i>Arigatoni</i>extension may define how to join a third party auction server. Candidate servants for a 
            <i>SREQ</i>would contact the auction server and make their bid. The trusted auction server chooses the elected candidate and service conditions based on auction terms. The agent would
            then contact the auction server and get this information. Those extensions may take advantage of the 
            <i>RDP</i>optional fields 
            <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid2" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, for example to transmit location and parameter information to
            call a third party system.</p>
          </li>
        </simplelist>
      </subsection>
      <subsection id="uid97" level="2">
        <bodyTitle>Execution model</bodyTitle>
        <simplelist>
          <li id="uid98">
            <p noindent="true"><b>Programming an overlay network computer</b>. Once resources (hardware, software...) have been discovered, the agent computer that made the request may wish to use and manipulate it; to
            do this, the agent computer has written a (distributed) program in a new language (
            <i>à la</i><i>BPEL</i>, 
            <i>LINDA</i>, 
            <i>YAWL</i>, 
            <i>JOpera</i>...), let's call it 
            <i>Ivonne</i>, in honor to the great scientist John von Neumann. Those languages are often called (terminology often overlaps), 
            <i>coordination- workflow- dataflow- orchestration- composition- metaprogramming- languages</i>. 
            <i>Ivonne</i>will have 
            <i>ad hoc</i>primitives to express sequences, iterators, cycles, parallel split, joins, synchronization, exclusive/multi/deferred choice, simple/multi/synchronizing merge, discriminators,
            pipelining, cancellation, implicit termination, exception handling... 
            <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid12" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
            <p>The “main” of an 
            <i>Ivonne</i>program will be run on the agent computer machine that launched the service request and received the resources availability: it will orchestrate and coordinate data and
            program resources executed on others agent computers.</p>
            <p>In case of 
            <i>failure</i>of a remote service – due to a network problem or simply because of the unreliability or untrustability of the agent that promised the resource – an exception handling
            mechanism will send a resource discovery query 
            <i>on the fly</i>to recover a faulty peer and the actual state of the run represented, in semantic jargon, by the 
            <i>current continuation</i>.</p>
            <p>We also envisage to design a 
            <i>run-time</i>distributed virtual machine, built on top of a virtual or hardware machine, in order to scale-up from local to distributed computations and to fit with the distributed
            nature of an overlay network computer. Communication between agent computers will be performed through a 
            <i>logic bus</i>, using Web technologies, like 
            <i>SOAP</i>or 
            <i>AJAX</i>protocols, or a combination of 
            <i>Java</i>-based 
            <i>JNI</i>+
            <i>RMI</i>-protocols, or 
            <i>.NET</i>, 
            <i>XPCOM</i>, 
            <i>D-BUS</i>, 
            <i>OLE</i>bus protocols, or even by enriching the 
            <i>Arigatoni</i>protocol suite with an 
            <i>ad hoc</i>control-flow and data-flow protocol, and permitting to use it directly inside 
            <i>Ivonne</i>.</p>
            <p>The 
            <i>Ivonne</i>language can be both interpreted and compiled. In the latter case we envisage the design of an intermediate low-level distributed assembler language in which 
            <i>Ivonne</i>could be compiled. The intermediate machine code will recast the assembler pseudo code</p>
            <p noindent="true">
              <tt>move R0 R1</tt>
            </p>
            <p noindent="true"><i>à la</i>Backus 
            <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid13" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>in</p>
            <p noindent="true">
              <tt>move dataR0 from ipR0:portR0 to ipR1:portR1</tt>
            </p>
            <p noindent="true">where, of course, latency is an non-trivial issue, or the assembler pseudo code</p>
            <p noindent="true"><tt>op R0 R1 R2</tt>in</p>
            <p noindent="true">
              <tt>op on ipR0 with ipR0:portR0:dataR0 and ipR1:portR1:dataR1 and</tt>
            </p>
            <p noindent="true"><tt>stockin ipR2:portR2:dataR2</tt>.</p>
            <p noindent="true">Resuming, an 
            <i>overlay program</i>will be a smooth combination of an overlay network connectivity dealing with virtual organizations and discovery protocols, a computation of an algorithm resulting
            of the 
            <i>summa</i>of all algorithms running on different computer agents, and the coordination of all computer agents, made by an 
            <i>Ivonne</i>program.</p>
          </li>
        </simplelist>
        <li id="uid99">
          <p noindent="true"><b>Trust and security</b>. In order to work securely, the 
          <i>Arigatoni</i>overlay network computer needs to be able to offer the following guarantees to its components:</p>
          <simplelist>
            <li id="uid100">
              <p noindent="true">The communication between two agents must be secured;</p>
            </li>
            <li id="uid101">
              <p noindent="true">The role played by an agent (
              <i>i</i>.
              <i>e</i>. client 
              <i>AC</i>, servant 
              <i>AC</i>or 
              <i>AB</i>) must be certified by a third party trusted by the agents that communicate with this particular agent. A way to implement those constraints is to use 
              <i>PKI</i>certificates. A 
              <i>Certification Authority</i>delivers certificates, and couples of private and public keys for 
              <i>AC</i>s and 
              <i>AB</i>s which attest to their distinctive roles. The whole mechanisms involved by a 
              <i>PKI</i>are out of the scope of this research statement, but good use of 
              <i>PKI</i>s and an implementation compliant with 
              <i>RFC2743</i>can provide all the necessary security, namely the trustfulness on the identity of the peers, and the trustfulness of all the transmitted data, 
              <i>i</i>.
              <i>e</i>. secrecy, authenticity, and integrity;</p>
            </li>
            <li id="uid102">
              <p noindent="true">In addition to 
              <i>PKI</i>s, a more “liquid” trust model could be built, based on 
              <i>reputation</i>mechanisms. Reputation represents the amount of trust an agent in the overlay has in another agent based on its partial view. In a nutshell:</p>
              <simplelist>
                <li id="uid103">
                  <p noindent="true">Each agent maintains a reputation score for each agent he knows;</p>
                </li>
                <li id="uid104">
                  <p noindent="true">Each agent maintains a reputation score for each resource he serves;</p>
                </li>
                <li id="uid105">
                  <p noindent="true">Exchanges between agents update each other's scores dynamically;</p>
                </li>
                <li id="uid106">
                  <p noindent="true">Conflicts between two or many agents are resolved by the broker leaders of the colonies to which the agents belong;</p>
                </li>
                <li id="uid107">
                  <p noindent="true">The computation of the reputation score (a trust metrics) and the way agents exchange scores is left free to each single implementation.</p>
                </li>
              </simplelist>
            </li>
          </simplelist>
          <p>A last word on implementation issues of the 
          <i>Arigatoni</i>overlay network computer: it is well-known that two technical barriers are commonly used to block transmission over 
          <i>IP</i>network in overlays:</p>
          <simplelist>
            <li id="uid108">
              <p noindent="true"><i>Firewalls</i>to drop 
              <i>UDP</i>flows (usually considered as suspects);</p>
            </li>
            <li id="uid109">
              <p noindent="true"><i>NAT</i>techniques to mask to the outside world the real 
              <i>IP</i>addresses of inside hosts; a 
              <i>NAT</i>equipment changes the 
              <i>IP</i>source address when a packet 
              <i>goes to</i>outside, and it changes the 
              <i>IP</i>destination address when a packet 
              <i>comes from</i>outside.</p>
            </li>
          </simplelist>
          <p>The usage of these mechanisms is very frequent on the Internet and they are barriers that can prevent connections between 
          <i>inside</i>and 
          <i>outside</i>agents in 
          <i>Arigatoni</i>. The implementation of 
          <i>RFC3489</i>could be used to overcome such obstacles.</p>
        </li>
      </subsection>
    </subsection>
  </fondements>
  <domaine id="uid110">
    <bodyTitle>Application Domains</bodyTitle>
    <subsection id="uid111" level="1">
      <bodyTitle>Panorama</bodyTitle>
      <p>Because of its generality, our overlay network can target many applications. We would like to list a small list of useful programmable overlay networks case studies that can be considered as
      “LogNet Grand Challenges” to help potential readers understand the interest of our research program.</p>
      <simplelist>
        <li id="uid112">
          <p noindent="true">New distributed models of computation</p>
        </li>
        <li id="uid113">
          <p noindent="true">Overlay networks over mobile 
          <i>ad hoc</i>networks</p>
        </li>
        <li id="uid114">
          <p noindent="true">Reduce the digital divide</p>
        </li>
      </simplelist>
    </subsection>
    <subsection id="uid115" level="1">
      <bodyTitle>Potential applications</bodyTitle>
      <p noindent="true"><b>From large-scale computing machines to large-scale overlay network machines (John von Neumann was right after all).</b>This challenge is inspired by the seminal talk by John von Neumann,
      given in May 1946, “Principles of Large-Scale Computing Machines”, typesetted and reprinted in 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid14" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. At that time, “large-scale” meant the 
      <i>ENIAC</i>computer, 
      <i>i</i>.
      <i>e</i>., 17,468 vacuum tubes, 7,200 crystal diodes, 1,500 relays, 70,000 resistors, 10,000 capacitors, 5 million joints, 30 short tons, 2.4m x 0.9m x 30m, stored in a 167 m
      <span class="math"><sup>2</sup></span>room, and 150 kW to operate. Today, thanks to the Moore's law and to the Internet, “large scale” means “worldwide scale”, 
      <i>i</i>.
      <i>e</i>. the computer hardware is distributed in space and in time and must be negotiated before being used. The main inspirations of the programmable overlay network computer research's vein
      are still contained in that article.</p>
      <p>The term “von Neumann bottleneck” was coined by John Backus in his 1977 ACM Turing award lecture. Bottleneck refers to the fact that, since data and program are stored on the same support
      (the memory), the throughput (data transfer rate) between the CPU and the memory is very low. In current von Neumann architecture, the bottleneck is alleviated by using big cache memories.
      Since in overlay network computers the bus can be modeled by an Internet connection, the data transfer is still more critical than on a single processor machine. As such, we should probably
      look at new computer architectures, such as the Harvard one.</p>
      <p>Needless to say that the “icing on the cake`” will be to formalize this new distributed computational model and architecture, together with a formal proof of its Turing completeness
      statement!</p>
      <p noindent="true"><b>Developing a pedestrian/vehicular infrastructure based on an overlay network computer.</b>We plan to build an 
      <i>ad hoc</i>vehicular network infrastructure using the 
      <i>Arigatoni</i>overlay infrastructure. That network must enable efficient and transparent access to the resources of on-board and roadside agents. In such a scenario, commercial services and
      access to public information are available to vehicles transiting in specific areas where such information is broadcast by roadside wireless gateways or by other vehicles. Data retrieved can be
      stored on the on-board vehicle computer; then, they can be used and rebroadcast at a later time without the need of persistent connectivity. These new features will offer innovative functions
      and services, such as:</p>
      <simplelist>
        <li id="uid116">
          <p noindent="true">Distribution, from infrastructure to vehicle (
          <i>I2V</i>), and among vehicles (
          <i>V2V</i>), of safety and/or traffic-related information;</p>
        </li>
        <li id="uid117">
          <p noindent="true">Collection, from vehicles to infrastructures (
          <i>V2I</i>), of data useful to perform traffic management;</p>
        </li>
        <li id="uid118">
          <p noindent="true">Exchange of information between private vehicles and public transportation systems (buses, vehicles, road side equipments...) to support and, thus, foster inter-modality
          in urban areas;</p>
        </li>
        <li id="uid119">
          <p noindent="true">Distribution of real-time, updated information to enable dynamic navigation services.</p>
        </li>
      </simplelist>
      <p>In this scenario, vehicles/pedestrians play the role of agent computers, while Bus-stop stations equipped with 
      <i>IP</i>network, routing tables and 
      <i>WIFI</i>access point play the role of agent brokers; Buses play the role of mobile agent brokers, a sort of proxy of a unique bus-stop agent broker. Proxy load balancing policies are left to
      the bus headquarter (
      <i>HQ</i>). See, for more details, the 
      <i>Arigatoni</i>'s sub-project 
      <i>Ariwheels</i>.</p>
      <p noindent="true"><b>Programming services for the new mesh overlay network in the Campus STIC of Sophia Antipolis.</b>The future Campus STIC, grouping EPU, UNSA, Eurecom, CNRS, and INRIA will be ready in one
      year. It will be equipped with a 
      <i>WIFI</i>network infrastructure implementing 802.11a/b/g protocols, with potential evolution to 802.11n protocol. The main objectives of such an underlay network are to offer 
      <i>IP</i>connection to all of the Campus “citizens”: the network must guarantee the respect of French laws concerning public network connections (
      <i>décret 2006-358 sur l'offre de connexion au public loi 2006-64</i>). To do this, it would be suitable that all users get identified using, 
      <i>e</i>.
      <i>g</i>., using the “pin” code of the student/employee-card. The infrastructure mainly targets Internet access for all. The Campus STIC 
      <i>WIFI</i>underlay network could be an unique opportunity to have a real testbed into which we could put our programmable overlay to the test. 
      <i>Arigatoni</i>and 
      <i>Ariwheels</i>could represent the overlay network infrastructure to offer 
      <i>much more</i>than simply an Internet connection: the LogNet vision can provide a list of interesting high-level semantic (on demand) services, and a plausible way to implement it.</p>
      <p noindent="true"><b>Reducing the</b><i><b>Digital Divide</b></i><b>[Sources Wikipedia].</b>The digital divide is the troubling gap between those who use computers and the Internet and those who do not. The term digital divide had a moving target: at first,
      it meant the ownership of a computer. Later, it meant access to the Internet. Most recently it centers on broadband access. In modern usage, the term also means more than just access to
      hardware, it also refers to the imbalance that exists amongst groups of society regarding their ability to use information technology.</p>
      <p>The digital divide tends to focus on access to hardware, access to the Internet. The writer Lisa J. Servon argued in 2002 that the digital divide “is a symptom of a larger and more complex
      problem – the problem of persistent poverty and inequality”. The four major components that contribute to the digital divide are “socioeconomic status, with income, educational level, and race
      among other factors associated with technological attainment”.</p>
      <p>One area of significant focus was 
      <i>school computer access</i>; in the 1990s, rich schools were much more likely to provide their students with regular computer access. In the late 1990s, rich schools were much more likely to
      have Internet access. In the context of schools, which have constantly been involved in the discussion of the divide, current formulations of the divide focus more on how (and whether)
      computers are used by students, and less on whether there are computers or Internet connections.</p>
      <p>The USA E-rate program (officially the Schools and Libraries Program of the Universal Service Fund), authorized in 1996 and implemented in 1997, directly addressed the technology gap between
      rich and poor schools by allocating money from telecommunications taxes to poor schools without technology resources. Although the program faced criticism and controversy in its methods of
      disbursement, it did provide over 100,000 schools with additional computing resources and Internet connectivity.</p>
      <p>Recently, discussions regarding the digital divide in school access have broadened to include technology-related skills and training in addition to basic access to computers and Internet
      access. An interesting example is that, in the North of Italy, the town of Pordenone, 50,000 inhabitants, will be equipped with public local 
      <i>WIFI</i>LAN (
      <i>e</i>.
      <i>g</i>. see the declaration of the Major, in Italian, 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://it.youtube.com/watch?v=zBTnkEnXTlc" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>it.
      <allowbreak/>youtube.
      <allowbreak/>com/
      <allowbreak/>watch?v=zBTnkEnXTlc</ref>). Our vision could contribute to reducing the digital divide in our society, and, more contextually, in the future Campus STIC.</p>
    </subsection>
  </domaine>
  <logiciels id="uid120">
    <bodyTitle>Software</bodyTitle>
    <subsection id="uid121" level="1">
      <bodyTitle>Ariwheels</bodyTitle>
      <participants>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
          <moreinfo>contact for the 
          <i>Ariwheels</i>simulator</moreinfo>
        </person>
        <person key="mascotte-2007-idm304854251264">
          <firstname>Claudio</firstname>
          <lastname>Casetti</lastname>
          <moreinfo>Politecnico di Torino, Italy</moreinfo>
        </person>
        <person key="PASUSERID">
          <firstname>Diego</firstname>
          <lastname>Borsetti</lastname>
          <moreinfo>Politecnico di Torino, Italy</moreinfo>
        </person>
        <person key="lognet-2009-idm468886189392">
          <firstname>Carla-Fabiana</firstname>
          <lastname>Chiasserini</lastname>
          <moreinfo>Politecnico di Torino, Italy</moreinfo>
        </person>
        <person key="PASUSERID">
          <firstname>Diego</firstname>
          <lastname>Malandrino</lastname>
          <moreinfo>Politecnico di Torino, Italy, contact for the 
          <i>Ariwheels</i>client</moreinfo>
        </person>
      </participants>
      <p><i>Ariwheels</i>is an infomobility solution for urban environments, with access points deployed at both bus stops (forming thus a wired backbone) and inside the buses themselves. Such a network
      is meant to provide connectivity and services to the users of the public transport system, allowing them to exchange services, resources and information through their mobile devices. 
      <i>Ariwheels</i>is both:</p>
      <simplelist>
        <li id="uid122">
          <p noindent="true">a protocol, based on 
          <i>Arigatoni</i>and the publish/subscribe paradigm;</p>
        </li>
        <li id="uid123">
          <p noindent="true">a set of applications, implementing the protocol on the different types of nodes;</p>
        </li>
        <li id="uid124">
          <p noindent="true">a simulator, written in OMNET++ and recently ported to the ns2 simulator.</p>
        </li>
      </simplelist>
      <p>We implemented 
      <i>Ariwheels</i>within the Omnet++ simulator, coding the overlay part and exploiting the existing wireless underlay network modules. In the underlay, we used IEEE 802.11 at the MAC layer and
      the DYMO routing protocol (an AODV-like reactive routing protocol). We tested the performance of 
      <i>Ariwheels</i>in a vehicular environment. We used a realistic mobility model generated by the simulator VanetMobiSim, whose output (mobility traces) was fed to the Omnet++ simulator. Vehicles
      travel in a 1 km
      <span class="math"><sup>2</sup></span>city section over a set of urban roads, which include several road intersections regulated by traffic lights or stop signs. In particular, we adopted the IDM-IM microscopic car-following
      model  
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid15" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, which allows us to reproduce real-world traffic dynamics as queues
      of vehicles decelerating and/or coming to a full stop near crowded intersections.</p>
      <p><i>Ariwheels</i>is designed for the scenario of urban public transportation. In such a scenario, a significant number of users equipped with mobile devices spends significant amounts of time at
      the bus stops or inside the bus themselves. The basic idea of 
      <i>Ariwheels</i>is to exploit this situation to let the users exchange data or services - more generally: resources - through their mobile devices. 
      <i>Ariwheels</i>is based on the 802.11 wireless LAN protocols. Therefore, its infrastructure is mostly made of access points, deployed at bus stops, forming a backbone; and on the buses
      themselves, thus with an intermittent connection to the backbone. 
      <i>Ariwheels</i>have four kinds of functional units, namely agents, brokers, mobile brokers, and proxies. The agent is a software running on the user's device. It will run in user space and
      unprivileged mode, in order to require no additional configuration or permissions. Using appropriate sensing and probing mechanisms, the agent will look for a Broker. Once found one, it
      performs the registration, which includes sending a list of the resources the agent has to offer and the request of the resources the agent needs. The broker is a program, running on a mid- or
      high-end device. There must be (at least) one broker in each L2 network belonging to the 
      <i>Ariwheels</i>system. The Broker performs four main duties: advertise its presence and the resources available through it; receive, elaborate and acknowledge the registration requests coming
      from the Agents; receive and (try to) answer the resource request coming from the Agents; manage feedback and reputation. Mobile brokers are brokers with an intermittent connection to the rest
      of the network. A typical example is a bus equipped with a wireless access point, connecting - when possible - to the infrastructure, deployed at some stops. Mobile brokers are associated with
      a fixed broker. As soon as this broker becomes available (
      <i>i</i>.
      <i>e</i>. the mobile broker can hear its Hello messages), the mobile broker sends it one or more Dump messages, containing its routing table. Proxies are the way 
      <i>Ariwheels</i>copes with the need to access information outside the colony. The following basic principles hold: brokers only store information about their own colony; brokers are the only
      entity storing information.</p>
      <p>See the web page 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/members/Luigi.Liquori/ARIGATONI/Ariwheels.htm" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>www-sop.
      <allowbreak/>inria.
      <allowbreak/>fr/
      <allowbreak/>members/
      <allowbreak/>Luigi.
      <allowbreak/>Liquori/
      <allowbreak/>ARIGATONI/
      <allowbreak/>Ariwheels.
      <allowbreak/>htm</ref>and 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://arigtt.altervista.org" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>arigtt.
      <allowbreak/>altervista.
      <allowbreak/>org</ref>.</p>
    </subsection>
    <subsection id="uid125" level="1">
      <bodyTitle>Arigatoni simulator</bodyTitle>
      <participants>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
          <moreinfo>contact</moreinfo>
        </person>
        <person key="PASUSERID">
          <firstname>Raphael</firstname>
          <lastname>Chand</lastname>
          <moreinfo>Université de Geneva, Switzerland</moreinfo>
        </person>
      </participants>
      <object id="uid126">
        <table>
          <tr>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/Simulateur-Arigatoni.jpg" xylemeAttach="6" xlink:href="IMG/Simulateur-Arigatoni" type="float" width="192.1487pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
          </tr>
        </table>
        <caption>The 
        <i>Arigatoni</i>simulator</caption>
      </object>
      <p>We have implemented in C++ (
      <span class="math"><img align="bottom" width="10" height="3" src="math_image_10.png" xylemeAttach="18" border="0" alt="Im10 $\#8764 $"/></span>2.5K lines of code) the Resource Discovery Algorithm and the Virtual Intermittent Protocol of the Arigatoni Overlay Network. The simulator was used to measure the load when we issued 
      <span class="math"><hi rend="it">n</hi></span>service requests at Global Computers chosen uniformly at random. Each request contained a certain number of instances of one service, also chosen uniformly at random. Each service
      request was then handled by the Resource Discovery mechanism of Arigatoni networks.</p>
    </subsection>
    <subsection id="uid127" level="1">
      <bodyTitle>BabelChord simulator</bodyTitle>
      <participants>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
          <moreinfo>contact</moreinfo>
        </person>
      </participants>
      <p>We have conducted some simulations of the BabelChord protocol 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid16" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. The simulator, written in Python, works in two phases. First, a
      Babelchord topology is created, with the following properties: (i) a fixed network size (the number of nodes) 
      <span class="math"><hi rend="it">N</hi></span>, (ii) a fixed number of floors denoted 
      <span class="math"><hi rend="it">F</hi></span>, (iii) a fixed global 
      <i>connectivity</i>, 
      <i>i</i>.
      <i>e</i>., the number of floors each node belongs to, denoted 
      <span class="math"><hi rend="it">C</hi></span>. As a consequence: (i) The nodes are uniformly dispatched among the floors, 
      <i>i</i>.
      <i>e</i>., each node belongs to 
      <span class="math"><hi rend="it">C</hi></span>floors uniformly chosen among the set of floors. (ii) Each resource provided by nodes is present at 
      <span class="math"><hi rend="it">C</hi></span>floors. (iii) The average lookup length within one given floor is 
      <span class="math">log((
      <hi rend="it">N</hi>×
      <hi rend="it">C</hi>)/
      <hi rend="it">F</hi>)/2</span>.</p>
      <p>The second time, the simulator computes the number of hops required to reach one of the nodes storing one of the keys of a particular resource. Results are given for different values of 
      <span class="math"><hi rend="it">N</hi></span>, 
      <span class="math"><hi rend="it">F</hi></span>, and 
      <span class="math"><hi rend="it">C</hi></span>. Simulations show that only 5% of synapses made of 2 (resp. 3, 5, 10) floors connections in the whole node population is enough to achieve more than 50% (resp. 60%, 80%, 95%) of
      exhaustive lookups in the Babelchord network.</p>
    </subsection>
    <subsection id="uid128" level="1">
      <bodyTitle>Synapse simulator</bodyTitle>
      <participants>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
          <moreinfo>contact</moreinfo>
        </person>
      </participants>
      <p>To better capture its relevance, we have conducted some intensive simulations of the Synapse approach 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid17" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. The simulator, written in Python, follows a discrete time approach.
      First, an initial topology is created, with a specified number of synapses, each having a specified different degree. Then, some discovery queries are sent. At each discrete time step, a
      message sent at the previous step is received by its destination (next routing step for the sought key). This simulator takes churn into account; at each time step, some events affect the
      network: some new nodes join the network, some existing nodes leave it. This simulator has been used to have a better and deep understanding of Synapse-like architectures, interconnecting
      structured overlay networks in a simple ways: routing latency and communication overhead while changing the input parameters (number of nodes, synapses, degree of synapses, level of churn), see
      see 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/lognet/synapse/pysynapse/pysynapse.zip" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>www-sop.
      <allowbreak/>inria.
      <allowbreak/>fr/
      <allowbreak/>lognet/
      <allowbreak/>synapse/
      <allowbreak/>pysynapse/
      <allowbreak/>pysynapse.
      <allowbreak/>zip</ref>.</p>
    </subsection>
    <subsection id="uid129" level="1">
      <bodyTitle>Synapse client</bodyTitle>
      <participants>
        <person key="oasis-2008-idm355833861312">
          <firstname>Laurent</firstname>
          <lastname>Vanni</lastname>
          <moreinfo>contact</moreinfo>
        </person>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
        </person>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
        </person>
        <person key="lognet-2009-idm468886176688">
          <firstname>Vincenzo</firstname>
          <lastname>Ciancaglini</lastname>
        </person>
      </participants>
      <p>In order to test our Synapse protocol 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid17" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>on real platforms, we have initially developed JSynapse, a Java
      software prototype, which uses the Java RMI standard for communication between nodes, and whose purpose is to capture the very essence of our Synapse protocol. It is a flexible and
      ready-to-be-plugged library which can interconnect any type of overlay networks. In particular, JSynapse fully implements a Chord-based inter-overlay network. It was designed to be a
      lightweight and easy-to-extend software. We also provided some practical classes which help in automating the generation of the inter-overlay network and the testing of specific scenarios. We
      have experimented with JSynapse on the Grid'5000 platform connecting more than 20 clusters on 9 different sites. Again, Chord was used as the intra-overlay protocol.</p>
      <p>We used one cluster located at Sophia Antipolis, France. The 
      <tt>Helios</tt>cluster consists of 56 quad-core AMD Opteron 275 processors linked by a gigabit Ethernet connection. The created Synapse network was first made up of up to 50 processors
      uniformly distributed among 3 Chord intra-overlays. Then, still on the same cluster, as nodes are quad-core, we deployed up to 3 logical nodes by processor, thus creating a 150 nodes overlay
      network, nodes being dispatched uniformly over 6 overlays. During the deployment, overlays were progressively bridged by synapses (the degree of which was always 2).</p>
      <p>We give a proof of concept and show the viability of the Synapse approach while confirming results obtained by the simulation. We also focus on the metrics affecting the user (satisfaction
      ratio and time to get a response). Once his request was sent, a user waits only for 1 second before closing the channels opened to receive responses. If no response was received after 1 second,
      the query is considered as not satisfied, see 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/lognet/synapse/jSynapse/index.html" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>www-sop.
      <allowbreak/>inria.
      <allowbreak/>fr/
      <allowbreak/>lognet/
      <allowbreak/>synapse/
      <allowbreak/>jSynapse/
      <allowbreak/>index.
      <allowbreak/>html</ref>.</p>
    </subsection>
    <subsection id="uid130" level="1">
      <bodyTitle>Open Synapse client</bodyTitle>
      <participants>
        <person key="lognet-2009-idm468886170528">
          <firstname>Bojan</firstname>
          <lastname>Marinkovic</lastname>
          <moreinfo>contact</moreinfo>
        </person>
      </participants>
      <p>Opensynapse is an open source implementation of 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid17" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. It is available for free under the GNU GPL. This implemetation is
      based on Open Chord (v. 1.0.5) - an open source implementation of the Chord distributed hash table implementation by Distributed and Mobile Systems Group Lehrstuhl fuer Praktische Informatik
      Universitaet Bamberg. 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/lognet/synapse/open-synapse/index.html" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>www-sop.
      <allowbreak/>inria.
      <allowbreak/>fr/
      <allowbreak/>lognet/
      <allowbreak/>synapse/
      <allowbreak/>open-synapse/
      <allowbreak/>index.
      <allowbreak/>html</ref>.</p>
      <p>Opensynapse is implemented on top of an arbitrary number of overlay networks. Inter-networking can be built on top of Synapse in a very efficient way. Synapse is based on co-located nodes
      playing a role that is reminiscent of neural synapses. The current implementation of Opensynapse in this precise case interconnects many Chord overlay networks. The features of Opensynapse
      are:</p>
      <simplelist>
        <li id="uid131">
          <p noindent="true">Stores any serializable Java object within a set of distributed hash tables (dhts).</p>
        </li>
        <li id="uid132">
          <p noindent="true">Facilitates configurable replication of entries in the dht.</p>
        </li>
        <li id="uid133">
          <p noindent="true">Currently provides two (proprietary) protocols for communication:</p>
          <simplelist>
            <li id="uid134">
              <p noindent="true">Local method calls: This protocol can be used to create a dht within one Java Virtual Machine for testing and visualization purposes.</p>
            </li>
            <li id="uid135">
              <p noindent="true">Java Sockets: This protocol creates a dht distributed over different nodes (JVMs).</p>
            </li>
          </simplelist>
        </li>
      </simplelist>
      <p>The new client currently can interconnect an arbitrary number of Chord networks. This implementation follows the notation presented in 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid16" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, and so, each new Chord network is called a 
      <i>Floor</i>. Regarding the 
      <tt>open-chord</tt>implementation, some new classes were implemented, such as 
      <tt>Floor</tt>or 
      <tt>MyFloor</tt>. The rest of the code is changed only to be compatible with the new data structure, that References and Entries are specific for a particular floor. Major changes were made in
      the main classes 
      <tt>NodeImpl</tt>and 
      <tt>ChordImpl</tt>, as well in the communication part, in form of specific proxy classes: 
      <tt>SocketProxy</tt>with 
      <tt>RequestHandler</tt>and 
      <tt>ThreadProxy</tt>with 
      <tt>ThreadEndpoint</tt>.</p>
      <p>Following the idea that every node is potentially a neural synapse, the decision was made not to implement a full object-oriented extension of the classes, but only to change the 
      <tt>open-chord</tt>implementation, because the new classes which should extend the old ones would have almost the same code as the old ones with the only novelties being the calls to these
      altered structures. So, in this case we do not have a real full object-oriented extension, we just deal with some sort of siblings classes.</p>
    </subsection>
    <subsection id="uid136" level="1">
      <bodyTitle>Husky interpreter</bodyTitle>
      <participants>
        <person key="lognet-2009-idm468886164368">
          <firstname>Marthe</firstname>
          <lastname>Bonamy</lastname>
          <moreinfo>contact</moreinfo>
        </person>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
        </person>
      </participants>
      <object id="uid137">
        <table>
          <tr>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/husky.jpg" xylemeAttach="7" xlink:href="IMG/husky" type="float" scale=".3" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
          </tr>
        </table>
        <caption>Launching the Husky interpreter</caption>
      </object>
      <p>Husky is a variableless language based on lambda calculus and term rewriting systems. Husky is based on the version 1.1 of 
      <i>Snake</i>
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid18" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. It was completely rewritten in CAML by Marthe Bonamy, ENSL (new
      parser, new syntactic constructions, like, 
      <i>e</i>.
      <i>g</i>., guards, anti-patterns, anti-expressions, exceptions and parametrized pattern matching). In 
      <i>Husky</i>all the keywords of the language are ASCII-symbols. It could be useful to teach basic algorithms and pattern-matching to childrens.</p>
    </subsection>
    <subsection id="uid138" level="1">
      <bodyTitle>myTransport Gui</bodyTitle>
      <participants>
        <person key="oasis-2008-idm355833861312">
          <firstname>Laurent</firstname>
          <lastname>Vanni</lastname>
          <moreinfo>contact</moreinfo>
        </person>
        <person key="lognet-2009-idm468886176688">
          <firstname>Vincenzo</firstname>
          <lastname>Ciancaglini</lastname>
        </person>
      </participants>
      <object id="uid139">
        <table>
          <tr>
            <td>
              <ressource xmlns:xlink="http://www.w3.org/1999/xlink" aux="IMG/mytransport.jpg" xylemeAttach="8" xlink:href="IMG/mytransport" type="float" width="341.6013pt" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest" media="WEB"/>
            </td>
          </tr>
        </table>
        <caption>myTransport on the Nokia N800 Internet tablet</caption>
      </object>
      <p>myTransport is a GUI built on top of the Synapse protocol and network. Its purpose is to be a proof of concept of the future service of infomobility to be available in the myMed social
      Network, see Figure 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#uid139" location="intern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. The GUI is written in Java and it is fully functional in the Nokia N800
      internet tablet devices.</p>
    </subsection>
    <subsection id="uid140" level="1">
      <bodyTitle>“Perinet” site of the GIR Maralpin</bodyTitle>
      <participants>
        <person key="lognet-2009-idm468886161296">
          <firstname>Luc</firstname>
          <lastname>Marongiu</lastname>
          <moreinfo>contact</moreinfo>
        </person>
        <person key="lognet-2009-idm468886158208">
          <firstname>Alexis</firstname>
          <lastname>Paoleschi</lastname>
        </person>
      </participants>
      <p>We design completely, using the Content Management Systems JOOMLA, the “Perinet” site of the GIR Maralpin 
      <i>Groupe Interdisciplinaire de Réflexion sur les traversées sud alpines et l'aménagement du territoire Maralpin</i>. Hundreds of pages of this site are currently visited.</p>
    </subsection>
  </logiciels>
  <resultats id="uid141">
    <bodyTitle>New Results</bodyTitle>
    <subsection id="uid142" level="1">
      <bodyTitle>Babelchord, a DHT's tower</bodyTitle>
      <participants>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
        </person>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
        </person>
        <person key="lognet-2008-idm279446248480">
          <firstname>Francesco</firstname>
          <lastname>Bongiovanni</lastname>
        </person>
      </participants>
      <p>A significant part of today's Internet traffic is generated by peer-to-peer (
      <i>P2P</i>) applications, used originally for file sharing, and more recently for real-time multimedia communications and live media streaming.</p>
      <p>Distributed hash tables (
      <i>DHT</i>s) or “structured overlay networks” have gained momentum in the last few years as the breaking technology to implement scalable, robust and efficient Internet applications. 
      <i>DHT</i>s provide a lookup service similar to a hash table: (key, value) pairs are stored in the DHT, and any participating node can efficiently retrieve the value associated with a given
      key. The responsibility for maintaining the mapping from names to values is distributed among the nodes, in such a way that a change in the set of participants causes a minimal amount of
      disruption. This allows 
      <i>DHT</i>s to scale to extremely large numbers of nodes and to handle continual node arrivals, departures, and failures.</p>
      <p>Chord 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid19" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>is one of the simplest protocols addressing key lookup in a
      distributed hash table: the only operation that Chord supports is that given a key it route onto a node which is supposed to host the entry (key,value). Chord adapts efficiently as nodes join
      and leave the system. Theoretical analysis and simulations showed that the Chord protocol scales up logarithmically with the number of nodes. In Chord, every node can join and leave the system
      without any peer negotiation, even though this feature can be implemented at the application layer. Chord uses consistent hashing in order to map keys and nodes' addresses, hosting the
      distributed table, to the same logical address space. All the peers use a unique hash function, which is the only way to map physical addresses and keys to a single logical address space. Peers
      can join the Chord just by sending a message to any node belonging to the Chord overlay. No reputation mechanism is required to accept, reject, or reward peers that are more reliable or more
      virtuous than others. Merging two Chord rings together is a costly operation because of the induced message complexity and the substantial time the distributed finger tables need to stabilize.
      Both of the rings need to know their relative hash functions and have to decide which ring will absorb the other, the latter point being critical because of the politics and security reliance.
      We propose to connect smaller Chord networks in an unstructured way via special nodes playing the role of 
      <i>neural synapses</i>.</p>
      <p>Schematically, the main features of Babelchord are:</p>
      <p noindent="true"><b>Routing over SW/HW-Barriers.</b>Namely, the ability to route queries through different, unrelated, 
      <i>DHT</i>s (possibly separated by firewalls) by “crossing floors”. A peer “on the border” of a firewall can bridge two overlays (having two different hash functions) that were not meant to
      communicate with each other unless one wants to merge one floor into the other (operation with a complexity linear in the number of nodes). The possibility to implement strong or weak security
      requirements makes Babelchord suitable for employment in Internet applications where software or social barriers are an important issue to deal with.</p>
      <p noindent="true"><b>Social-based.</b>Every peer has data structures recording peers and floors which are more “attractive” than others. A “hot” node is a node which is stable (alive) and which is responsible
      for managing a large number of (keys-values) in all hosted 
      <i>DHT</i>s. A “hot” floor is a floor responsible for a high number of successful lookups. Following a personal “good deal” strategy, a peer can decide to invite a hot node on a given floor it
      belongs to, or to join a hot floor, or even create from scratch a new floor (and then invite some hot nodes), or accept/decline an invitation to join a hot floor. This social-behavior makes the
      Babelchord network topology to change dynamically. As observed in other 
      <i>P2P</i>protocols, like 
      <i>Bittorrent</i>, peers with similar characteristics are more willing to group together on a private floor and thus will eventually improve their overall communications quality. Finally, the
      “good deal” strategy is geared up to be further enhanced with a reputation-system for nodes and floors.</p>
      <p noindent="true"><b>Neural-inspired.</b>Since every floor has a proper hash function, a Babelchord network can be thought of as a sort of 
      <i>meta overlay network</i>or 
      <i>meta-DHT</i>, where inter-floor connections take place via crossroad nodes, a sort of neural synapses, without sharing a global knowledge of the hash functions and without a time consuming
      floor merging. The more synapses you have, the higher the possibility of having successful routing is.</p>
      <p>Because of the aforementioned original features, the following are examples of applications for which Babelchord can provide good groundwork (in addition, of course, to all genuine
      Chord-based applications, like cooperative mirroring, time-shared storage, distributed indexes and large-scale combinatorial search).</p>
      <p noindent="true"><b>Anti Internet censorship applications.</b>Internet censorship is the control or the suppression of the publishing or accessing information on the Internet. Many applications and networks
      have been recently developed in order to bypass the censorship: among the many we recall Psiphon (
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://psiphon.ca" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>psiphon.
      <allowbreak/>ca</ref>), Tor (
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.torproject.org" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
      <allowbreak/>www.
      <allowbreak/>torproject.
      <allowbreak/>org</ref>), and many others. Babelchord can support such applications by taking advantage of intra-floor routing in order to bypass software barriers.</p>
      <p noindent="true"><b>Fully Distributed social-networks applications.</b>Social-networks are emerging as one of the Web 2.0 applications. Famous social networks, such as Facebook or LinkedIn are based on a
      client-server architecture; very often those sites are down for maintenance. Babelchord could represent a scalable and reliable alternative to decentralize key search and data storage.</p>
      <p noindent="true"><b>Large-scale brain model and simulations.</b>(Via a distributed, neural-based, network.) As well explained by R.D. DeGroot (Project founded by KNAW, Netherlands), supercomputers exist now
      with raw computational powers exceeding that of a human brain. Technological and production advances will soon place such computing power within the hands of cognitive and medical neuroscience
      research groups. For the first time it will be possible to execute brain-scale simulations of cognitive and pharmacological processes over millions and then billions of neurons - even at the
      biological model level. Babelchord could help modeling as a meta-overlay network for the human brain.</p>
    </subsection>
    <subsection id="uid143" level="1">
      <bodyTitle>Synapse, interconnecting heterogeneous overlay networks</bodyTitle>
      <participants>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
        </person>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
        </person>
        <person key="oasis-2008-idm355833861312">
          <firstname>Laurent</firstname>
          <lastname>Vanni</lastname>
        </person>
        <person key="lognet-2008-idm279446248480">
          <firstname>Francesco</firstname>
          <lastname>Bongiovanni</lastname>
        </person>
        <person key="lognet-2009-idm468886176688">
          <firstname>Vincenzo</firstname>
          <lastname>Ciancaglini</lastname>
        </person>
        <person key="lognet-2009-idm468886170528">
          <firstname>Bojan</firstname>
          <lastname>Marinkovic</lastname>
        </person>
      </participants>
      <p>We investigate Synapse 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid17" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>, a scalable protocol for information retrieval over the
      inter-connection of heterogeneous overlay networks. Applications of top of Synapse see those intra-overlay networks as a unique inter-overlay network.</p>
      <p>Scalability in Synapse is achieved via co-located nodes, 
      <i>i</i>.
      <i>e</i>. nodes that are part of multiple overlay networks at the same time. Co-located nodes, playing the role of 
      <i>neural synapses</i>and connected to several overlay networks, give a larger search area and provide alternative routing.</p>
      <p>Synapse can either work with “open” overlays adapting their protocol to synapse interconnection requirements, or with “closed” overlays that will not accept any change to their protocol.
      Built-in primitives to deal with social networking give an incentive for nodes cooperation. Results from simulation and experiments show that Synapse is scalable, with a communication and state
      overhead scaling similarly as the networks interconnected. thanks to alternate routing paths, Synapse also gives a practical solution to network partitions. We precisely capture the behavior of
      traditional metrics of overlay networks within Synapse and present results from simulations as well as some actual experiments of a client prototype on the Grid'5000 platform. The prototype
      developed implements the Synapse protocol in the particular case of the inter-connection of many Chord overlay networks.</p>
      <p>The inter-connection of overlay networks has been recently identified as a promising model to cope with today's Internet issues such as scalability, resource discovery, failure recovery or
      routing efficiency, in particular in the context of information retrieval. Some recent researches have focused on the design of mechanisms for building bridges between heterogeneous overlay
      networks for the purpose of improving cooperation between networks that have different routing mechanisms, logical topologies and maintenance policies. However, more comprehensive approaches of
      such inter-connections for information retrieval and both quantitative and experimental studies of its key metrics, such as satisfaction rate or routing length, are still missing.</p>
      <p>Many disparate overlay networks may not only simultaneously co-exist in the Internet but also compete for the same resources on shared nodes and underlying network links. One of the problems
      of the overlay networking area is how heterogeneous overlay networks may 
      <i>interact</i>and 
      <i>cooperate</i>with each other. Overlay networks are heterogeneous and basically unable to cooperate each other in an effortless way, without merging, an operation which is very costly since
      it not scalable and not suitable in many cases for security reasons. However, in many situations, distinct overlay networks could take advantage of cooperating for many purposes: collective
      performance enhancement, larger shared information, better resistance to loss of connectivity (network partitions), improved routing performance in terms of delay, throughput and packets loss,
      by, for instance, cooperative forwarding of flows.</p>
      <p>As a basic example, let us consider two distant databases. One node of the first database stores one 
      <span class="math">(
      <hi rend="it">k</hi>
      <hi rend="it">e</hi>
      <hi rend="it">y</hi>, 
      <hi rend="it">v</hi>
      <hi rend="it">a</hi>
      <hi rend="it">l</hi>
      <hi rend="it">u</hi>
      <hi rend="it">e</hi>)</span>pair which is searched by a node of the second one. Without network cooperation those two nodes will never communicate together. As another example, we have an
      overlay network where a number of nodes got isolated by an overlay network failure, leading to a partition: if some or all of those nodes can be reached via an alternative overlay network, than
      the partition “could” be recovered via an alternative routing.</p>
      <p>In the context of large scale information retrieval, several overlays may want to offer an aggregation of their information/data to their potential common users without losing control of it.
      Imagine two companies wishing to share or aggregate information contained in their distributed databases, obviously while keeping their proprietary routing and their exclusive right to update
      it. Finally, in terms of fault-tolerance, cooperation can increase the availability of the system, if one overlay becomes unavailable the global network will only undergo partial failure
      as other distinct resources will be usable.</p>
      <p>We consider the tradeoff of having one 
      <i>vs.</i>many overlays as a conflict without a cause: having a single global overlay has many obvious advantages and is the 
      <i>de facto</i>most natural solution, but it appears unrealistic in the actual setting. In some optimistic case, different overlays are suitable for collaboration by opening their proprietary
      protocols in order to build an open standard; in many other pessimistic cases, this opening is simply unrealistic for many different reasons (backward compatibility, security, commercial,
      practical, etc.). As such, studying protocols to interconnect collaborative (or competitive) overlay networks is an interesting research vein.</p>
      <p>The main contribution of thisresearch vein is to introduce, simulate and experiment with 
      <i>Synapse</i>, a scalable protocol for information retrieval over the inter-connection of heterogeneous overlay networks. The protocol is based on co-located nodes, also called 
      <i>synapses</i>, serving as low-cost natural candidates for inter-overlay bridges. In the simplest case (where overlays to be interconnected are ready to adapt their protocols to the
      requirements of interconnection), every message received by a co-located node can be forwarded to other overlays the node belongs to. In other words, upon receipt of a search query, in addition
      to its forwarding to the next hop in the current overlay (according to their routing policy), the node can possibly start a new search, according to some given strategy, in some or all other
      overlay networks it belongs to. This obviously implies to providing a Time-To-Live value and detection of already processed queries, to avoid infinite loop in the network, as in unstructured
      peer-to-peer systems.</p>
      <p>We also study interconnection policies as the explicit possibility to rely on 
      <i>social</i>based strategies to build these bridges between distinct overlays; nodes can invite or can be invited.</p>
      <p>In case of concurrent overlay networks, inter-overlay routing becomes harder, as intra-overlays are provided as some black boxes: a 
      <i>control</i>overlay-network made of co-located nodes maps one hashed key from one overlay into the original key that, in turn, will be hashed and routed in other overlays in which the
      co-located node belongs to. This extra structure is unavoidable to route queries along closed overlays and to prevent routing loops.</p>
      <p>Our experiments and simulations show that a small number of well-connected synapses is sufficient in order to achieve almost exhaustive searches in a “synapsed” network of structured overlay
      networks. We believe that Synapse can give an answer to circumventing network partitions; the key points being that: 
      <span class="math">(
      <hi rend="it">i</hi>)</span>several logical links for one node leads to as many alternative physical routes through these overlay, and 
      <span class="math">(
      <hi rend="it">i</hi>
      <hi rend="it">i</hi>)</span>a synapse can retrieve keys from overlays that it doesn't even know simply by forwarding their query to another synapse that, in turn, is better connected. Those
      features are achieved in Synapse at the cost of some additional data structures and in an orthogonal way to ordinary techniques of caching and replication. Moreover, being a synapse can allow
      for the retrieval of extra information from many other overlays even if we are not connected with.</p>
    </subsection>
    <subsection id="uid144" level="1">
      <bodyTitle>DHT formal specification</bodyTitle>
      <participants>
        <person key="PASUSERID">
          <firstname>Bernard</firstname>
          <lastname>Serpette</lastname>
        </person>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
        </person>
      </participants>
      <p>We have begun a formal specification associated to a 
      <i>PiNet</i>implementation, of a 
      <i>DHT</i>(Distributed Hash Table) oriented network. The specification is done via a relation on network states (small step semantics). A network state is the set of all individuals network
      nodes states. A node state consists of a, possibly sorted, set of neighbors, 
      <i>i</i>.
      <i>e</i>. the nodes known by a specific node, a local memory and a queue of messages received by the node to be executed. The semantics describe the behavior of incoming messages in each nodes.
      The specificity of the formalized 
      <i>DHT</i>are:</p>
      <p><span class="math">(
      <hi rend="it">i</hi>)</span>as in Chord, the path found between any two nodes of the network has a length which is in 
      <span class="math"><img align="middle" width="61" height="13" src="math_image_11.png" xylemeAttach="19" border="0" alt="Im11 ${\#119978 (Log(n))}$"/></span>, where 
      <span class="math"><hi rend="it">n</hi></span>is the number of nodes of the network; 
      <span class="math">(
      <hi rend="it">i</hi>
      <hi rend="it">i</hi>)</span>the graph induced by the neighbors is symmetric, 
      <i>i</i>.
      <i>e</i>. if a node 
      <span class="math"><hi rend="it">a</hi></span>can communicate with a node 
      <span class="math"><hi rend="it">b</hi></span>, then 
      <span class="math"><hi rend="it">b</hi></span>can communicate with 
      <span class="math"><hi rend="it">a</hi></span>. This fact is generally ensured by the transport layer (
      <i>TCP</i>, 
      <i>UDP</i>...) and thus the associated improvement (path lengths are divided by two) comes at a low price; 
      <span class="math">(
      <hi rend="it">i</hi>
      <hi rend="it">i</hi>
      <hi rend="it">i</hi>)</span>the dynamic nature of such network, 
      <i>i</i>.
      <i>e</i>. the fact that nodes can join and leave the network, requires to readjust the neighbors of some nodes. This readjustment is called stabilization. In contrast to Chord, where
      stabilization is done via a periodic background process which is hard to tune, our stabilization is done during the routing of messages and thus 1) does not make any administrative charge when
      the network is sleeping 2) uses only few words in already existing packets and so has a very limited impact to the average network latency.</p>
      <p>Following a formal general specification of such networks, we have developed a java simulator, coupled to a real implementation intended to catch the exact precise behavior of several
      topologies used in P2P systems.</p>
    </subsection>
    <subsection id="uid145" level="1">
      <bodyTitle>Resource discovery and Self-stabilizing in Tree-bases P2P systems</bodyTitle>
      <participants>
        <person key="graal-2006-idm329937212304">
          <firstname>Cédric</firstname>
          <lastname>Tedeschi</lastname>
        </person>
        <person key="PASUSERID">
          <firstname>Eddy</firstname>
          <lastname>Caron</lastname>
          <moreinfo>EPI GRAAL INRIA</moreinfo>
        </person>
        <person key="PASUSERID">
          <firstname>Frédéric</firstname>
          <lastname>Desprez</lastname>
          <moreinfo>EPI GRAAL INRIA</moreinfo>
        </person>
        <person key="PASUSERID">
          <firstname>Franck</firstname>
          <lastname>Petit</lastname>
          <moreinfo>EPI GRAAL INRIA</moreinfo>
        </person>
      </participants>
      <p>The Distributed Lexicographic Placement (DLP)-Table is a 
      <i>P2P</i>approach for the service discovery within large scale grids. It relies on a prefix tree structured overlay network. It provides load balancing, efficient mapping of nodes of the tree
      onto processors of the network and fault-tolerance mechanisms, formally proved to be self-stabilizing, 
      <i>i</i>.
      <i>e</i>. converging to a correct topology in a finite time starting from an arbitrary topology and memory state. It has been initially developed within the INRIA GRAAL project team.</p>
      <p>In collaboration with Eddy Caron, Frédéric Desprez and Franck Petit of GRAAL, we have written a chapter to appear in the future book entitled “Handbook of Research on P2P and Grid Systems
      for Service-Oriented Computing: Models, Methodologies and Applications” and published by IGI Global 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid20" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>. This chapter gives a more 
      <i>popularizing</i>view of the system and its features.</p>
      <p>A journal paper about the stabilizing part of this architecture has been accepted for publication in Parallel Processing Letters 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid21" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
    </subsection>
    <subsection id="uid146" level="1">
      <bodyTitle>Intersection and Union Types à la Church</bodyTitle>
      <participants>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
        </person>
        <person key="PASUSERID">
          <firstname>Dan</firstname>
          <lastname>Dougherty</lastname>
        </person>
      </participants>
      <p>We studied an explicitly typed lambda calculus “à la Church” based on the union and intersection types discipline; this system is the counterpart of the standard type assignment calculus “à
      la Curry.” Our typed calculus enjoys Subject Reduction and confluence, and typed terms are strongly normalizing when the universal type is omitted. Moreover, both type checking and type
      reconstruction are decidable. In contrast to other typed calculi, a system with union types will fail to be “coherent” in the sense of Tannen, Coquand, Gunter, and Scedrov: different proofs of
      the same typing judgement will not necessarily have the same meaning. In response, we introduce a decidable notion of equality on type-assignment derivations inspired by the equational theory
      of bicartesian-closed categories 
      <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#lognet-2009-bid22" location="biblio" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest"/>.</p>
      <p>We address the problem of designing a 
      <span class="math"><img width="11" height="13" align="bottom" border="0" src="../../images/img_lambda.png" alt="$ \lambda$"/></span>-calculus 
      <i>à la</i>Church corresponding to Curry-style type assignment to an untyped 
      <span class="math"><img width="11" height="13" align="bottom" border="0" src="../../images/img_lambda.png" alt="$ \lambda$"/></span>-calculus with intersection and union types. In particular, we define a typed language such that its relationship with the intersection-union type assignment system fulfills the
      following 
      <i>desiderata</i>: (i) typed and type assignment derivations are 
      <i>isomorphic</i>, 
      <i>i</i>.
      <i>e</i>., the application of an 
      <i>erasing function</i>on all typed terms and contexts (in a typed derivation judgment) produces a derivable type assignment derivation with the same structure, and every type assignment
      derivation is obtained from a typed one with the same structure by applying the same erasure; (ii) type checking and type reconstruction are decidable; (iii) reduction on typed terms has the
      same fundamental nice properties of reduction on terms receiving a type in the type-assignment system, namely confluence, preservation of typing under reduction, and strong normalization of
      terms typable without the universal type 
      <span class="math"><img width="12" height="12" align="bottom" border="0" src="../../images/img_omega.png" alt="$ \omega$"/></span>.</p>
    </subsection>
    <subsection id="uid147" level="1">
      <bodyTitle>Dealing with uncertain knowledge in Logical Frameworks</bodyTitle>
      <participants>
        <person key="lognet-2008-idm279446242320">
          <firstname>Petar</firstname>
          <lastname>Maksimovic</lastname>
        </person>
        <person key="mascotte-2006-idm166461066608">
          <firstname>Luigi</firstname>
          <lastname>Liquori</lastname>
        </person>
      </participants>
      <p>The main goal of this research vein is the design and prototype implementation of logical frameworks in which it would be possible to smoothly encode various probabilistic logics, and other
      logics considered in general to be exotic, such as Modal, Program, Linear or Relevance logics. It may also involve the formalization and possible creation of a certified SAT checker for one or
      more probabilistic logics within the proof assistant Coq.</p>
      <p>The theoretical background behind this involves:</p>
      <simplelist>
        <li id="uid148">
          <p noindent="true">typed lambda calculi, namely the cube of Barendregt,</p>
        </li>
        <li id="uid149">
          <p noindent="true">the Edinburgh Logical Framework, and</p>
        </li>
        <li id="uid150">
          <p noindent="true">the proof assistant Coq.</p>
        </li>
      </simplelist>
      <p>At this point, formalization of one of the probabilistic logics, namely 
      <span class="math"><hi rend="it">L</hi><hi rend="it">P</hi><hi rend="it">P</hi><sub>2</sub></span>, in the proof assistant Coq, is well under way. In this probabilistic logic, one can make statements of the form "the probability of A is at least s", where 
      <span class="math"><hi rend="it">A</hi></span>is a classical formula, and 
      <span class="math"><hi rend="it">s</hi></span>is a rational number from the interval 
      <span class="math">[0, 1]</span>, but with formulas themselves still remaining either true or false. The syntax, the semantics, and a complete axiomatization with appropriate inference rules
      have been encoded in Coq, and the soundness of the system (the validity of axioms with respect to the semantics and the preservation of validity by the inference rules) has been proven
      formally. The formal proof of completeness and an analysis of possible formalization of a SAT checker for this logic are in progress, and we expect sufficient progress for appropriate
      publication in the first half of 2010.</p>
    </subsection>
  </resultats>
  <international id="uid151">
    <bodyTitle>Other Grants and Activities</bodyTitle>
    <subsection id="uid152" level="1">
      <bodyTitle>European Initiatives</bodyTitle>
      <subsection id="uid153" level="2">
        <bodyTitle>Interreg Alcotra: myMed, 2010-2012</bodyTitle>
        <participants>
          <person key="mascotte-2006-idm166461066608">
            <firstname>Luigi</firstname>
            <lastname>Liquori</lastname>
          </person>
          <person key="oasis-2008-idm355833861312">
            <firstname>Laurent</firstname>
            <lastname>Vanni</lastname>
          </person>
          <person key="lognet-2009-idm468886176688">
            <firstname>Vincenzo</firstname>
            <lastname>Ciancaglini</lastname>
          </person>
          <person key="mascotte-2007-idm304854251264">
            <firstname>Claudio</firstname>
            <lastname>Casetti</lastname>
          </person>
          <person key="lognet-2009-idm468886189392">
            <firstname>Carla-Fabiana</firstname>
            <lastname>Chiasserini</lastname>
          </person>
        </participants>
        <p>The Interreg Alcotra office has founded the three-year project 
        <i>myMed : un réseau informatique transfrontalier pour léchange de contenus dans un environnement fixe et mobile</i>. LogNet will head the project; other partners are Vulog PME, GIR Maralpin,
        Politecnico di Torino, Uni. Torino, Uni. Piemonte Orientale. The total budget 1380Keur (796Keur for l'INRIA) - the external founding is 932Keur (526Keur for l'INRIA). The founders are UE,
        PACA, CG06, PREF06, and INRIA, see 
        <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www-sop.inria.fr/mymed" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
        <allowbreak/>www-sop.
        <allowbreak/>inria.
        <allowbreak/>fr/
        <allowbreak/>mymed</ref>.</p>
      </subsection>
      <subsection id="uid154" level="2">
        <bodyTitle>FP6 FET Global Computing: IST AEOLUS, 2005-2009</bodyTitle>
        <participants>
          <person key="mascotte-2006-idm166461066608">
            <firstname>Luigi</firstname>
            <lastname>Liquori</lastname>
          </person>
          <person key="oasis-2008-idm355833861312">
            <firstname>Laurent</firstname>
            <lastname>Vanni</lastname>
          </person>
        </participants>
        <p><i>AEOLUS, Algorithmic principles for building efficient overlay computers</i>, in collaboration with 21 European universities and coordinated by University of Patras, Greece. LogNet
        participates in package 2 (Resource management) and in package 5 (Extending global computing to wireless users). See also LogNet highlights.</p>
      </subsection>
      <subsection id="uid155" level="2">
        <bodyTitle>FP6 TEMPUS DEUKS, 2007-2009</bodyTitle>
        <participants>
          <person key="mascotte-2006-idm166461066608">
            <firstname>Luigi</firstname>
            <lastname>Liquori</lastname>
          </person>
          <person key="lognet-2008-idm279446242320">
            <firstname>Petar</firstname>
            <lastname>Maksimovic</lastname>
          </person>
          <person key="lognet-2009-idm468886170528">
            <firstname>Bojan</firstname>
            <lastname>Marinkovic</lastname>
            <moreinfo>Math. Institute of Belgrade, Serbia</moreinfo>
          </person>
        </participants>
        <p><i>DEUKS, Doctoral School Towards European Knowledge Society</i>. The main aim of this Project, in collaboration with 6 European universities, is to promote the current European landscape of
        doctoral programmes in Serbia. Particularly, the Project will develop and implement a pilot Doctoral Programme according to the European innovative recommendations with comprehensive approach
        to information technologies, where foundational theories are fully integrated in a pragmatic engineering approach. LogNet is the head of the French chapter.</p>
      </subsection>
    </subsection>
  </international>
  <diffusion id="uid156">
    <bodyTitle>Dissemination</bodyTitle>
    <subsection id="uid157" level="1">
      <bodyTitle>Participation in committees and referees</bodyTitle>
      <simplelist>
        <li id="uid158">
          <p noindent="true">Luigi Liquori is member of the 
          <i>Commission de Spécialistes du jury CR2 INRIA Sophia Antipolis</i>.</p>
        </li>
        <li id="uid159">
          <p noindent="true">Luigi Liquori is PC member of the Sixth International Workshop on Hot Topics in Peer-to-Peer Systems HotP2P, 2010.</p>
        </li>
        <li id="uid160">
          <p noindent="true">Luigi Liquori is PC member of the SEMELS Workshop on Semantic Extensions to Middleware: Enabling Large Scale Knowledge Applications.</p>
        </li>
        <li id="uid161">
          <p noindent="true">Luigi Liquori is PC member of the 20th Tyrrhenian Workshop on Digital Communications "The Internet of Things".</p>
        </li>
        <li id="uid162">
          <p noindent="true">Luigi Liquori is PC member of 3rd Conference on Algebra and Coalgebra in Computer Science, CALCO 2009.</p>
        </li>
        <li id="uid163">
          <p noindent="true">Cédric Tedeschi is PC member of the Eleventh International Symposium on Stabilization, Safety, and Security of Distributed Systems, SSS 2009.</p>
        </li>
        <li id="uid164">
          <p noindent="true">Cédric Tedeschi is PC member of the International Conference on Computational Science, ICCS 2009.</p>
        </li>
        <li id="uid165">
          <p noindent="true">Cédric Tedeschi is PC member of the the International Conference on Computational Science, ICCS 2010.</p>
        </li>
      </simplelist>
      <p>Moreover Luigi Liquori was a referee for the IEEE Symposium on Computers and Communications, the Journal of Logic and Computations, and the International Conference on Computational Science,
      ICCS 2009.</p>
    </subsection>
    <subsection id="uid166" level="1">
      <bodyTitle>Teaching and Meeting organizations</bodyTitle>
      <simplelist>
        <li id="uid167">
          <p noindent="true">Luigi Liquori gave a course on Overlay and P2P networks at the DEUKS TEMPUS, Foundations of Information Technologies summer school June 14-27, 2009, Novi Sad, Serbia.</p>
        </li>
        <li id="uid168">
          <p noindent="true">Luigi Liquori gave a 9 TD course on Peer to peer, Master Ubinet UNSA.</p>
        </li>
        <li id="uid169">
          <p noindent="true">Luigi Liquori organized the DEUKS TEMPUS third training meeting in Sophia Antipolis.</p>
        </li>
      </simplelist>
    </subsection>
    <subsection id="uid170" level="1">
      <bodyTitle>Spare presentations</bodyTitle>
      <simplelist>
        <li id="uid171">
          <p noindent="true">Luigi Liquori presented the LogNet team to the ENS Lyon's students.</p>
        </li>
        <li id="uid172">
          <p noindent="true">Luigi Liquori presented the LogNet team to the Marseille Master's students.</p>
        </li>
        <li id="uid173">
          <p noindent="true">Bojan Marinkovic presented the Babelchord work at the DEUKS third training meeting in Sophia Antipolis.</p>
        </li>
        <li id="uid174">
          <p noindent="true">Cédric presented the BabelChord approach during a seminar on P2P systems at INRIA Sophia Antipolis.</p>
        </li>
      </simplelist>
    </subsection>
    <subsection id="uid175" level="1">
      <bodyTitle>Visitors</bodyTitle>
      <p noindent="true">
        <b>IN</b>
      </p>
      <simplelist>
        <li id="uid176">
          <p noindent="true">Giuseppe Persiano, full professor, U. Salerno, 1 month</p>
        </li>
        <li id="uid177">
          <p noindent="true">Alberto Trombetta, assistant professor, U. Insubria, 7 dd</p>
        </li>
      </simplelist>
      <p noindent="true">
        <b>OUT</b>
      </p>
      <p>Luigi Liquori visited the following sites:</p>
      <simplelist>
        <li id="uid178">
          <p noindent="true">Politecnico di Torino, multiple visits,</p>
        </li>
        <li id="uid179">
          <p noindent="true">Universitá ti Torino, multiple visits</p>
        </li>
        <li id="uid180">
          <p noindent="true">University of Novi Sad, Serbia, 15dd</p>
        </li>
        <li id="uid181">
          <p noindent="true">Mathematical Institute of the Serbian Academy of Sciences and Arts, Belgrade, 1dd</p>
        </li>
        <li id="uid182">
          <p noindent="true">Scientific Computing Laboratory, Institute of Physics Belgrade, 1dd</p>
        </li>
        <li id="uid183">
          <p noindent="true">INRIA Lille Europe, 1dd</p>
        </li>
      </simplelist>
      <p>Cédric Tedeschi visited the following sites:</p>
      <simplelist>
        <li id="uid184">
          <p noindent="true">INRIA Grenoble Rhône-Alpes, MOAIS Project, 1dd</p>
        </li>
        <li id="uid185">
          <p noindent="true">INRIA Rennes Bretagne Atlantique, PARIS Project, 1dd</p>
        </li>
        <li id="uid186">
          <p noindent="true">LIFC (Besancon), CARTOON Project, 1dd</p>
        </li>
      </simplelist>
    </subsection>
  </diffusion>
  <biblio id="bibliography" html="bibliography" numero="10" titre="Bibliography">
    <biblStruct id="lognet-2009-bid2" type="inproceedings" rend="refer" n="refercite:BCLV06" default="NO">
      <analytic>
        <title level="a">Arigatoni: Overlaying Internet via Low Level Network Protocols</title>
        <author>
          <persName>
            <foreName>D.</foreName>
            <surname>Benza</surname>
            <initial>D.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName>
            <foreName>M.</foreName>
            <surname>Vesin</surname>
            <initial>M.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">JVA, John Vincent Atanasoff International Symposium on Modern Computing</title>
        <imprint>
          <publisher>
            <orgName>IEEE</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2006</year>
          </dateStruct>
          <biblScope type="pages">82–91</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid1" type="incollection" rend="refer" n="refercite:BCCL08" default="NO">
      <analytic>
        <title level="a">Content Discovery in Heterogeneous Mobile Networks</title>
        <author>
          <persName>
            <foreName>D.</foreName>
            <surname>Borsetti</surname>
            <initial>D.</initial>
          </persName>
          <persName key="mascotte-2007-idm304854251264">
            <foreName>C.</foreName>
            <surname>Casetti</surname>
            <initial>C.</initial>
          </persName>
          <persName>
            <foreName>C.-F.</foreName>
            <surname>Chiasserini</surname>
            <initial>C.-F.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
        </author>
      </analytic>
      <monogr x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <editor role="editor">
          <persName>
            <foreName>E.</foreName>
            <surname>Hossain</surname>
            <initial>E.</initial>
          </persName>
        </editor>
        <title level="m">Heterogeneous Wireless Access Networks: Architectures and Protocols</title>
        <imprint>
          <publisher>
            <orgName>Springer-Verlag</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2008</year>
          </dateStruct>
          <biblScope type="pages">419–441</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid3" type="inproceedings" rend="refer" n="refercite:CCL06" default="NO">
      <analytic>
        <title level="a">Resource Discovery in the Arigatoni Overlay Network</title>
        <author>
          <persName key="mascotte-2006-idm166461030768">
            <foreName>R.</foreName>
            <surname>Chand</surname>
            <initial>R.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">I2CS, International Workshop on Innovative Internet Community Systems</title>
        <title level="s">Lecture Notes in Computer Science</title>
        <imprint>
          <publisher>
            <orgName>Springer-Verlag</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2006</year>
          </dateStruct>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid8" type="article" rend="refer" n="refercite:CCL08" default="NO">
      <analytic>
        <title level="a">Powerful resource discovery for Arigatoni overlay network</title>
        <author>
          <persName key="mascotte-2006-idm166461030768">
            <foreName>R.</foreName>
            <surname>Chand</surname>
            <initial>R.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="j">Future Generation Computer Systems</title>
        <imprint>
          <biblScope type="volume">1</biblScope>
          <biblScope type="number">21</biblScope>
          <dateStruct>
            <year full="yes">2008</year>
          </dateStruct>
          <biblScope type="pages">31–38</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid6" type="inproceedings" rend="refer" n="refercite:CLC07" default="NO">
      <analytic>
        <title level="a">Improving Resource Discovery in the Arigatoni Overlay Network</title>
        <author>
          <persName key="mascotte-2006-idm166461030768">
            <foreName>R.</foreName>
            <surname>Chand</surname>
            <initial>R.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">ARCS, International Conference on Architecture of Computing Systems</title>
        <title level="s">Lecture Notes in Computer Science</title>
        <imprint>
          <biblScope type="volume">4415</biblScope>
          <publisher>
            <orgName>Springer-Verlag</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2007</year>
          </dateStruct>
          <biblScope type="pages">98-111</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid7" type="article" rend="refer" n="refercite:CLC07b" default="NO">
      <analytic>
        <title level="a">Virtual Organizations in Arigatoni</title>
        <author>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461030768">
            <foreName>R.</foreName>
            <surname>Chand</surname>
            <initial>R.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="j">DCM, International Workshop on Developpment in Computational Models. Electr. Notes Theor. Comput. Sci.</title>
        <imprint>
          <biblScope type="volume">171</biblScope>
          <biblScope type="number">3</biblScope>
          <dateStruct>
            <year full="yes">2007</year>
          </dateStruct>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid0" type="inproceedings" rend="refer" n="refercite:LBCC08" default="NO">
      <analytic>
        <title level="a">An Overlay Architecture for Vehicular Networks</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName>
            <foreName>D.</foreName>
            <surname>Borsetti</surname>
            <initial>D.</initial>
          </persName>
          <persName key="mascotte-2007-idm304854251264">
            <foreName>C.</foreName>
            <surname>Casetti</surname>
            <initial>C.</initial>
          </persName>
          <persName>
            <foreName>C.-F.</foreName>
            <surname>Chiasserini</surname>
            <initial>C.-F.</initial>
          </persName>
        </author>
      </analytic>
      <monogr x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <title level="m">IFIP Networking, International Conference on Networking</title>
        <title level="s">Lecture Notes in Computer Science</title>
        <imprint>
          <biblScope type="volume">4982</biblScope>
          <publisher>
            <orgName>Springer-Verlag</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2008</year>
          </dateStruct>
          <biblScope type="pages">60–71</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid5" type="inproceedings" rend="refer" n="refercite:LC07b" default="NO">
      <analytic>
        <title level="a">Logical Networks: Towards Foundations for Programmable Overlay Networks and Overlay Computing Systems</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">TGC, Trustworthy Global Computing</title>
        <title level="s">Lecture Notes in Computer Science</title>
        <imprint>
          <biblScope type="volume">4912</biblScope>
          <publisher>
            <orgName>Springer-Verlag</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2007</year>
          </dateStruct>
          <biblScope type="pages">90–107</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid4" type="inproceedings" rend="refer" n="refercite:LC07a" default="NO">
      <analytic>
        <title level="a">Weaving Arigatoni with a Graph Topology</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">ADVCOMP, International Conference on Advanced Engineering Computing and Applications in Sciences</title>
        <imprint>
          <publisher>
            <orgName>IEEE Computer Society Press</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2007</year>
          </dateStruct>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid18" type="article" rend="refer" n="refercite:LS08c" default="NO">
      <analytic>
        <title level="a">iRho: An Imperative Rewriting-calculus</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName>
            <foreName>B. P.</foreName>
            <surname>Serpette</surname>
            <initial>B. P.</initial>
          </persName>
        </author>
      </analytic>
      <monogr x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <title level="j">MSCS, Mathematical Structures in Computer Science</title>
        <imprint>
          <biblScope type="volume">18</biblScope>
          <biblScope type="number">3</biblScope>
          <dateStruct>
            <year full="yes">2008</year>
          </dateStruct>
          <biblScope type="pages">467-500</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid24" type="article" rend="refer" n="refercite:LS08b" default="NO">
      <analytic>
        <title level="a">Extending FeatherTrait Java with Interfaces</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="logical-2006-idm356512353408">
            <foreName>A.</foreName>
            <surname>Spiwack</surname>
            <initial>A.</initial>
          </persName>
        </author>
      </analytic>
      <monogr x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <title level="j">TCS, Theoretical Computer Science</title>
        <imprint>
          <biblScope type="volume">398</biblScope>
          <biblScope type="number">1-3</biblScope>
          <dateStruct>
            <year full="yes">2008</year>
          </dateStruct>
          <biblScope type="pages">243–260</biblScope>
        </imprint>
      </monogr>
      <note type="bnote" place="unspecified" anchored="yes">Calculi, types and applications: Essays in honour of M. Coppo, M. Dezani-Ciancaglini and S. Ronchi Della Rocca</note>
    </biblStruct>
    <biblStruct id="lognet-2009-bid23" type="article" rend="refer" n="refercite:LS08a" default="NO">
      <analytic>
        <title level="a">FeatherTrait: A Modest Extension of Featherweight Java</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="logical-2006-idm356512353408">
            <foreName>A.</foreName>
            <surname>Spiwack</surname>
            <initial>A.</initial>
          </persName>
        </author>
      </analytic>
      <monogr x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <title level="j">TOPLAS, ACM Transaction on Programming Languages and Systems</title>
        <imprint>
          <biblScope type="volume">30</biblScope>
          <biblScope type="number">2</biblScope>
          <dateStruct>
            <year full="yes">2008</year>
          </dateStruct>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct dedoublkey="1951" id="lognet-2009-bid20" type="inbook" rend="year" n="cite:DLPTchapter09" default="NO">
      <analytic>
        <author>
          <persName key="graal-2006-idm329937269808">
            <foreName>E.</foreName>
            <surname>Caron</surname>
            <initial>E.</initial>
          </persName>
          <persName key="graal-2006-idm329937294144">
            <foreName>F.</foreName>
            <surname>Desprez</surname>
            <initial>F.</initial>
          </persName>
          <persName key="graal-2008-idm236822691792">
            <foreName>F.</foreName>
            <surname>Petit</surname>
            <initial>F.</initial>
          </persName>
          <persName key="graal-2006-idm329937212304">
            <foreName>C.</foreName>
            <surname>Tedeschi</surname>
            <initial>C.</initial>
          </persName>
        </author>
        <title level="a">DLPT: A P2P tool for Service Discovery in Grid Computing</title>
      </analytic>
      <monogr>
        <title level="m">Handbook of Research on P2P and Grid Systems for Service-Oriented Computing: Models, Methodologies and Applications</title>
        <editor role="editor">
          <persName>
            <foreName>N.</foreName>
            <surname>Antonopoulos</surname>
            <initial>N.</initial>
          </persName>
          <persName>
            <foreName>G.</foreName>
            <surname>Exarchakos</surname>
            <initial>G.</initial>
          </persName>
          <persName key="concha-2008-idm358651466288">
            <foreName>M.</foreName>
            <surname>Li</surname>
            <initial>M.</initial>
          </persName>
          <persName>
            <foreName>A.</foreName>
            <surname>Liotta</surname>
            <initial>A.</initial>
          </persName>
        </editor>
        <imprint>
          <publisher>
            <orgName>IGI Global</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2009</year>
          </dateStruct>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct dedoublkey="1413" id="lognet-2009-bid21" subtype="nonparu" type="article" rend="year" n="cite:CDPT10" default="NO">
      <analytic>
        <title level="a">Snap-Stabilizing Prefix Tree for Peer-to-Peer Systems</title>
        <author>
          <persName key="graal-2006-idm329937269808">
            <foreName>E.</foreName>
            <surname>Caron</surname>
            <initial>E.</initial>
          </persName>
          <persName key="graal-2006-idm329937294144">
            <foreName>F.</foreName>
            <surname>Desprez</surname>
            <initial>F.</initial>
          </persName>
          <persName key="graal-2008-idm236822691792">
            <foreName>F.</foreName>
            <surname>Petit</surname>
            <initial>F.</initial>
          </persName>
          <persName key="graal-2006-idm329937212304">
            <foreName>C.</foreName>
            <surname>Tedeschi</surname>
            <initial>C.</initial>
          </persName>
        </author>
      </analytic>
      <monogr id="rid01649" x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <idno type="issn">0129-6264</idno>
        <title level="j">Parallel Processing Letters</title>
        <imprint>
          <dateStruct>
            <month full="yes">jan</month>
            <year full="yes">2009</year>
          </dateStruct>
        </imprint>
      </monogr>
      <note type="bnote" place="unspecified" anchored="yes">To appear</note>
    </biblStruct>
    <biblStruct dedoublkey="2673" id="lognet-2009-bid16" type="inproceedings" rend="year" n="cite:LTB09" default="NO">
      <analytic>
        <title level="a">Babelchord: a social tower of DHT-based overlay networks</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="graal-2006-idm329937212304">
            <foreName>C.</foreName>
            <surname>Tedeschi</surname>
            <initial>C.</initial>
          </persName>
          <persName key="lognet-2008-idm279446248480">
            <foreName>F.</foreName>
            <surname>Bongiovanni</surname>
            <initial>F.</initial>
          </persName>
        </author>
      </analytic>
      <monogr x-editorial-board="yes" x-international-audience="yes" x-proceedings="yes">
        <title level="m">IEEE, ISCC</title>
        <imprint>
          <dateStruct>
            <year full="yes">2009</year>
          </dateStruct>
          <biblScope type="pages">307-312</biblScope>
        </imprint>
        <meeting id="cid94370">
          <title>IEEE Symposium on Computers and Communications</title>
          <num>14</num>
          <abbr type="sigle">ISCC</abbr>
        </meeting>
      </monogr>
    </biblStruct>
    <biblStruct dedoublkey="6087" id="lognet-2009-bid22" subtype="nonparu" type="unpublished" rend="year" n="cite:DL-TR" default="NO">
      <monogr x-editorial-board="no" x-international-audience="no" x-proceedings="no">
        <title level="m">Logic and computation in a lambda calculus with intersection and union types</title>
        <author>
          <persName>
            <foreName>D.</foreName>
            <surname>Dougherty</surname>
            <initial>D.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
        </author>
        <imprint>
          <dateStruct>
            <year full="yes">2009</year>
          </dateStruct>
        </imprint>
      </monogr>
      <note type="bnote" place="unspecified" anchored="yes">submitted</note>
    </biblStruct>
    <biblStruct dedoublkey="6152" id="lognet-2009-bid17" subtype="nonparu" type="unpublished" rend="year" n="cite:synapse-TR" default="NO">
      <monogr x-editorial-board="no" x-international-audience="no" x-proceedings="no">
        <title level="m">Synapse: A Scalable Protocol for Interconnecting Heterogeneous Overlay Networks</title>
        <author>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName key="graal-2006-idm329937212304">
            <foreName>C.</foreName>
            <surname>Tedeschi</surname>
            <initial>C.</initial>
          </persName>
          <persName key="oasis-2008-idm355833861312">
            <foreName>L.</foreName>
            <surname>Vanni</surname>
            <initial>L.</initial>
          </persName>
          <persName key="lognet-2008-idm279446248480">
            <foreName>F.</foreName>
            <surname>Bongiovanni</surname>
            <initial>F.</initial>
          </persName>
          <persName key="lognet-2009-idm468886176688">
            <foreName>V.</foreName>
            <surname>Ciancaglini</surname>
            <initial>V.</initial>
          </persName>
          <persName key="lognet-2009-idm468886170528">
            <foreName>B.</foreName>
            <surname>Marinkovic</surname>
            <initial>B.</initial>
          </persName>
        </author>
        <imprint>
          <dateStruct>
            <year full="yes">2009</year>
          </dateStruct>
        </imprint>
      </monogr>
      <note type="bnote" place="unspecified" anchored="yes">submitted</note>
    </biblStruct>
    <biblStruct id="lognet-2009-bid13" type="article" rend="foot" n="footcite:backus" default="NO">
      <identifiant type="doi" value="10.1145/320764.320766"/>
      <analytic>
        <title level="a">The IBM 701 Speedcoding System</title>
        <author>
          <persName>
            <foreName>J. W.</foreName>
            <surname>Backus</surname>
            <initial>J. W.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="j">J. ACM</title>
        <imprint>
          <biblScope type="volume">1</biblScope>
          <biblScope type="number">1</biblScope>
          <dateStruct>
            <year full="yes">1954</year>
          </dateStruct>
          <ref xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://doi.acm.org/10.1145/320764.320766" location="extern" xlink:type="simple" xlink:show="replace" xlink:actuate="onRequest">http://
          <allowbreak/>doi.
          <allowbreak/>acm.
          <allowbreak/>org/
          <allowbreak/>10.
          <allowbreak/>1145/
          <allowbreak/>320764.
          <allowbreak/>320766</ref>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid11" type="techreport" rend="foot" n="footcite:BCLVRR06" default="NO">
      <monogr>
        <title level="m">Arigatoni: Overlaying Internet via Low Level Network Protocols</title>
        <author>
          <persName>
            <foreName>D.</foreName>
            <surname>Benza</surname>
            <initial>D.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461072400">
            <foreName>M.</foreName>
            <surname>Cosnard</surname>
            <initial>M.</initial>
          </persName>
          <persName key="mascotte-2006-idm166461066608">
            <foreName>L.</foreName>
            <surname>Liquori</surname>
            <initial>L.</initial>
          </persName>
          <persName>
            <foreName>M.</foreName>
            <surname>Vesin</surname>
            <initial>M.</initial>
          </persName>
        </author>
        <imprint>
          <biblScope type="number">5805</biblScope>
          <publisher>
            <orgName type="institution">INRIA</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">2006</year>
          </dateStruct>
        </imprint>
      </monogr>
      <note type="typdoc" place="unspecified" anchored="yes">Technical report</note>
    </biblStruct>
    <biblStruct id="lognet-2009-bid10" type="incollection" rend="foot" n="footcite:EGI-98" default="NO">
      <analytic>
        <title level="a">Dynamic graph algorithms</title>
        <author>
          <persName>
            <foreName>D.</foreName>
            <surname>Eppstein</surname>
            <initial>D.</initial>
          </persName>
          <persName>
            <foreName>Z.</foreName>
            <surname>Galil</surname>
            <initial>Z.</initial>
          </persName>
          <persName>
            <foreName>G.</foreName>
            <surname>Italiano</surname>
            <initial>G.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">Handbook of Algorithms and Theory of Computation</title>
        <imprint>
          <biblScope type="chapter">22</biblScope>
          <publisher>
            <orgName>CRC Press</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">1998</year>
          </dateStruct>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid15" type="inproceedings" rend="foot" n="footcite:fiore07" default="NO">
      <analytic>
        <title level="a">Vehicular Mobility Simulation for VANETs</title>
        <author>
          <persName>
            <foreName>M.</foreName>
            <surname>Fiore</surname>
            <initial>M.</initial>
          </persName>
          <persName>
            <foreName>J.</foreName>
            <surname>Härri</surname>
            <initial>J.</initial>
          </persName>
          <persName>
            <foreName>F.</foreName>
            <surname>Filali</surname>
            <initial>F.</initial>
          </persName>
          <persName key="sosso2-2006-idm492987641056">
            <foreName>C.</foreName>
            <surname>Bonnet</surname>
            <initial>C.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">Annual Simulation Symposium</title>
        <imprint>
          <dateStruct>
            <year full="yes">2007</year>
          </dateStruct>
          <biblScope type="pages">301-309</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid9" type="inbook" rend="foot" n="footcite:Rapoport" default="NO">
      <analytic>
        <author>
          <persName>
            <foreName>A.</foreName>
            <surname>Rapoport</surname>
            <initial>A.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">Mathematical models of social interaction</title>
        <imprint>
          <biblScope type="volume">II</biblScope>
          <publisher>
            <orgName>John Wiley and Sons</orgName>
          </publisher>
          <dateStruct>
            <year full="yes">1963</year>
          </dateStruct>
          <biblScope type="pages">493–579</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid19" type="inproceedings" rend="foot" n="footcite:Chord" default="NO">
      <analytic>
        <title level="a">Chord: A Scalable Peer-to-Peer Lookup service for Internet Applications.</title>
        <author>
          <persName>
            <foreName>I.</foreName>
            <surname>Stoica</surname>
            <initial>I.</initial>
          </persName>
          <persName>
            <foreName>R.</foreName>
            <surname>Morris</surname>
            <initial>R.</initial>
          </persName>
          <persName>
            <foreName>D.</foreName>
            <surname>Karger</surname>
            <initial>D.</initial>
          </persName>
          <persName>
            <foreName>M.</foreName>
            <surname>Kaashoek</surname>
            <initial>M.</initial>
          </persName>
          <persName>
            <foreName>H.</foreName>
            <surname>Balakrishnan</surname>
            <initial>H.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="m">ACM SIGCOMM</title>
        <imprint>
          <dateStruct>
            <year full="yes">2001</year>
          </dateStruct>
          <biblScope type="pages">149-160</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid12" type="article" rend="foot" n="footcite:AH-05" default="NO">
      <analytic>
        <title level="a">YAWL: yet another workflow language</title>
        <author>
          <persName>
            <foreName>W. M. P.</foreName>
            <surname>van der Aalst</surname>
            <initial>W. M. P.</initial>
          </persName>
          <persName>
            <foreName>A. H. M.</foreName>
            <surname>ter Hofstede</surname>
            <initial>A. H. M.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="j">Information System</title>
        <imprint>
          <biblScope type="volume">30</biblScope>
          <biblScope type="number">4</biblScope>
          <dateStruct>
            <year full="yes">2005</year>
          </dateStruct>
          <biblScope type="pages">245-275</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
    <biblStruct id="lognet-2009-bid14" type="article" rend="foot" n="footcite:Neumann" default="NO">
      <analytic>
        <title level="a">The Principles of Large-Scale Computing Machines</title>
        <author>
          <persName>
            <foreName>J.</foreName>
            <surname>von Neumann</surname>
            <initial>J.</initial>
          </persName>
        </author>
      </analytic>
      <monogr>
        <title level="j">IEEE Ann. Hist. Comput.</title>
        <imprint>
          <biblScope type="volume">10</biblScope>
          <biblScope type="number">4</biblScope>
          <dateStruct>
            <year full="yes">1988</year>
          </dateStruct>
          <biblScope type="pages">243–256</biblScope>
        </imprint>
      </monogr>
    </biblStruct>
  </biblio>
</raweb>
