Damian Vicino

Juan Pablo Timpanaro

Isabelle Chrisment

Olivier Festor

Keywords: KAD, BitTorrent, DHT, P2P Architecture, Performance, Security KAD, BitTorrent, DHT, l'architecture P2P, performance, sécurité

BitTorrent is a fast, popular, P2P filesharing application with no search engine mapping keywords to contents. The trackerless approach uses a DHT based on Kademlia to look for sources when the SHA1 hash of the metadata of the content to transfer is known. However, this DHT implementation is exposed to several identified security issues. On the other hand, the KAD network uses a solid DHT implementation based also on Kademlia and developed for the eMule/amule P2P clients. The KAD DHT provides an extra level of indexation to map keywords to file identifiers that is used as search engine. We produced a hybrid implementation compatible with both P2P file sharing networks to have the KAD advantages on indexation and the BitTorrent speed for transfer without losing backward compatibility.

Introduction

Since the beginning of Internet one of the most popular uses has been the file sharing between a set of users.

In early days this was achieved in a client-server model (i.e. a ftp server could have all the files and users could retrieve the files as they need it). After the big expansion of internet worldwide the resources needed to provide services as ftp servers became too expensive and a new set of technologies for sharing files needed to be developed, the solutions were found in P2P models where the users transfer the files between them.

Three different approaches were used: pure P2P 1 where users never need to interact with a centralized resource (i.e. gnutella, freenet), statically centralized hybrid P2P where users transfer the files between each other but coordination between peers is decided by a central known resource (i.e. eDonkey2000) and dynamically centralized P2P where a small subset of selected peers work as coordinators, usually called supernodes (i.e. Kazaa).

Since different countries got different policies about copyright, censorship and content distribution, there was controversy about the technology and the means it provided for people doing illegal distribution of content. The immediate response from some countries to the legal conflict was to block nodes that were doing some illegal activity. This decision impacted the network efficiency for every content (legal or not). As legislation is different according to the countries, users in a place where the content was legal got affected by other country legislation since users are a worldwide community. Last few years P2P file sharing communities were prosecuted in some countries because users indexed copyrighted material for distribution taking the local government actions to censor or block the central index, disabling the whole index in some cases by a single country action, (i.e. Kazaa [START_REF]Metro-goldwyn-mayer v. grokster ltd[END_REF] [START_REF]Metro-goldwyn-mayer studios inc. v. grokster[END_REF]). The networks had to evolve into pure P2P to avoid been compromised by conflicts of few nodes. One popular approach was to use DHTs 2for indexing peers and sometimes files; the most widely deployed implantation is based on XOR metrics design and called Kademlia [START_REF] Maymounkov | Kademlia: A peer-to-peer information system based on the xor metric[END_REF].

Recent research in the two most popular file-sharing networks [START_REF] Timpanaro | When kad meets bittorrentbuilding a stronger p2p network[END_REF] pointed that quality of searching is better in eMule networks thanks to the KAD indexing network, a variant of Kademlia which has two levels of indexation and is more solid against known attacks than BitTorrent DHTs which only has one indexing level and less security measures implemented. On the other hand, the BitTorrent network provides a fast transfer protocol in terms of overheads and propagation times.

The objective of this work is to build an integrated software that merges together the benefices of KAD indexation with BitTorrent transport protocol without loosing compatibility with previous eMule and BitTorrent clients.

The report is organized as follow. In section 2, we introduce what a file-sharing service should provide and presents the Kademlia DHT, the ed2k network and BitTorrent protocol. In section 3, we give a survey of the technologies available to be used in our project. In section 4, we review the requirements for the project and define some use cases. In section 5, we explain some approaches that were evaluated before implementation. In section 6, we show the flow of messages in a simple download using original aMule client. In section 7, we define the changes that we proposed to achieve our goal and the expected flow of messages after our implementation. In section 8, we review the implementation details. In section 9, we explain a set of tests that were run in PlanetLab 3 with the new client and the results from those tests. In section 10, we enumerate some future work ideas. In the appendix, we provide a installation guide, a user guide, a troubleshooting for known issues and the documentation of the most relevant new classes implemented.

State of the art

File sharing service

File sharing service is composed of 3 steps: (1) a user searches for files that would suit his/her needs using keywords; (2) he/she selects which files from the search results he/she would like to obtain and ask for the list of sources; (3) at last he/she asks to the sources for the content of the files.

In client/server approach, the first step was done using some site like www.yahoo. com, www.google.com, www.download.com, etc. or links provided using email, irc or another channel. The second step was provided by the server who has the content itself or a secondary server providing a portal with the index of the content and resources location. The third step, the transfer, was done using ftp, http or some similar protocol.

There are different approaches in P2P with slightly variants. We will focus on just two technologies, eMule and BitTorrent.

For the first step, the eMule KAD network has a first level index that maps keywords to file identifiers while BitTorrent uses web sites that publish info-files containing the metadata needed for second step (pretty much like the client/server approach). The second step for eMule is handled by a second level index in KAD while BitTorrent uses some implementation of DHT that maps file metadata to sources. Both networks can also use centralized coordination servers 4 in some cases, these kind of use comes from backward compatibility before the use of DHTs for indexing. In the last step, each client uses it own protocol for transfer.

Kademlia for indexing

The theory

Kademlia is a general purpose P2P DHT based on XOR metrics [START_REF] Maymounkov | Kademlia: A peer-to-peer information system based on the xor metric[END_REF]. In Kademlia every node has a 160 bit identifier randomly generated before joining the network. The distance between two nodes is defined as the XOR operation between two nodes' id. This operation in a fully populated tree of 160 bits is equivalent to the height of the smallest tree that contains both nodes.

For each i between 0 to 160, every <ip, port, id> triplets of nodes that are in distance 2 i and 2 i+1 from itself are saved and called K-buckets. When a new node joins the network, it looks for itself and starts taking note of the closest nodes. It keeps record of the k closest known nodes(usually k = 20). These known nodes are used to route query messages to the other nodes.

To store information in Kademlia, a 160 bits key is created for this information and the closest nodes to the key will store data. To locate the stored data, the closest nodes to the key identifying the data should be found. To locate a node by its identifier you should ask the closest nodes you know, they will reply with the closest nodes they know and you iterate with the new closest nodes to the target until you reach the target node.

Transfer protocols 6

The eMule implementation -KAD

The eMule network uses a variation of Kademlia called KAD where the size of the keys is 128 bits (since eMule uses MD4 hashes as identifiers for files to keep compatibility with ed2k networks) [START_REF] Mysicka | Reverse engineering of emule-an analysis of the implementation of kademlia in emule[END_REF]. KAD indexes has two levels to provide the whole file-sharing service process. The first level has an index that maps MD4 hashes of keywords to file identifiers (MD4 of the file contents) and the second level maps those file identifiers to the sources that share the file. In previous research, we have shown that KAD has a more reliable Kademlia implementation in terms of security than BitTorrent DHTs [START_REF] Timpanaro | Bittorrent's mainline dht security assessment[END_REF].

The BitTorrent implementations -Mainline and Vuze

There are two Kademlia implementations for BitTorrent's DHT: Mainline or Vuze, both incompatible between them. Both implementations uses 160 bits keys as indexes since BitTorrent applies uses as key the sha1 hash of the info-file, which contains the metadata of the indexed content, also known as the info-hash. The BitTorrent DHT implementations have only one level of indexation that maps content identifiers to peers, that is why they need to access to the web or other channels to find the files identifiers to fulfill the first step in a file sharing service (as in section 2.1). The infohash is used in place of file content's hash since BitTorrent transfers can handle several files as one single content.

Transfer protocols

ed2k

The ed2k protocol was developed originally for the eDonkey2000 network. It uses two queues for transfers: one to handle uploads and the other one to handle downloads. When a peer asks for a file to another peer, the peer providing the file replies saying how many users asked before and waits until finishing with those previous requests to start the transfer of the requested piece of data. Some improvements related to peer exchange and credit systems were implemented in some alternative clients (i.e. eMule [START_REF] Kulbak | The emule protocol specification[END_REF]). The original eDonkey2000 client was shut down in 2006 because of legal actions [START_REF]Metro-goldwyn-mayer v. grokster ltd[END_REF] [START_REF]Metro-goldwyn-mayer studios inc. v. grokster[END_REF] and eMule took the central place in the scene when talking about standardization and protocol changes.

BitTorrent

BitTorrent users sharing the same content are grouped together into what is called "a swarm". The participants of a swarm follow a set of rules defined to maximize availability of content and redistribute the cost of upload and download between them. [START_REF] Cohen | Incentives build robustness in bittorrent[END_REF] 3 Survey of available technologies

eMule

The eMule client is an eDonkey2000 open source alternative for windows started in 2002. Since it release, eMule was expanding the original ed2k protocol with new nonofficial functionalities like peer exchange, credit systems and protocol obfuscation. [START_REF] Kulbak | The emule protocol specification[END_REF] When legal prosecution started against the servers providing indexation of ed2k, eMule developed the KAD DHT based in Kademlia with 2 level index, one mapping file identifiers to peers, and one to map keywords to file identifiers so search for content can be done inside the network. [START_REF] Mysicka | Reverse engineering of emule-an analysis of the implementation of kademlia in emule[END_REF] In 2006 legal actions shut down eDonkey2000 [START_REF]Metro-goldwyn-mayer v. grokster ltd[END_REF] [2] and eMule became the unofficial owner of ed2k protocol. The KAD guidelines for implementation are very strict and the network is not allowed to index anything but files shared. The source code is available under GPLv2+ in VC++ and can be obtained from http://www.emule-project.com.

aMule

The aMule client is a fork of xMule, an open source alternative multi-platform implementation compatible with eMule. It is the second most used client with active development these days. The architecture originally fully monolithic has been replaced with a modular one using ECP 5 to separate the core functionality from other components that provide different kinds of user interfaces. There is still the chance to get a monolithic build from same code.

The aMule components are:

• aMule Daemon: handles all the file-sharing work and can be connected to any user interface provided by aMule from a local or remote origin.

• aMule Remote GUI: similar to eMule GUI and implemented using wxWidgets library.

• aMule Web: a service that provides user interface using HTTP protocol, it's based on PHP code so it can be easily extended by webdevelopers.

• aMule Cmd: a simple user interface for command line.

• aMule: the monolithic version that resembles a Daemon + Remote Gui squashed together in a single binary.

The source code is available under GPLv2+ in C++ with wxWidgets library and can be obtained from http://www.amule.org.

BitTorrent

BitTorrent is the official client originally developed by Bram Cohen and the protocol specification is publicly available in BitTorrent site (http://www.bittorrent.

Vuze (formerly azureus)

Vuze is one of the most deployed alternatives to BitTorrent client, their developers had implemented a lot of extra features that are not in BitTorrent standard, also they provide a easy way to use interface for third party plug-ins. The Kademlia based DHT used by Vuze is not Mainline, neither it is compatible to it. The source code developed in Java is under a hybrid license having some components under proprietary and some under GPLv3, the open source pieces of code can be downloaded from http://dev. vuze.com/

rTorrent

The rTorrent is a command line BitTorrent client whose core is also released as libtorrent (rakshasa) and used to implement other clients. The source code is available under GPLv2+ in C++ and can be obtained from http://libtorrent.rakshasa.no.

libtorrent-rasterbar

LibTorrent-rasterbar is a library implementing the BitTorrent protocol and a set of related tools needed to build a full client in few lines of code, including session management, plugins management, DHT access, metadata exchange and persistence of the content. The build from source code offers the option to build Python and Ruby bindings. The source code is available under BSD license in C++ and can be obtained from http://www.rasterbar.com/products/libtorrent/. We can observe that Vuze and BitTorrent clients need to search by keyword in the web or another external resource to retrive the info-file or the info-hash. After they obtain the info-file or info-hash they lookup for a swarm to join in a tracker or a DHT. When looking in a DHT most the clients can use Mainline DHT, Vuze uses it own DHT implementation or Mainline up to configuration. When client find a swarm sharing the content needed, it will join and get the content. It's important to notice that the swarm can be joinned by any client using BitTorrent protocol, the only resource that is not shared between all of them is the DHT.

In the other side we got *Mule clients, they search by keyword in their DHT called KAD, then they ask for sources using again KAD. When a set of sources is obtained, *Mule client asks to every source for the metadata of the file and subscribes to the remote upload queue.

The difference in the order to obtain metadata is important, because it change assumptions in the protocols, i.e. BitTorrent info-file is unique metadata for a content, while the metadata for *Mule transfers can be as many as detected sources providing it. The new client appears as a bridge between networks, it can access full content on both sides. After downloading a file from one of the networks it provides it to the other one.

List of requirements

• hMule should be able to join KAD to search and publish content.

• hMule should be able to transfer content to other hMule clients using BitTorrent transfer protocol.

• hMule should be retrocompatible:

-It should be agnostic about transfer protocol when publishing content in KAD, meaning that a content should not have to be searched with different criterias depending of the transfer protocol to be used and KAD should return a valid result set for all kind of users.

-It should share the published files to aMule/eMule clients using ed2k transfer protocol.

-It should be able to join swarms with other BitTorrent clients.

Use cases 4.4.1 Request in hMule and hMule sources are provided by KAD

• Start a query in KAD with a keyword to get possible files.

• When KAD replies to the query, prompt the user to select the file to download.

Use cases 11

• Start a query in KAD with the selected file to get sources.

• For each source query source for metadata about the file.

if metadata includes an info-hash identifying the file as content in BitTorrent network, the download will be added to BitTorrent's transfer queues, a swarm will be joined using the peer providing the metadata as entry point.

add metadata to the ed2k queue.

Request in hMule and no hMule sources are provided by KAD

• Start a query in KAD with a keyword to get possible files.

• When KAD replies to the query, prompt the user to select the file to download.

• Start a query in KAD with the selected file to get sources.

• For each source query source for metadata about the file.

add metadata to the ed2k queue.

• When transfer is complete, since no BitTorrent metadata was retrieved it should be generated and stored for future transfers.

Request in hMule from BitTorrent network having info-file or info-hash

• User introduces the info-file or info-hash.

• Download using torrent protocol, trackers and DHT if needed.

• When transfer is complete, compute KAD metadata and keywords.

• Publish in KAD.

Publish new content from hMule

• Compute BitTorrent info-file of the new content to be able to reply to BitTorrent requests for info-file from peer that only have the info-hash.

• Compute KAD metadata and keywords.

• Publish in KAD.

5 Possible approaches evaluated 12

Possible approaches evaluated

To fulfill the requirements of the project several popular available technologies were studied and different approaches were evaluated to combine them into a solution for hMule implementation.

Expanding a BitTorrent client to use KAD

Using Vuze we could have implemented the indexing on KAD as a plugin for the search engine. When searching it should have to ask KAD first index level for files, then KAD should be asked for sources providing those files and finally transfer the file.

The first problem with this approach is that KAD identifiers are smaller (128 bits) than BitTorrent's info-file which has no fixed length and can take several bytes. This issue happened to the developers of the BitTorrent DHTs too, that why they indexed using info-hashes of 160 bits. Knowing the metadata hash and sources providing the content, the sources can be asked for a copy of the full info-file to start the download. In the other side KAD reply has only 128 bits and there is no direct translation to compute an info-hash without lossing backward compatibility with KAD or BitTorrent.

To overcome these problems we thought to include the info-hash as a keyword when publishing the file, but some clients drop keywords or overrides them when other publication for the same file arrives (probably from an old client that doesn't provide this information). As we (at least until our client becomes popular enough) are a small minority in the network, there is a high probability that our info-hash gets eclipsed by other clients providing the same content.

The solution we came up for the issue matching KAD file identifiers to info-files was to implement a new protocol message that has a 128 bits identifier. The peers that share the file ask the info-file to clients identified as sources by KAD and if some client replies with the info-file, content transfer can be started using BitTorrent protocol.

This solution needs a new message and the implementation is not backward compatible to users using KAD right now since if we publish a content in KAD and we are the only client peer providing it, it will be available in index for all the *Mule users but will noone using an old client will be able to get the transfer. So using this approach only provides a shared index between networks that got garbage for both kind of users, those using BitTorrent can find transfers that only can be acquired using ed2k protocol and those using ed2k can find content that oly can be acquired using BtiTorrent protocol for transfers. This shows the need of ed2k protocol to get files when there is no BitTorrent sources, same to provide the content.

The implementation of ed2k protocol into the BitTorrent client is complex since there is no popular open source libraries providing it and should be stripped from some *Mule. We could try to filter results in our client so only those available for BitTorrent transfer appear, but filtering is complex because can not be done without asking to each source of each result what application version got installed. Asking to all sources of all results is overkill and if the file is provided or not by a hybrid client cannot be registered in KAD for same reasons than 160 bits hashes couldn't, also the use is unfair to other users of KAD who will index content they can not access.

Moving the KAD source code from eMule to a BitTorrent client (Vuze or any other) is 5.2 Creating a hybrid client from the scratch using KAD, BitTorrent and ed2k libraries 13

possible since other clients using KAD already had the need for that, but extracting the ed2k transfer protocol and session components is really difficult since eMule is tightly coupled between these functionalities and it's main loop.

Creating a hybrid client from the scratch using KAD, BitTorrent and ed2k libraries

Both libraries for BitTorrent were well designed and useful, but the libraries to provide KAD and ed2k functionalities were not available for production or needed too much work to be extracted from original implementation as libraries.

Expanding an eMule client to support BitTorrent as transfer protocol

Libraries providing BitTorrent were evaluated and both of them provide a good start for a BitTorrent client. The KAD protocol is working in any eMule client and the glue to exchange 128 bits for 160 identifier can be coded as a libtorrent extension or hooked to some eMule operation when bootstraping downloads.

The library extension approach major benefit is it will be used by several clients and they will provide the mapping service. However since KAD is not provided in the library if those clients don't connect to KAD network, they will not be suggested as sources so none of them will be asked for the translation.

We also know that eMule client asks every new source added for metadata, we can take advantage of this extending the eMule protocol so in the reply they also come up with the info-hash we need.

Choosen approach

We decided to expand an eMule-compatible client to support BitTorrent as an alternative transfer protocol.

T

he technologies we used

• We use aMule as eMule-compatible client since our experimentation infrastructure is based on Linux and also because the aMule project has a more modular architecture than eMule.

• We use libtorrent-rasterbar to provide the BitTorrent protocol and the tools, it has a complete high level interface to handle sessions, individual torrents and peers, and also it has access to low level interfaces to do adjustments when needed. The implementation is based in widely known Boost libraries that makes it easily portable to other operating systems and it provides interfaces to develop extensions. Extentions providing Mainline DHT, metadata exchange between peers, uPNP and IPFilters are already provided by the library.

6 aMule message flow study of a file transfer 14

aMule message flow study of a file transfer

As explained before, aMule uses EC Protocol to provide user interfaces and core functionality as separate applications.

The full list of messages defined in the EC protocol can be found in ECCodes.abstract file that renders the ECCodes.h file in the build process.

There were 84 messages defined at the time this project started. To simplify we will focus on a small subset of messages that are needed to start the download of a file after searching it in KAD from keywords.

• EC_OP_KAD_START: the daemon starts the KAD service and look for peers.

• EC_OP_SEARCH_START: the daemon starts a search of keywords in some network. In our case the param EC_SEARCH_KAD and at least one keyword should be used.

• EC_OP_SEARCH_PROGRESS: asks to the daemon for progress in the search since the search operation is asynchronous.

• EC_OP_SEARCH_RESULTS: After a search was started, this message asks for the list of results matching the criteria so far, asking more than one time can give different results until progress is 100%.

• EC_OP_DOWNLOAD_SEARCH_RESULT: when user decides what file to download from the results list, this message tells the daemon to start the download of the selected file.

• EC_OP_DWLOAD_QUEUE: asks to the daemon the status of the files in the download queue to provide the user feedback.

The aMule daemon when receiving the messages from the user interfaces replies the messages using the same EC protocol and interacts with the other peers in the network to fulfill the required actions. At the same time, the aMule daemon keeps track of the session, the transfer queues using the ed2k transfer protocol and the DHT using the KAD protocol.

To search for a file, the aMule daemon uses the CKademlia class defined in Kademlia.h and interacts with other peers using the following messages [START_REF] Mysicka | Reverse engineering of emule-an analysis of the implementation of kademlia in emule[END_REF]:

• KADEMLIA_REQ message is sent to the known nodes whose identifier is closer to the hash of the keyword been looked up and iterates sending same message until no more closer to target nodes are found.

• SEARCH_REQ message is sent to those nodes that are known as the closer ones to the keyword's hash requested and they reply with the data they got about files that include the keyword in their metadata.

The aMule daemon caches the received results and passes them to the external interface using EC protocol when requested. When the file is selected by the user, the download is registered in the download queue.

Every time a new file is added to the queue, a SEARCH_REQ message is sent to find sources using the file id as search criteria. This search repeats periodically to update the source list of each file in the download queue. After sources are retrieved from KAD, aMule contacts each source asking for metadata about the file using the messages from ed2k protocol defined in TCP.h (i.e. OP_REQUESTFILENAME is sent to each source and is replied with a OP_REQFILENAMEANSWER message).

The sources register the client in their upload queue and notify it when it got the resources to transfer the requested data using the OP_SENDINGPART message.

After a file is downloaded (or if it is added to the sharing directory manually), it gets processed to extract metadata and all the extracted metadata is published, first in the nodes with the closer id to the hash of the keywords of the file to be published using the same procedure used for search, after the closest nodes to the target are found a STORE_KEYWORD message is send to those nodes and a STORE_FILE to the nodes that are closer to the file_id.

Next is a diagram of a simple flow of messages intervening in the download of a file in aMule. The numbers show a possible trace of the messages, some messages were suppressed to help the understanding, the order of them is not strict in the protocol and some times some of them can be swapped as it is the case for ( 8) and (9).

At top we got the interaction between the back end and the front end using the ECP:

(1) we start a search; (4) we ask for search progress; (5) we obtain the search results; [START_REF] Mysicka | Reverse engineering of emule-an analysis of the implementation of kademlia in emule[END_REF] we select what to dowload; (10) we monitor the download queue status.

At the bottom we got the interaction between the backend and other peers: (2,3) we send a requests to KAD; [START_REF] Timpanaro | Bittorrent's mainline dht security assessment[END_REF] we request metadata for the file to each source; (8) the sources reply with metadata about our requested file; (9) we request a subcription to the remote upload queue in a source.

Changes proposed to the aMule client

We got to retrieve the BitTorrent metadata from peers that know it. This metadata can be retrieved after download is added to download queue when sources are consulted about the metadata of the file to be transferred. If one of the known nodes replies with the info-hash, that also means that it provides BitTorrent services in the client and the port where this service is running should be retrieved to start a metadata exchange request using the already implemented methods in the libtorrent-rasterbar. There is no need to implement a message to request the info-hash since OP_REQUIRE_FILENAME is sent to all known sources and expects several asynchronous replies with different kinds of metadata as user comments, media tags, etc.

Protocol changes

• The new message providing the info-hash and the port number where to listen for BitTorrent protocol messages will be implemented as part of eMule extended protocol and the message will be named OP_BTIH.

• Some extra messages should be defined in the EC protocol to check Torrent specific stats, add new download starting from info-files, info-hash or magnet links, disable or enable Mainline DHT support.

Next is a diagram of a simple flow of messages intervening in the download of a file in the modified client hMule. This diagram is based in previous aMule diagram in section 6.

Application changes needed

The changes are between messages ( 8) to ( 12): (9) the new implemented message providing info-hash and port which is listening for BitTorrent protocol, is sent from sources having hMule; (10) Info-file is obteined using BitTorrent metadata exchange extension; (11) The swarm is joinned and the content is transfered.

Application changes needed

• To reply with OP_BITH an internal dictionary that maps eMule file ids to Bit-Torrent metadata hashes should be maintained internally. This dictionary should persist between sessions since torrent metadata coming from different sources has different metadata hash for the same content and we don't want to lose the original swarms.

• To provide backward compatibility, when a file was fully transferred using ed2k protocol, the info-file is generated and it is added to the dictionary. So users with hMule client can retrieve info-file and info-hash to use BitTorrent protocol. An external torrent file should be able to be added to the session and after fully transferred using BitTorrent protocol the file should be published in KAD and the dictionary updated.

• A class should be defined to wrap the libtorrent-rasterbar uses and a coordinator between the transfer protocols should be defined to avoid overlap of efforts and competition. This coordinator should be able to decide which protocols to use and fix the decision if it was not the best. The switch of strategies should be easy so the client can be used for experiments.

• A translation between wxWidgets structures and Boost ones should be provided in some cases.

• Building scripts should be modified to provide a non hybrid build and to detect the needed libraries.

Current implementation details

The glue between aMule and libtorrent-rasterbar was implemented defining a namespace torrent that contains a class Torrent to handle the wrapping and a class Torrent-MuleMapping that keeps track of the metadata relations.

The TorrentMuleMapping class is internally represented as 3 unordered maps to index the relations for search and a vector for iteration of the relations. The relations have 4 fields, a CMD4hash 6 , a SHA1hash 7 , a boost::filesystem::path that should point the metadata torrent file and a status of download enum. Several getters and update methods are defined to access the container, including constant iteration.

The Torrent class is implemented as a singleton and contains internally the libtorrent session, an instance of TorrentMuleMapping and methods to wrap libtorrent behavior as createMetadataForFile (which generates the torrent metadata for a known file). Torrent class also initializes and calls the TorrentStrategy used to select protocols for transfer, which is selected in the app's configuration file.

Initializing and shutting down the application

Main application class, called amuleApp, has an OnInit method and an OnExit method that are called at start and end of the application run. There is also specific methods for subapplication customization of those methods.

When application is launched and OnInit is called, aMule reads all the preferences of the user from the config file, initializes the Download and Upload queues, reads a set of metadata files called PartMet files to register the current downloads metadata in the download queue. There some extra activities handled in the OnInit method based in configuration, i.e. join edonkey servers and start running KAD, if any of them is enabled as soon as possible they start looking sources for all the downloads queued.

After all ports for aMule connections are open, the Torrent class instance is created setting the ports for BitTorrent connections (by default port 7000, but tries others if that one is taken). The Torrent object uses two configuration options to select where to persist the info-files and where to persist the dictionary betweeen sessions. The strategy to use is read from the config file only once, so if you want to change it, session should be restarted.

After the download queue are completly loaded, the method refreshMetadata in the Torrent class is called. This method iterates the TorrentMuleMap to load all the metadata known from previous sessions then checks the torrent directory defined in the config for info-files that are not mapped yet and load them, this works as a dropping directory for those not using the amulecmd UI.

Then aMule calls reloadFiles in SharedFilesList class to update the metadata of the shared files, this method was modified so it calls addFilesFromDirectory method in Torrent object to update the metadata of torrent files and update information in the TorrentMuleMap also.

When the application shutdown calls OnExit method all is persisted and shutdown, this 6 Type of identifier used for files in aMule 7 Type of identifier used for the BitTorrent content 8.2 Starting a download from KAD method was modified to include info-files and dictionary in the list of persisted things between session and also shutdown the BitTorrent session.

Starting a download from KAD

When a user searches KAD and finds a file he/she wants to download, the file is added to the download queue, in KAD same file identifier was used for files that are transmitted using ed2k protocol for transfer than those transferred using BitTorrent since the content is the same and we want to keep backward compatibility. If a user having an old client finds the file in KAD and doesn't support BitTorrent transfers, the file should be transferred using ed2k protocol without the need of a new search.

After the file is added to DownloadQueue and KAD provides a list of sources a message OP_REQUEST_FILENAME is sent to each source to request for metadata of the file to be transferred.

When the source uses the extended eMule protocol, it will reply with several message with different information as idv3, comments, filename, etc., if using our implementation we will reply one more message, named OP_BTIH that contains the info-hash and the listening port for BitTorrent interactions.

When our client receives metadata from sources, it will process it using the processFile-Info method in DownloadClient class, this one was modified to check for OP_BTIH messages, if any was received the information contained is passed to the Torrent class using the addTorrentUsingSHA1AndPeer method, this adds the ip and port of the peer that provided the information and the info-hash of the file and with this data libtorrentrasterbar starts a torrent connection to the peer and asks for a full metadata exchange.

The main loop of the application has a second thread to process asynchronous tasks, every time a loop is completed the download queue and upload queue gets a call to the process method, a call to the process method in Torrent class was added so asynchronous alerts from libtorrent-rasterbar can be attended and TorrentStrategy can do the switch of protocols if needed.

After file is fully downloaded in torrent, the process method calls for a recheck of the file in the aMule download queue this validates the AICH hashes and flag the file as completely downloaded, moves the file out of the temp directory and shares it.

Strategies for referee

Two basic strategies were implemented, one that saves metadata provided by others, provides the OP_BTIH replies to other peers requesting it and transfers content to other but doesn't use BitTorrent protocol to download content, this strategy was named NoTorrentStrategy and can be selected in config as strategy=0, the second was defined so at the moment metadata for BitTorrent is fully obtained the download is handled completely by BitTorrent transfer protocol, this one was named AllwaysFallToTor-rentStrategy and can be selected in config as strategy=1. When a file .torrent with the metadata for a torrent file is provided from the web or other source, it needs to be added to the libtorrent-rasterbar session to be downloaded and after it is fully downloaded be published in KAD.

The file path can be provided in the add command of amulecmd or dropping the file in the torrent directory configured, also add command can receive a BitTorrent magenet link and download if mainline DHT is enabled.

Mainline DHT can be enabled using connect mainline command in aMulecmd.

Sharing a new file

When a new file is added in the sharing directory and reload button or reload command is executed and the reload method in SharedFilesList is called, this already calls the reload method in Torrent class and everything gets registered.

Other changes

Autoconf scripts have been modified to check for the new libraries needed in the software, a -enable-torrent option has been added to the ./configure script that separated the code been compiled for hybrid version than the one used to build a original aMule version with no hybrid code in it.

9 Experimentation 21

Experimentation

To test functionalities, we used in PlanetLab where several daemons were installed. We deployed 8 nodes with hMuled, 4 of them were configured to use NoTorrentStrategy and the other 4 were configured to use AlwaysFallToTorrentStrategy, also we deployed 4 nodes using aMuled, 2 built from aMule original code and 2 bould from hMule using building paramenter -disable-torrent.

After deploying all the nodes, random content was generated in each node and shared. Using aMulecmd or aMulegui nodes were accessed to do search in KAD of the other nodes published content and all files were transferred. We validated that, when possible, the content was transferred using BitTorrent protocol and over 95% of the time the metadata for BitTorrent was obtained before any content transfer using ed2k protocol, meaning no thrash was produced in the Temp directories.

After test that all our nodes can share the content between them, we did a second experiment where popular content was searched in KAD network and downloaded by all our peers. At first we were searching in each node a few minutes later than the previous one and when last one started to download it was verified that it was using only BitTorrent resources.

Another showed that when all the downloads start simultaneously the swarm doesn't get joined by all the peers who could since the join is done when a peer asks for metadata to others and at the time the download is started none of them can provide an info-file. Anyway, after at least one source finish the download, if a new peer asks for the same content afterwards it will gather all those peers together in a swarm, this happens because the new peer will trigger the exchange of bootstrap message in all of the sources, then it will get the info-file from the source that already completed the transfer and when others check this peer as a source will obtain the info-file from it.

Two more test were ran where peers running hMule downloaded content from Bit-Torrent networks using magnet links (with mainline DHT) or info-files (downloaded from the web) was succesful. After publish the content in KAD, other peers searched for it, they found the content and started the download, these new peers downloaded joined the original swarm with any other BitTorrent client keeping backward compatibility. Notice that files downloaded from BitTorrent networks doesn't get indexed in KAD until full download and to keep new downloaders joining the peers in the original swarm, the original info-file should be provided and not a new computed one (as it happens).

Tests also showed that when using AlwaysFallToTorrent, after a file started download using BitTorrent and all peers providing the content goes down the transfer stills, but after a new peer connects (or some of the previous reconnects) the transfer is resumed fine because the new peers are detected in the aMule network and notified to the Bit-Torrent session. New experiments should be created with several nodes to check which are reasonably better parameters for the defined strategy. Also more interesting strategies should be implemented where offering the chance to switch back to ed2k network when the download could be improved.

Hybrid download using sparse files

One of the main problems to switch protocol in a download is to keep the downloaded data, aMule and libtorrent-rasterbar provide a format for the saving file called "sparse file" that reserves the whole file required space at the start of the download fill it all with 0s and starts writing the received content in the place it should go. Using this format it is reasonable to switch protocols on the same file without problems, it will only require a full recheck of the pieces hash at the start to know what the other protocol provided.

There are a few issues to solve for that, both libraries use different ways to open the file so the ways should be unified or the file should be split in 2 or more pieces so it can be opened separately, if split the point of split should be wisely selected, second issue will be to avoid overlap of work, this includes the creation of a map of pieces overlapping since pieces in torrent and ed2k have different size and will not match 1 to 1, neither 1 to an integer in most the cases.

Multifile multiprotocol content support and collections

Torrent metadata of a content can include several files and even directories, most of the popular torrent file downloaded from the web got more of 1 file, in the other hand eMule provides a kind of file name .emulecollection containing a list of MD4 hashes of a set of files that when downloaded is read and all the files identified into the files start download. It is difficult to match the 2 approaches (specially because the emule approach doesn't have concept of directory).

The proposed approach for this issue will be to read the shared files directory. If a directory is there, it will be shared in torrent as a directory structure in a single torrent file and in ed2k as a emulecollection, if the file is downloaded from torrent an emulecollection file will be defined when the full directory structure is downloaded and if downloaded from an emulecollection a directory will be created when download finishes with all the files and be shared as a torrent file that contains several files with one single directory in the structure.

Protection against Fake SHA1

Since there is no math conversion between the ed2k identifier and the info-hash of a file we trust user to provide the translation, those user can fake the sha1 so we start downloading something that doesn't match the original indexed content, so when a 10.5 Fake SHA1 earlier detection download finishes in using BitTorrent protocol we validate that the content's MD4 hash matches the original ed2k identifier and throw an error, this error should be handled.

Fake SHA1 earlier detection

In *Mule networks there is a set of hashes to detect when a file is not going to match the expected content to early detect, it is called AICH validation and similar set of hashes is produced in BitTorrent when the Torrent is Merkled. We should be able to find when some validated against Merkle pieces pull together cover a full piece of ed2k content and this piece fails to validate against AICH, when this happens we are downloading content that matches the provided info-hash but doesn't match the ed2k identifier, enough to say that info-hash is fake and we don't have to keep downloading it.

Torrent Fast Resume support

LibTorrent-rasterbar provides some tools to skip rehashing and management overheads that should be used.

Thread safeness

Before creating more complex strategies the operations that would be used for them should be checked for needing of locks, specially iteration operations, because most the code only locks at start and finish of the method and that can be not enough in some cases.

org) .

 . Changes to the BitTorrent protocol are proposed and decided by community. BitTorrent official client uses a DHT for index based on Kademlia called Mainline. The index maps SHA1 hashes of info-files to sources. The search for the file from keywords is handled outside of BitTorrent using the Web or other channels. In previous work BitTorrent transfer speed were compared with eMule in several scenarios showing that he download algorithm of BitTorrent performs better than KAD's algorithm[START_REF] Timpanaro | When kad meets bittorrentbuilding a stronger p2p network[END_REF]. BitTorrent was originally developed in Python in 2001 and licensed under MIT, since version 4 the code was closed by BitTorrent Inc, after several open-source alternatives were developed.

4. 2 4 . 2

 242 How should different clients interact once hMule is fully implemented 10 How should different clients interact once hMule is fully implemented

8. 4 8 . 4

 484 Starting a download from .torrent 20 Starting a download from .torrent

1

 1 Definition of referee strategies based on experimentation

Also known as decentralized file sharing network in some bibliography.

Distributed Hash Table.

http://www.planet-lab.org/

Appendix A Install Guide

The procedure to install hMule is pretty straight foward in any Linux or BSD system 8 .

Step by step install for Ubuntu 11.04 systems.

• Using synaptics, aptitude or apt-get install the following packages.

-libgtk2.0-dev

• Download wxWidgets 2.9.2 from http://www.wxwidgets.org and unpack it.

• Open a terminal, step into the wxWidget's code directory and run the following commands.

. / c o n f i g u r e --e n a b l e -debug --e n a b l e -u n i c o d e \ --d i s a b l e -s h a r e d --p r e f i x = / u s r make make i n s t a l l • Download Boost 1.47+ from http://www.boost.org and unpack it.

• Open a terminal, step into the Boost's code directory and run the following commands.

. / b o o t s t r a p . s h --w i t hl i b r a r i e s = s y s t e m , f i l e s y s t e m --p r e f i x = / u s r . / b2 . / b2 i n s t a l l

• Download libtorrent-rasterbar 0.16 from http://www.rasterbar.com/ products/libtorrent/ and unpack it.

• Open a terminal, step into the libtorrent-raterbar's code directory and run the following commands, if you are trying to find a bug there is options in configure that provide logging of every operation done by the library that can be really useful.

. / c o n f i g u r e --e n a b l e -debug --p r e f i x = / u s r make make i n s t a l l 8 The software is suppose to build an run in windows also, but was not tested by us in those platforms Appendix B User Guide 26

• Download hmule and unpack it.

• Open a terminal, step into the hmule's code directory and run the following commands.

. / a u t o g e n . s h . / c o n f i g u r e --e n a b l et o r r e n t make make i n s t a l l

• There is interesting options that could be added to the configure command in hmule.

--enable-amule-daemon builds amuled, a deamon to run amule that can be controlled remotely with amulecmd or amule-gui (best option to use in planetlab).

--enable-amulecmd builds amulecmd, a command line interface to control an amuled.

--enable-amule-gui builds amule-gui, a gtk GUI for amuled.

--disable-monolithic prevents the building of the full monolithic client (useful to add when using any of the previous options).

Appendix B User Guide

This guide doesn't intend to fully cover hMule usage, but to introduce the user to the new functionallities provided by this implementation, this guide can be complemented by the original user guide of aMule provided in http://wiki.amule.org.

Appendix B.1 New configuration parameters

In aMule configuration file, usually in /.aMule/amule.conf, we defined a new category called Torrent which has 2 configuration options.

• TorrentDir that defines a directory where the info-files will be saved.

• Strategy that defines the strategy used todecide which protocol to use, so far we got NoTorrentStrategy (using Strategy=0) or AlwaysFallToTorrent (using Strat-egy=1).

Appendix B.2 Connection to Mainline DHT

To connect to or disconnect from Mainline DHT two new commands are provided in aMuleCmd.

• connect mainline

• disconnect mainline

Appendix B.3 New files

All files been downloaded using BitTorrent protocol will be stored in Temp directory with the name provided by the info-file until fully transfered, when transfer is complete it will be moved to Incomming directory. All metadata obtainned for BitTorrent transfers will be saved in as info-files into Torrent directory.

Appendix C Known Issues

• Localization fails and crash when openning amuled in some systems. To disable localization export LC_ALL=C before running amuled and you can skip the error at the price of using non localized version.

• Some times when trying to find for updates an http error appears and crashes the full app, restart the app, it tries once every few days and if didn't crash in the first few minutes it is safe since app will not try again until new instance is started.

• When shutting down the application some times it tries to remove some objects more than once creating a core dump, it happens after saving all data so doesn't affect next run.

More known bugs can be found in the http://bugs.amule.org/, but only these show up in the experimentation we have done.

Appendix D Most relevant new classes documentation

Static Public Attributes

• static const int NO_BT = 0 • static const int ALLWAYS_FALL_TO_BT = 1 constant indetifying the NoBtStrategy.

• static const int SWITCH_TO_THE_MOST_USABLE_PEERS = 2 constant identifying the AlwaysFallToBTStrategy.

Appendix D.1.1 Detailed Description

Wrap class for torrent functionalities.

It is implemented as a singleton, to get the instance use: Torrent::getInstance() method. Add a download to Torrent queue knowing SHA1 and a peer.

If the file is not in the queue, it is added and the peer is associated hoping to get a full metadata exchange from it, else the peer is added to the set of known peers for that file.

Parameters fileId An MD4 identifier for a file known in aMule. SHA1Hash The SHA1 provided by KAD that identifies the file's torrent metadata. The file is copied into the torrent files directory and an unregistered torrents call is made.

Parameters file

The complete filename for a info-data torrent file.

Returns true if the file was registered successfully in tmm. Obtain the SHA1 content identifier for torrent knowing its muleId.

Parameters fileId An MD4 identifier for a file known in aMule.

Returns

SHA1 torrent content identifier. Loads all the torrents info-files that are known but not loaded in session yet and saves all the torrent info-files of those that were received but not persisted yet. Torrent sessions are a container for all the shared and downloading torrents and handle all the connections some ports are opened when starting the session and if prefered Mainline DHT is joined too. Obtain the SHA1 content identifier for torrent knowing its muleId.

Warning

This method assumes you asking for a valid tuple, check before use.

See also

HasBTIH

Parameters muleId An MD4 identifier for a file known in aMule.

Returns

SHA1 torrent content identifier.

Appendix D.5.4.5 const libtorrent::sha1_hash& torrent::CTorrentMuleMapping::GetBTIH ( boost::filesystem::path torrentFile ) const

Obtain the SHA1 content identifier for torrent knowing the filename of its info-file.

Warning

This method assumes you asking for a valid tuple, check before use.

See also

HasBTIH

Parameters torrentFile

The name of a info-file containing torrent metadata.

Returns

SHA1 torrent content identifier.

Appendix D.5.4.6 const CMD4Hash& torrent::CTorrentMuleMapping::GetMuleIH ( libtorrent::sha1_hash torrentId ) const

Obtain the MD4 aMule file identifier for torrent knowing the torrent SHA1 content identifier.

Warning

This method assumes you asking for a valid tuple, check before use.

See also

HasMuleIH

Parameters

torrentId An SHA1 identifier for a content known in Torrent.

Returns

MD4 identifier for a file known in aMule.

Appendix D.5.4.7 const CMD4Hash& torrent::CTorrentMuleMapping::GetMuleIH ( boost::filesystem::path torrentFile ) const

Obtain the MD4 aMule file identifier for torrent knowing the filename of its torrent info-file.

Warning

This method assumes you asking for a valid tuple, check before use.

See also

HasMuleIH

Parameters

torrentFile The name of a info-file containing torrent metadata.

Returns

MD4 identifier for a file known in aMule.

Appendix D.5.4.8 const boost::filesystem::path& torrent::CTorrentMuleMapping::GetTorrentPath ( CMD4Hash muleId ) const

Obtain the filename of a torrent info-file knowing its muleId.

Warning

This method assumes you asking for a valid tuple, check before use.

See also

HasTorrentPath

Parameters muleId An MD4 identifier for a file known in aMule.

Returns

filename of the torrent info-file.

Appendix D.5.4.9 const boost::filesystem::path& torrent::CTorrentMuleMapping::GetTorrentPath ( libtorrent::sha1_hash torrentId ) const

Obtain the filename of a torrent info-file knowing its torrentId.

Warning

This method assumes you asking for a valid tuple, check before use.

See also

HasTorrentPath

Parameters torrentId An SHA1 identifier for a content known in Torrent. Updates or creates a MetadataRelation.

Returns

It looks for MetadataRelations partially containing the data provided and replaces the null data so the Metadata Relation increases knowledge, it can't remove info or modify it, only increment it. Usually this Update is used when a file starts sharing or when a download started in KAD and some peer provided the info-file metadata for Torrent transfer. (both cases content metadata is completely known).

Parameters muleId A MD4 identifier of an aMule known file. torrentId A SHA1 identifier of a torrent known content. torrentFile A filename of where the info-file metadata is saved to load it again in next session.

Returns

Pointer to the created or updated Metadata Relation.

Appendix D.5.4.34 MetadataRelation * torrent::CTorrentMuleMapping::UpdateMetadata ( CMD4Hash muleId, libtorrent::sha1_hash torrentId )

Creates a MetadataRelation.

It creates a MetadataRelation with the aMule Identifier and the BT info-hash, but keeps the torrentFile as NULL. Usually this Update is used when a download started in KAD and some peer provided BTIH, but the info-file metadata for Torrent transfer was not acquired yet.

Parameters muleId A MD4 identifier of an aMule known file. torrentId A SHA1 identifier of a torrent known content.

Returns

Pointer to the created or updated Metadata Relation. It creates a MetadataRelation with the BT info-hash and the filename of the info-file containing torrent metadata and keeps the torrentFile as NULL. Usually this Update is used when a download started in from mainline or .torrent file and the MD4 identifier for aMule is not known yet.

Parameters torrentId A SHA1 identifier of a torrent known content. torrentFile A filename of where the info-file metadata is saved to load it again in next session.

Returns

Pointer to the created or updated Metadata Relation. Check if a content Was Removed knowing its torrent filename.

Parameters torrentFile

The name of a info-file containing torrent metadata.

Returns

true if the file is in state removed.

The documentation for this class was generated from the following file: • uint32 m_lastTimeValidationQueueProcessed last time the Alerts for torrent asynchronous task were processed.

• libtorrent::session * m_ts last time the Validation Queue was processed.

• CTorrentMuleMapping * m_tmm pointer to the active torrent session.

• std::vector< std::pair< CMD4Hash, int > > m_validationQueue pointer to the Metadata Relation for torrent and amule.

Appendix D.6.1 Detailed Description

Abtract class for Transfer protocol selection strategies.

Different strategies can be created to handle the way it is decided to choose transfer protocol and when to switch to the other one. Constructor.

Parameters torrentSession

A pointer to the running torrent session.

mapping A pointer to the MetadataRelations between Torrent and aMule.

Appendix D. Constructor Overrides CTorrentStrategy so nothing is done.

Parameters torrentSession

A pointer to the running torrent session. A strategy that Falls to Torrent transfer protocol as soon as BTIH is known This strategy checks if any peer provided a Info Hash for Torrent transfer and as soon as it is transfered pauses the download in the aMule download queue and fully transfer the content using BitTorrent transfer protocol. It is not a very smart strategy but is great for debugging. Check CTorrentStrategy comments.


Sao Mai Nguyen

Masaki Ogino

Minoru Asada

Real-time face-swapping as a tool for understanding infant self-recognition

To study the preference of infants for contingency of movements and familiarity of faces during self-recognition task, we built, as an accurate and instantaneous imitator, a real-time faceswapper for videos.

Self-recognition development

Human neonates detect contingency between their movements and what they see [START_REF] Rochat | Others in Mind[END_REF] but they cannot discriminate their own image from that of another infant before 5 months of age. Only by 18 months can they recognize themselves in a mirror. The 6 to18 months period is a decisive developmental stage.

Behavioral studies have shown that 9-month-olds display a preference for familiar faces similar to themselves [START_REF] Sanefuji | Preference for peers in infancy[END_REF], but also that 5-month-olds show differential visual fixation to a contingent video [START_REF] Bahrick | Detection of intermodal proprioceptive-visual contingency as a potential basis of selfperception in infancy[END_REF].

Unbiased imitator

We propose to compare the contingency of movements and familiarity of faces factors in self-recognition in an experiment where an imitator reproduces the head, arms and body movements with or without delay. The imitator's face may be identical to the subject's face or look different. We thus developed a face-swapper for videos that detects the face position and orientation of the current subject A, then superimposes the image of a subject B on A's face (fig. 1 where A and B's faces are identical). To avoid disturbing the subject's behavior or appearance, we did not use special markers. The only installa-tion was a camera. Our non-constraint real-time system is an integration of existing 3D head posture trackers, with an original face-swapper in videos. The very short delay of the face swapper has been reached thanks to parallel computing including the General-Purpose computing on Graphics Processing Units (GPGPU). The novelty of this work also lies in its easy calibration.

Face-swapper for videos

The overall system (fig. 2) includes a head tracker to determine the head position and orientation of the current subject A, and a face swapper to replace the face of A by that of subject B. Its calibration only uses frontal face pictures of subjects A and B, and the camera video as inputs.

3D visual tracker

Devices measuring the head's pose such as magnetic sensors, link mechanisms or motion capture unfortunately alter the subjects' behavior or their natural appearance. As non-invasive methods, faceAPI, sparsetemplate-matching-based object tracking [START_REF] Matsubara | Real-time object tracking by sparse template matching[END_REF] and CAMSHIFT solutions exist. However they either are commercial systems where the information needed to adapt it for children and extend it to a face-swapper could be inaccessible, or they lack robustness. [START_REF] Matsumoto | 3D model-based 6-DOF head tracking by a single camera for human-robot interaction[END_REF] propose an estimation of the 6-DOF motion of the face using a single camera, but require the heavy set-up of a personal 3D facial model. [START_REF] Lozano | Real-time visual tracker by stream processing[END_REF] present a real-time visual tracker by stream processing and particle filter using a generic 3D model of the face. Our head tracker also adopts this approach to estimate the state x = (T x , T y , T x dot , T y dot , S, R x , R y , R z , R y dot , α) where T x , T y are the translation coordinates of the target object, T x dot , T y dot are the velocity along the horizontal x and vertical y axes, S is the scale, R x , R y , R z are the rotations along each axis, R y dot is the velocity of the rotation along the vertical axis y, and α is a global illumination variable.

Our tracker relies on multi-processing and sparsetemplate-based particle filtering. No 3D face model was used, but a simpler ellipsoid model. The real-time constraint has been kept thanks to the parallel processing of the camera capture, head-tracking, face-swapping and results-display threads. Moreover the computation of the particle filter was speeded up by the use of GPGPU and NVIDIA CUDA.

Face-swapper

Once x A the face position and orientation of A is detected, an image of B is superimposed on A's face.

Replacement of whole faces in still images has been developed only recently [START_REF] Zhu | Unsupervised face alignment by nonrigid mapping[END_REF], [START_REF] Bitouk | Face swapping: Automatically replacing faces in photographs[END_REF]). However, we target videos with real-time constraints, continuity and movement factors.

Our system first creates automatically a set of replacement faces of subject B and tags them with the position and orientation x. The face-swapper thread compares the state parameters x A with those of the replacement faces of B. It selects the closest face replacement x B to superimpose on A's face. To render the temporal continuity, the replacement face is interpolated before superimposition, so that the replacement looks dynamic. We obtain a whole system for automatically replacing faces in videos, that renders dynamic movements of the head.

Performance

A demonstration video can be found on the site http: //www.youtube.com/watch?v=qtYl4o4QoIo.

The real-time constraint was the greatest challenge. The use of GPGPU and parallel processing decreased the delay to 99ms. In addition, our face-swapper is robust against background distractors such as other faces in the background (fig. 1). The head-tracker can detect a wide range of face orientations with a head pitch angle up to 70 degrees and is robust against partial occlusion like when children bring their toys or hands to their mouth or faces.

The system was evaluated against motion capture system, with an adult subject moving at normal speed, and a head rotation ranging from -40 to 40 • . The pitch angles measured by the motion capture system and ours show the same variations. The average error is 9 • .

Conclusion

We presented a non-constraint face-swapper based on 3D visual tracking that achieves real-time performance through parallel computing. Our imitator system is particularly suited for experiments involving children with Autistic Spectrum Disorder who are often strongly disturbed by the constraints of other methods (Frith, 2003). It can estimate their attention point during natural social interaction to study their peculiar attention pattern, or be used as an imitator to evaluate how imitation facilitates their social behaviors. Future improvement can focus on the facial expressions.

We plan to conduct our experiment with children to investigate the importance of the contingency and familiarity factors in self-recognition. In the longer perspective, the results could be confronted to neuro-scientific data such as the activation in the frontal lobe of the right hemisphere [START_REF] Uddin | Self face recognition activates a fronto parietal mirror network in the right hemisphere: an event-related fMRI study[END_REF] or the default network [START_REF] Goa | Evidence on the emergence of the brain's default network from 2-week-old to 2-year-old healthy pediatric subjects[END_REF] to model the development of selfconsciousness, in the context of human self-consciousness analysis, but also for implementation of a robotic sense of self-consciousness.

Figure 1 :

 1 Figure 1: face-swap: B's face is superimposed on A's face

Figure 2 :

 2 Figure 2: The system contains a face tracker and swapper

Acknowledgement: We would like to thank Pierre-Yves Oudeyer for his helpful comments on the draft of this paper and Sawa Fuke for her support for the demonstration video.


Mohammed ; Eslam

Reyes Aparcero

Takumi Kawaguchi

José A Del Campo

Michio Sata

Mahmoud A Khattab

Manuel Romero-Gomez
email: mromerogomez@us.es

MD, PhD Director Manuel Romero-Gómez

Mohammed Eslam¹

Reyes Aparcero¹

Takumi Kawaguchi²

José A Del Campo¹

Michio Sata²

Mahmoud Abo-Elneen

Manuel Khattab³

Romero-Gomez¹

Insulin resistance and sustained virological response in hepatitis C

Keywords: Insulin resistance and sustained virological response in hepatitis C Hepatitis C < Hepatology, Viral hepatitis < Hepatology, Liver < Organ-based, Meta-analyses Insulin resistance and sustained virological response in hepatitis Hepatitis C virus, Insulin resistance, HOMA-IR, sustained virological response

. Chronic HCV infection is characterized by a high rate of fibrosis progression, leading to cirrhosis and ultimately to hepatocellular carcinoma [ 2,3 ].

Combination therapy with pegylated interferon alpha and ribavirin (Peg-FN/RBV) represents the current standard of care in chronic HCV [ 4,5 ]. Despite the improvements in sustained virologic response (SVR) seen using combination of Peg-FN plus weightbased RBV, SVR rates in genotypes 1 and 4 populations have remained unsatisfactory with reported SVR rates of 28.9% to 54% [ 6,7 ]. Even more unsatisfactory SVR rates on the order of 10% to 20% have been seen in difficult-to-treat populations such as African Americans, Hispanics, or insulin-resistant patients [ 6-8 ]. Studying the factors influencing SVR in patients with HCV treated with Peg-FN/RBV has been assiduously pursued over the past two decades. Now; there is a great interest by the importance of host factors such as fibrosis progression, genetic factors and metabolic disorders and these have been invoked to explain the reported differences in SVR [ 9 ]. Insulin resistance (IR) is the main feature of metabolic syndrome and is characterised by hyperinsulinaemia in patients with normal fasting glucose. It has been associated with increased risk of developing diabetes mellitus (T2DM), cardiovascular disease and non-alcoholic fatty liver disease [ 10 ]. Accumulating large body of literature, including molecular, pathological, epidemiological, randomised controlled trials and observational studies, has highlighted the interaction between HCV and glucose metabolism (IR/T2DM) [ 11,12,13,14,15,16 ]. Although, earlier works refereed to that a higher baseline homeostasis to Peg-IFN-α/ribavirin in treatment-naïve chronic hepatitis C patients [ 8'17,18,19,20 ]; this data was not universally confirmed by all studies [ 21 ]. In the view of the suboptimal response to the current standard in therapy; these postulated correlation between IR and SVR has gain a great importance, as one of the modifiable risk factor. Therefore, we performed a systematic review and meta-analysis to review the literature systematically to evaluate, quantify, and summarize the association between HOMA and SVR.

Methods

Study Selection Criteria

Inclusion and exclusion criteria were defined prior to commencement of the literature search. Studies were included if they met the following criteria: they included treatment-naive HCV patients aged older than 18 years regardless HCV genotype or the ethnic group; they provided information on SVR rates; and they were reported in English as full papers. Studies were excluded if they met the following criteria: they did not provide information on SVR; they did not allow correlation between the HOMA-IR and SVR; they included patients who were treated with nonpegylated interferons; they included patients with additional antivirals to Peg-FN/RBV (eg, amantadine); they included patients who were not treatment-naive; they included human immunodeficiency virus (HIV) coinfected patients; they included liver transplant recipients; letters/case reports, studies enrolling fewer than 10 subjects, or articles not reporting outcomes of interest or primary data (editorials, reviews).

Literature Search, Study Selection, and Data Extraction

We searched MEDLINE and EMBASE for studies published in English through December 2010 using a combination of the following terms: "Hepatitis C"[Mesh] OR "Hepacivirus"[Mesh] OR "Hepatitis C, Chronic"[Mesh]) AND "Insulin Relevant reviews and letters to the editor were excluded from the analysis, but read in full in order to identify potential relevant original studies. Disagreements between the 2 observers were resolved by discussion. Data from selected studies were extracted in a data sheet by MRG author and checked by a second author (ME). Disagreements could be resolved by discussion. The following data were extracted: year of publication, number of patients, cutoff of HOMA-IR to define IR, method of measurement of insulin, percentage of patients with normal insulin sensitivity and percentage of patients with advanced fibrosis.

End Point

The main endpoint was the SVR rate, defined as the percentage of patients with undetectable HCVRNA (<50 IU/ mL) 24 weeks after treatment completion of therapy.

Statistical analysis

Statistical analysis was performed by using the

Results

Seventeen eligible studies fulfilled the inclusion and exclusion criteria are enrolled in the analysis ( 8,17-21,22,23,24,25,26,27,33,38,43 ), three studies without SVR rate according to baseline HOMA-IR were further excluded (Figure 1). The characteristics of these studies are shown in Table 1. Five studies were from Italy, 3 from Japan, 2 from Taiwan, 1 from Spain, United Kingdom, USA, France, India and Egypt. The used cutoff values for diagnosis of IR ranged from HOMA>2 in 10 studies to HOMA > 2.5 in 1 study, HOMA>2.7 in 1 study, HOMA>3 in 1 study and HOMA>3.5 in 1 study and was not available data in three studies. Nine studies found a statistically a significant association between HOMA-IR and SVR, and the other 5 studies did not find a significant association between HOMA-IR and SVR (Figure 2 and Table 1). Three of enrolled studies did not show SVR rate according to HOMA-IR. Thus, pooled data included 2129 patients in 14 studies. The meta-analysis including all 14 studies demonstrated that insulin resistance was associated with a remarkably lower likelihood of SVR, using random effects model by Der Simonian and Laird method, odds ratio was 2.86 (95% CI: 1.97 to 4.16) regardless of genotype (Figure 2). The test of heterogeneity (Cochran-Q=36.92; df=13; p=0.0004) inconsistency I 2 = 64.8% and Tau-squared = 0.287. Sub-analysis including patients segregated by genotype 1, 2/3 or 4 demonstrated a negative and significant impact of increased HOMA-IR on SVR; three studies mixed genotypes were included and were separately analyzed (17, 21, 39) (Table 2, Figure 3,4,5). Even with limiting the analysis to include only studies using cut-off HOMA > 2 for defining IR, the impact on SVR was maintained. Patients with HOMA-IR >2 had significantly lower rates of SVR compared with patients with HOMA-IR < 2, and this the conversion factor between SI units and mU/ml, the formula to calculate HOMA-IR and the threshold to define IR. For example: a) Insulin assays are not standardized and are not comparable between studies. Insulin inter-assay variations can be large, and values have varied considerably between different laboratories [ 29,30 ] b) careful handling of the blood samples is essential because hemolysis results in the degradation of insulin, while freezing the samples results in the degradation of C-peptide and glucose, with false-negative results being one of the consequences. c) Insulin should be reported in International Units (SI), but the conversion factor from microUnits/mL to SI units is not uniform among manufacturers; values ranging between 6 and 7.15 with no real scientific justification [ 31 ]. d) HOMA-IR could be calculated using the formula from Matthews et al. or using the HOMA-2 calculator (available at http://www.dtu.ox.ac.uk/homacalculator/). However, results from both methods are quite different and could bias the final analysis in comparative studies. e) Since insulin secretion is pulsatile, the use of a single fasting blood sample to diagnose IR in CHC, although convenient, potentially underestimates the prevalence and degree of this disturbance. The mean value from three samples taken at 5-min intervals to compute HOMA is, theoretically, better than a single sample determination [ 22 ]. However, in practice a single sample is often taken and, if population estimators are found, this is an acceptable compromise that yields a similar result for large datasets. No evidence is available in setting of CHC patients. f) Ultimately; till now; there is no international consensus regarding the threshold that defines IR by using HOMA-IR. Recently, Lam et al. showed that HOMA-IR >4 was the optimal value defining IR in hepatitis C setting when compared with steady-state plasma glucose [ 32 ]. However, these data need to be further confirmed in different populations, using euglycaemic hyperinsulinaemic clamp as gold-standard, and taking ethnicity and obesity into account when evaluating changes Interestingly in our review to the negative studies that failed to find an association between IR and SVR; the mean baseline HOMA-IR was <3 in all studies, and the prevalence of advanced fibrosis or cirrhosis was also lower or even these studies had excluded cirrhosis or had been under-powered. This observation supporting the idea that the more difficult-to-treat cohort the better the HOMA-IR prediction. In one of the negative studies, when HOMA-IR was excluded from the multivariate model, one of these variables emerged as independently associated with SVR. This highlights this type of statistical bias is very difficult to resolve when strongly related variables were included in the analysis. Indeed, Dai et al [ 17 ] demonstrated that the association of HOMAIR with SVR was stronger in cohorts including very difficult-to-treat patients.

Ultimately; when more sophisticated methods to measure IR (such as whole-body insulin sensitivity) were used, a stronger association was reported between IR and SVR [ 33 ]. Thirdly; several viral and host factors have an impact on response to treatment [ 34 ' 35 ], these factors may influence the final outcome and explain the difference of results of these cohorts. Further study is needed to clarify the interaction of genotype, the degree of IR, gender, and genetics (such as the IL28β mutation) and viral kinetics. This Meta-analysis has undoubtedly some limitations, since there is heterogeneity in the enrolled studies including characteristics cohort, methods for insulin measurement and HOMA-IR interpretation may have influenced on the concluded results. In conclusion, this meta-analysis provides evidence that impaired HOMA-IR was associated with a lower cure rate of patients with hepatitis C treated with Peg-FN/RBV. The differences are greater in cohorts of patients who are difficult to cure (higher insulin resistance, higher prevalence of advanced fibrosis). The inherent limitations in the determination and calculation of HOMA-IR may explain, at least in part, the variability detected in the results. Better handling and interpretation of HOMA are mandatory until the development of new tools for assessment of insulin resistance.

2

 2 Licence for Publication:The Corresponding Author has the right to grant on behalf of all authors and does grant on behalf of all authors, an exclusive licence (or non exclusive for government employees) on a worldwide basis to the Scholar one Publishing Group and its Licensees to permit this article (if accepted) to be published in Alimentary pharmacology& therapeutic editions and any other Scholar one products to exploit all subsidiary rights, as set out in our licence.

  million people are chronically infected with hepatitis C virus[ 1 ]

  insulin resistance (HOMA-IR) score predicted a poorer SVR rate

  Mesh] OR "Homeostasis Model of Assessment"[Mesh] AND "Sustained virological Response"[Mesh]. Manual search of cited bibliographies was also performed. Only fully published articles were considered. Two researchers independently performed the literature search and data abstraction with regard to the inclusion and exclusion criteria by reading titles and abstracts. When reading titles and abstracts did not allow identification of eligible studies, articles were read in full.

  Meta-Disc software 1.4 (Zamora J, et al., BMC Medical Research Methodology 2006, 6:31.) has been used, considering: i) a summary of data from individual studies, ii) an investigation of the studies homogeneity graphical and statistically, iii) calculation of clustered indexes and iv) exploration of heterogeneity. Our assumption of heterogeneity was tested for each planned analysis using the Cochran-Q heterogeneity test. Random effects model by Der Simonian and Laird method was considered when heterogeneity was found. Only 2-sided tests with a 0.05 were used. Confidence intervals (CIs) of individual studies were determined or approximated from the available data.

  independent of HCV genotype: HCV-1 (O.R.:2.16;95%CI:1.51-3.08), HCV-2&3 (O.R.:3.06;95%CI:1.06-8.82) and HCV-4 (O.R.:6.65;95%CI:2.51-17.61). The difference in SVR rate in patients with IR compared to those with insulin sensitivity ranged from 3% to 41% in genotype 1, 5% to 57% in genotype 2/3 and 38% to 48% in genotype 4. The risk estimate for not achieving SVR from 10 studies using HOMA-IR > 2 as cutoff value for diagnosis of IR was 3.1 fold. Similarly, the pooled estimates from 11 studies enrolled patients infected with HCV genotype 1 indicate a statistically significant 2.16-fold decrease in the incidence of SVR among patients with IR. Some studies that found no association were characterized by including cohorts of patients with a mean HOMA-IR <3 and without advanced fibrosis. In these studies; multivariate analysis demonstrated independent variables associated with SVR strongly related to metabolic abnormalities showing a tight co-linearity with HOMA-IR like body mass index, steatosis, elevated γ-glutamyl-transpeptidase (GGT), age and fibrosis.DiscussionThis meta-analysis of published studies indicates that IR assessed by HOMA-IR is associated with an approximately three fold increase in risk of failure to achieve SVR to Peginterferon+ribavirin in treatment naive patients with hepatitis C regardless of viral genotype. The discrepancy between the results of the cohorts in this review may be refereed to fact that the interaction between IR and SVR are very complex depends on numerous factors that need to be considered when interpreting the data: a) measurement and interpretation of HOMA-IR; b) colinearity between HOMA-IR and variables associated with metabolic derangements; and c) the characteristics of the cohort under study. HOMA-IR which was developed by Matthews et al[ 28 ] as an indirect surrogate marker of IR hampered by many concerns, which may influence the extracted data. These factors includes; methods of measurement of insulin, handling of blood samples,

  IR over time[ 26 ]. Second; HOMA-IR shows a strong colinearity, with several variables implicated in metabolic disturbances such as obesity, hepatocyte steatosis, elevated GGT, fibrosis and older age. All these variables provide information, at least in part, on the metabolic abnormalities occurring in the individual, the final outcome of the multivariate analysis depending on the interactions between them.

14 Figure 1 . 15 Figure 2 . 16 Figure 3 . 1 Figure 4 .Figure 5 .Figure 6 .

 1411521631456 Figure 1. Chart flow of studies screened and included in meta-analysis

Table 1 : studies included in meta-analysis addressing the impact of HOMA on sustained virological response

 1

	Author	year	HOMA Cut-off	SVR association	Insulin method	mean HOMA-IR (SD)	% patients with IS	Genotype	n	SVR in IS	non-SVR in IS	SVR in IR	non-SVR in IR	Delta %SVR IS -IR	O.R. (95%CI)
	Akuta et al	2009	3.5	NO	NA	2.6 (2.6)	0,28	1	123	11	9	26	26	0,05	0.82(0.29-2.33)
	Bortoletto et al	2010	3	YES	EIA	1.9 (1.1)	0,61	1	36	8	14	2	12	0,22	0.29(0.051-1.49)
	Camma et al (*)	2006	NA	NO	NA	2.65 (2.01)		1	291	NA	NA	NA	NA		NA
	Chu et al.	2008	2	YES	EIA	2.93 (0.14)	0,31	1	133	38	3	50	42	0,38	0.14(0.005-0.54)
	Conjeevaram et al	2007	2	YES	NA	3.5 (5.0)	0,33	1	399	65	68	96	170	0,13	0.87(0.77-0.99)
	Dai et al.	2009	2.5	YES	RIA	2.24 (2.46)	0,71	1	150	75	31	22	22	0,21	0.87(0.75-0.97)
	Fattovich et al	2010	2	NO	ECLIA	2.7 (2.5)	0,44	1	181	37	43	44	57	0,03	0.9(0.5-1.64)
	Grasso et al	2009	2	NO	EIA	2.6 (2.1)	0,77	1	90	34	35	8	13	0,11	0.63(0.23-1.72)
	Miyaaki et al	2009	2	NO	NA	1.9 (0.87)	0,51	1	39	11	9	6	13	0,23	0.37(0.1-1.38)
	Mizuta et al	2010	2	YES	NA	1.92 (1.92)	0,51	1	51	17	9	6	19	0,41	0.17(0.049-0.57)
	Petta et al.	2009	2.7	NO	EIA	2.73 (1.69)	0,65	1	83	32	22	14	15	0,11	0.64(0.17-3.03)
	Romero-Gomez et al.	2005	2	YES	ECLIA	3.01 (2.67)	0,38	1	113	26	17	23	47	0,28	0.55(0.33-0.93)
	Walsh et al (*)	2006	NA	NO	NA	2.02 (0.19)		1	66	NA	NA	NA	NA		NA
	Bortoletto et al	2010	3	YES	EIA	1.9 (1.1)	0,67	2&3	21	14	0	3	4	0,57	NC
	Dai et al.	2009	2.5	NO	RIA	2.24 (2.46)	0,71	2&3	180	117	11	44	8	0,07	0.87(0.75-0.97)
	Fattovich et al	2010	2	NO	ECLIA	2.7 (2.5)	0,57	2&3	209	93	26	66	24	0,05	0.8(0.42-1.54)
	Poustchi et al.	2008	2	YES	RIA	3.34 (3.34)	0,41	2&3	82	32	2	31	17	0,30	0.15(0.03-0.77)
	Walsh et al (*)	2006	NA	NO	NA	2.02 (0.19)		2&3	79	NA	NA	NA	NA		NA
	Khattab et al.	2010	2	YES	ECLIA	2.82 (1.19)	0,40	4	131	47	6	32	46	0,48	0.07(0.01-0.43)
	Moucari et al	2009	2	YES	ECLIA	3.7 (4.0)	0,49	4	108	39	20	14	35	0,38	0.19(0.07-0.51)
	(*) Not included in meta-analysis due to lack of data					2565
	HOMA: Homeostasis Model of Assessment
	SVR: Sustained virological response
	SD: Standard deviation
	O.R.: Odds ratio
	IS: Insulin sensitivity (HOMA under cut-off)
	IR: Insulin resistance (HOMA above cut-off)
	NA: Non-available
	ECLIA: Electrochemiluminescence Immunoassay
	EIA:Enzyme Immunoassay
	RIA: Radio Immuno Assay
	NC: Calculation not allowed

Table 1 :

 1 studies included in meta-analysis addressing the impact of HOMA on sustained virological response

	F o r
	P
	e
	e r
	R
	e
	v i e
	w

Table 2 : Random effect Model for pooled data according to genotypes.

 2

	Genotype	Studies	Pooled data	Heterogeneity
				Inconsistency
		number	O.R.(95%CI)	(Cochran-Q)
				36.92
	All	14	0.35 (0.24-0.51)	I 2 =64.8%
				p=0.0004
				18.05
	Genotype 1	11	0.46 (0.32 -0.66)	I 2 =44.6%
				p=0.05
	Genotype			8.78
		4	0.33 (0.11-0.94)	I 2 =65.8%
	2&3			p=0.03
				2.35
	Genotype 4	2	0.15 (0.05 -0.40)	I 2 =57.4%
				p=0.12
	HOMA cut-			35.9
		10	0.33 (0.20 -0.53)	I 2 =72.1%
	off 2			P=0.0001

Alimentary Pharmacology & Therapeutic

Khattab MA. Targeting host factors: A novel rationale for the management of hepatitis C virus. World J Gastroenterol 2009;15(27): 3471-3479.

Dai CY, Huang JF, Hsieh MY, et al. Insulin resistance predicts response to

Akuta N, Suzuki F, Hirakawa M, et al. Amino acid substitutions in the hepatitis C