Classe Node Q ee 33
We have treated each device as a node within the peer-to-peer network The nodes connect with others through an interface, which we have outlined below This class is designed to implement the declared functionalities and store the properties of a device.
The article outlines key attributes of a node in a network, including its properties and data types The "myIP" attribute represents the node's IP address, while "mySTATE" indicates the node's status as either a super-peer or a peer, using an integer data type Additionally, "myDataList" is a linked list that stores the data associated with the node, and "myProperty" is another linked list that contains the properties of the node itself.
The file name containing the properties of the node is referred to as "myPropertyFile Constant." Additionally, "myMetaDataFile Constant" denotes the file that holds metadata about the data stored on this node Lastly, "myDataDirectory Constant" indicates the directory where the data is located.
The method requestNetworkConnection is executed when the node integrates into the network The addNewData function allows for the addition of metadata to a data list while updating the node's properties To read data, the readDataFromFile method retrieves information from files where node properties or data are stored The writeDataToFile function is used to save data to a file For searching, the searchLocalData method conducts a search for specific data, while deleteLocalData removes local data The addProperty function enables the addition of a property to the node, and removeProperty deletes a property from the node The compareTo method compares the node's properties to a given list, and matchWith aligns the node's properties with a set of predicates.
Classe NodeSkipElement et DataSkipElement
Ce sont deux classes représentant un élément dans une liste 4 saut Comme mentionné, il y a deux listes 4 saut dans notre service : une pour les données et l’autre pour les noeuds
Chaque objet de ces classes a une liste de liens vers les autres éléments
TAB 4.7 — Classe NodeSkipElement et DataSkipElement
Nom du propriété Type de données Description node Node Pour la classe NodeSkipElement : Un noeud
Pour la classe DataSkipElement : Les méta- data Data données d’une donnée , , , nextItem Array Les poiteurs vers les autres noeuds pointerNb int Nombre de pointeurs.
Classe SuperPeer 2 6 ee 34
As outlined in the device classification section, our service consists of super peers and peers The super peer is responsible for conducting data or resource searches This class implements the functionalities defined in the Super Peer Interface.
The property name "headOfDataSkipList" refers to a DataSkipElement, which is a list that facilitates skipping metadata associated with data Similarly, "headOfNodeSkipList" denotes a NodeSkipElement, serving as a skip list for nodes Additionally, "myPeers" is a Hashtable that manages a list of peers.
Contenant les paramétres du my Parameters SystemParameters | systéme présenté dans la classe System Parameters current PointerNb Integer Le nombre maximal courant des liens dans la liste 4 saut
The method processMessage receives and processes broadcast messages from newly connected nodes in the network, determining their status as either peers or super-peers The getMinSuperPeer function identifies the least powerful super-peer, while setSuperPeer establishes a peer as a super-peer The setPeer function designates a super-peer to become a peer For data management, searchDataLocation and searchResourceLocation are used for locating data and resources, respectively The determineSuperPeer method finds the most powerful node to serve as a new super-peer The getDataListOfNode function retrieves the data list stored by a peer, and countNode counts the total number of nodes in the network, whereas countReplica counts the number of data replicas The insertElementToNodeSkipList method adds a new node to the skip list, while removeElementFromNodeSkipList removes an element from the skip list.
Classe Peer 1 ee 35
Most nodes in the network are peers where users manage data and send requests to a super-peer Each peer maintains a list of super-peer addresses but always directs requests to its designated super-peer, which is the first one in the list If the super-peer becomes disconnected, the peer will then seek assistance from the other super-peers.
Attributs Nom du propriété | Type de données | Description superPeerList | LinkedList | Liste d’adresses des super-pairs
The method "sendMetaDataToSPeer" is used to send metadata to a super-peer, while "getSuperPecrList" retrieves the list of super-peers The "requestDataDeletion" method is for requesting the deletion of data, and "requestMemoryRecovery" allows users to request memory space recovery Lastly, "requestDataIntegration" is utilized to request the integration of data.
To declare system parameters such as the maximum number of super-peer pairs, the number of device classes, the device unavailability probability, and the service availability probability, we create a class that reads these parameters from a file on the hard drive This class calculates the standard number of replicas based on the provided probabilities Each super-peer has an instance of this class to consult whenever needed.
~ _-.a.-serrncvxprnsswsessseosune ~Ắ sxseocôerudjikssssứs6ứsss © data: Data = node: Node â nodeinterface: Nodeinterface ứ nodelrderface: Nodelnterface © pointerNb: int © nextitern NodeSkipElemertt â nextitem: DataSkipElemert ứ pointerNt: int
L7 DataSkipElement(in pointerNb: int) o NodeSkipElement(in pointerNb: int)
@ DataSkipElement(in data: Data, in nodeinterface: Nodeinterface, in pointerNb: int) @ NodeSkipElement(in node: Node, in nodelnterface: Nodeinterface, in pointerNb: int)
@ compareTot(in elementCompare: Object): int @ compareTo(in elementCompare: Object): int
,e ] 4 ¢ J © Property — © proName: String © Nodelnterface © proValue: Object
@ proPriorty int @ uploadData(in newData: Data, in fileContent: byte[})
€Ÿ Property(In proName: String, in proValue: Object, in proPriority: int)
@ matchi\Vith(in pre: Predicate): boolean I © compareTo(in pro: Object) int 4 @ Node
1 | Qs my: inetAddress © myProperty: Property
—— Preaay © mySTATE: int © preOperator: Operator © myPropertyFile: String © myMetaDataFile: String ¢ Predicate(in preProName: String, in preProValue: Object, in preProPriority: int, in preOperator: Operator) 5 DataDirectory: String
@& Predicate(in preProperty: Property, in preOperator: Operator)
@ Node(in myState: int, in propertyFileName: String) ôinterfaceằ €Ÿ' Node(in nodelP: InetAddress, in nodeProperty: LinkedList, in state: int) © SuperPeerlnterface @ requestNetworkConnection(): LinkedList
@ printMyDataListQ) © sdtonth pease ice Hees boceen @ addNewData(in newData: Data)
The article discusses various methods related to data management and processing, including searching local data through a predicate list, retrieving a list of super peers, and reading data from a file It also covers functionalities for inserting elements into a data skip list, saving objects to files, and managing new data entries in the skip list with specific node IP addresses Additionally, it highlights the importance of saving properties to files for efficient data handling.
@ receiveMetaDataFromNewNode(in peer: Object) @ deleteLocalDatatin data: Data)
@ removeAlepiicasOtADatsOnSkipLisi(in deta: Data) @ matchvith(in nodePredicateList: LinkedList): boolean
@ removeNonExistNodes(in nonExistNodes: LinkedList) @ compareTo(in nodeCompare: Object): int
@ removeOneReplicaOfDataOnSkipList(in data; Data, in nodelP: InetAddress) :
The article discusses several key functions related to data management, including requesting data deletion, uploading new data, and integrating new data with a specified node IP address It also covers the processes for deleting data and recovering memory associated with a node IP Additionally, the article highlights the importance of managing data efficiently by removing outdated information and ensuring seamless data integration across systems.
@ setNodelinterfaceinSkipList(in nodelnterface: Object) @ _isOnline(): boolean © updateState(in nodelP: InetAddress, in state: int) a oO - © SuperPeer © Peer a headOfDataSkipList: DataSkipElerment ứ superPeerlPList: hetAddress ứ_ headOfNodeSkipList: NodeSkipElemert
The article discusses the implementation of a super peer system using a linked list structure to manage peer connections efficiently It outlines methods for sending metadata to super peers, requesting memory resources, and searching for data locations based on specified predicates Additionally, it details the insertion of new data elements into a skip list, emphasizing the importance of maintaining an organized data structure for optimal performance.
@ insertElementToNodeSkipList(in nodeElement: NodeSkipElement) © removeElementOnDataSkipList(in data: Data) © SystemParameters
@ getDataListOfNode(in node; Node): LinkedList © removeElementFromNodeSkipList(in node: Node) 1 © maxPeerNb: int © countSuperPeer(): int © maxPointerNb: int â determineSuperPeer(): Node ứ replicaStandardNb: ird[]
The article discusses various methods for managing data in a skip list, including functions to insert new data, remove replicas, and read system parameters Key operations include adding new data with `insertNewDataToSkipList`, eliminating unnecessary replicas with `removedAliReplicasOfADataOnSkipList`, and managing individual replicas through `removeOneReplicaOfDataOnSkipList` The functionality to read parameters from a file is encapsulated in the `readParameters` method, which returns a hashtable Additionally, the article highlights the importance of data integration through `requestDataintegration` and computing standard probabilities with the `computeStandardNb` function, which aids in assessing availability and global probability metrics.
@ requestDataDeletion(in data: Data, in nodelP: InetAddress)
@ requestMemoryRecovery(in nodelP: InetAddress): Hashtable
Notre service a été réalisé en Java à l’aide d’Eclipse La figure 4.7 illustre la structure de paquets et des fichiers du code de notre service
Les fichiers dans le paquet data.structure représentent les classes que nous avons présentées dans la partie de diagramme de classes
Les fichiers dans le paquet network.toolkit servent 4 la connexion du noeud au réseau Nous détaillerons la fagon de connexion au réseau dans la partie 4.4.1
Pour le test, le fichier MainProgram.java dans le paquet test.program contient la fonctionnalité principale pour lancer le programme sur un noeud
Le fichier metadata.property contient les méta-données sur les données étant stockées sur ce noeud
Le fichier node.property contient les propriétés du noeud ( espace mémoire, processeur, niveau de mobilité )
The system.parameters file contains crucial system parameters, including the unavailability probability for each class as shown in Figure 3.2, the overall probability, the maximum number of peers managed by each super-peer, and the number of device classes.
The metadata.property and node.property files are frequently updated whenever there is a change in properties For instance, the addition of new data results in a decrease in available memory space, as a new element is added to the data list.
(3) SystemParameters java đủ) Class-Diagram.ucd ®) Class-Diagram.uml
(3) SendThread java (J) UdpReceive.java + (3) UdpSend java
+ BÀ JRE System Library [jre1.6.0_02]
Fic 4.7 — Structure de paquets et des fichiers du code
4.4.1 Connexion au réseau d’un noeud
When a user launches the program on a device, it indicates that a node is entering the network The node broadcasts a message containing the message type, sender address, receiver address, and message data to announce its connection The message type is valued at 10 for a new node connection, while the super-peer's response is categorized as message types 21, 22, 23, or 24, depending on the state of the new node (peer or super-peer).
When all super-peers have reached their maximum number of connections and a new node joins the network, a new super-peer must be selected If the new node has greater capabilities than the current super-peer, it will become the new super-peer (type 21); otherwise, it will simply connect as a peer to the new super-peer (type 22).
In scenarios where a super-peer exists but does not have the maximum number of peers, if a new node is more powerful than one of the existing super-peers, it will take over the role of that super-peer (type 23) Conversely, if the new node does not surpass the existing super-peer's capability, it will become a peer of the super-peer that is lacking sufficient peers (type 24).
The connection message data corresponds to the properties of the node When super-peers receive this message, they utilize these properties to assess and report the status of the new node For each super-peer, a thread is created to handle requests from new nodes.
Peer communication is facilitated through RMI, where each node features an interface that allows it to download data from other nodes and send its properties to a super-peer Super-peers have an additional interface for contacting other super-peers and enabling their peers to reach them In our service, super-peers register in the rmiregistry, storing the interfaces of their peers When a request arises, such as a request for creating replicas, the super-peer searches for resources and returns the relevant interfaces to the requesting node Figure 4.8 illustrates the communication between nodes.
1 tinsertElementToDataSkipList() resourceslnterface +addPeer() uploadDatặ ) ôinterfaceằ
Fic 4.8 — Communication entre les noeuds
+getDataList() NODE 2 : Peer Seadpasc) | +getDataList()
To determine if a peer is connected, it regularly invokes the isOnline() method If the peer does not respond, the super-peer removes this node from the resource list and deletes all replicas stored on that node.
Connexion au réseau dunnœud
Communication entre lesnœuds 38 4.5 Test 2 Q Q Q Q Q Q HQ uc cà cà cv cà cv vn v vn v v v.v v v k v xa 39
Peer-to-peer communication is facilitated through RMI, where each node features an interface that allows it to download data from other nodes and send its properties to a super-peer Super-peers possess an additional interface to connect with other super-peers and enable their peers to reach them In our service, super-peers register in the rmiregistry, storing the interfaces of their peers When a request arises, such as for creating replicas, the super-peer searches for resources and returns the relevant interfaces to the requesting node Figure 4.8 illustrates the communication process between nodes.
1 tinsertElementToDataSkipList() resourceslnterface +addPeer() uploadDatặ ) ôinterfaceằ
Fic 4.8 — Communication entre les noeuds
+getDataList() NODE 2 : Peer Seadpasc) | +getDataList()
To determine if a peer is connected, it regularly invokes the isOnline() method If the peer fails to respond, the super-peer removes this node from the resource list and deletes all replicas stored on that node.
The existence of a super-peer is verified by its peers, each of which maintains a list of all super-peers in the network The first entry on this list is considered the super-peer for the node that holds it This list is updated whenever a new super-peer is introduced or an existing super-peer transitions to a regular peer If a node's super-peer becomes unavailable, the peer will request assistance from other super-peers using the addPeer( ) function A return value of true indicates that the super-peer lacks sufficient peers, allowing the requesting peer to become a new peer of that super-peer If not, the peer must continue to seek out another super-peer until one is found If no super-peer is available, the peer will assume the role of a new super-peer.
We tested our service on a range of desktop computers in the computer lab of the National School of Telecommunications of Brittany Each computer was treated as a device within a household The high-quality ADSL network enabled us to effectively evaluate our service using various data types, including images and audio files In specific scenarios such as node disconnection and role changes, our service successfully met the required standards.
We presented our research on data placement, proposing a software architecture for an adaptive data placement service that determines the creation and deletion of replicas Each component in this architecture addresses the limitations of existing data placement systems By utilizing environmental information, device characteristics, and access frequency for each device, our service can effectively decide when to create or remove replicas.
We proposed a solution to determine the minimum number of replicas based on the mobility level of the device This approach ensures data availability while conserving memory space However, to enhance service performance, it is essential to assign a probability of unavailability to each device class, as illustrated in Figure 3.2 We need to conduct an experimental duration and adjust these parameters accordingly.
We introduced a data structure utilizing a 4-jump list, where the data and nodes possess a set of properties A query is represented by a list of predicates, enabling range value searches and enhancing search speed This structure is independent of the network type, meaning it can be generally applied in any peer-to-peer network, whether unstructured, structured, or super-peer.
We have implemented a prototype that demonstrates the functionalities of our software architecture Although not all components of this architecture are fully developed, this prototype showcases our service's ability to adapt, make decisions regarding data creation and deletion, and determine the number of replicas (the nodes where data will be replicated) However, there are certain limitations that we will discuss in the perspectives section.
We utilized immutable data to avoid issues related to replica consistency management While it would be beneficial to explore the use of mutable data, this approach introduces challenges in maintaining consistency among replicas Additionally, the decision-making process for creation also plays a crucial role in this context.
When creating 40 replicas, it is essential to consider the cost of maintaining coherence This involves striking a balance between the expenses associated with creating replicas and the ongoing costs required to ensure consistency.
We determined the number of replicas based on the device characteristics such as mobility level, memory space, and processor capabilities, without considering the bandwidth between nodes Figure 5.1 illustrates a scenario where the node containing the data is available, but the data itself is not accessible Data A is replicated on two nodes (NODE 1 and NODE 2), which are the most stable and consistently available, ensuring that Data A remains accessible on the network at all times.
Le nccud NODE 3 a besoin de la donnée A mais la bande passante entre le nceud NODE
Three nodes are strong, while the other two are weaker and unable to transmit data to the nodes that require it In the future, our service must be able to determine when to create replicas on the nodes to ensure that these replicas are accessible to all nodes within the network.
J’ai besoin de la donnée A
Fic 5.1 — Disponibilité de la bande passante
Another improvement relates to the decision to create replicas In our service, replicas are generated within a single class (as shown in Figure 3.2) If the number of nodes in the class containing the more stable devices is insufficient, we will proceed accordingly.
In a less stable class, if there is insufficient memory space in the more stable class, we will create multiple replicas within the less stable class Regardless of the situation, our service must ensure the overall availability of data.
Dynamic adaptation is crucial for the future evolution of our system In the coming years, data placement algorithms will be implemented and stored in a directory Based on the system's context, the most suitable and efficient algorithm will be utilized In other words, our service must operate independently of the data placement algorithms.
Enfin, notre prototype est pour l’instant exécuté par les lignes de commandes Nous voulons construire une interface pour faciliter utilisation
[AMPV06] R Akbarinia, V Martins, E Pacitti, and P Valduriez Global Data Manage-
Anne Benoit Algorithmique des réseaux et des télécoms ENS Lyon, M1, 2006
A Beloued, J M Gilliot, F André, and M.T Segarra Context-aware replica- tion and consistency The 2nd International Middleware Doctoral Symposium, IEEE Distributed System Online, 7(2), 2006
G Coulouris, J Dollimore, and T Kindberg Distributed Systems Concepts and Design ADDISON WESLEY, fourth edition, 2005
I Clarke, 5 Miller, T.W Hong, O Sandberg, and B Wiley Freenet : A distributed anonymous information storage and retrieval system In Designing Privacy Enhancing Technologies, July 2001
I Clarke, S$ Miller, T.W Hong, O Sandberg, and B Wiley Protecting free expression online with freenet IEEE Internet Computing, January 2002
R Guerraoui, S B Handurukande, and A M Kermarrec Gosskip : a gossip- based structured overlay network for efficient content-based filtering Technical report, EPFL, Switzerland, 2004
N J A Harvey, M B Jones, S Saroiu, M Theimer, and A Wolman Skipnet :
A sacalable overlay network with practical locality properties In Proceedings of USITS, 2003