A Catalog-Based Caching Strategy for

Structured P2P Systems�

Mile Arnedo1, Maria del Pilar Villamil1, Ricardo Villanueva1,Harold Castro1, and Laurent d’Orazio2

1 University of Los Andes - Colombia2 University Blaise Pascal - France

{mj.arnedo45,mavillam,rl.villanueva46,hcastro}@uniandes.edu.co,laurent.dorazio@isima.fr

Abstract. Cache attempts to improve performance in P2P systems inthree ways: improve response time, availability and load balancing. De-spite their benefits, some proposals are very coupled with the applicationlevel and cannot be easily implemented in other environments, other usepre-defined structures difficult to maintain, or assume peers are phys-ically homogeneous. So, the search for portable and flexible strategiesremains an open problem. In this paper we present a caching strategy forimproving response time during a query execution using a catalog withinformation of neighbors cached items, allowing the interaction betweendifferent cache levels. A performance evaluation using grids is providedto verify the improvement achieved.

1 Introduction

Performance in loosely coupled distributed systems is affected by the distributionof data among nodes. P2P systems are a special class of distributed systemswhere data distribution is typically achieved with no knowledge of the applicationaccess patterns. Thus, performance is highly fluctuant as the cost of accessingdata across the network can be higher than the processing of such data in aparticular node.

Cache systems have been proposed as a way to alleviate the impact of datalocation on P2P systems. Caching is an efficient solution as it improves dataaccess times, makes data more available across the network and offers load bal-ancing. Nevertheless, to configure and implement cache in P2P systems is notan easy task. There are several decisions involved in its construction: contentmanagement, admission/replacement policies and resolution protocol are someof them. We are particularly interested in resolution protocols because they arefundamental for improving the query execution process.

The resolution protocol describes a “topology” between peers to obtain itemsrelated to a query, reducing the number of contacted peers in a traditional queryprocess. Every caching solution defines a resolution protocol based on the re-quirements of the application or the underlying P2P system.� This research was supported by the project Ecos-Colciencias C06M02.

A. Hameurlain, F. Morvan, and A. Min Tjoa (Eds.): Globe 2010, LNCS 6265, pp. 50–61, 2010.c© Springer-Verlag Berlin Heidelberg 2010

A Catalog-Based Caching Strategy for Structured P2P Systems 51

Works in cache can be analyzed according to two criteria: coupling and adap-tation levels. Several works, despite the achieved performance improvements, aretightly coupled with the application level making the portability hard to achieve.In terms of adaptability, such proposals use context/query information to pro-vide a more suitable solution to a specific problem. Other works use pre-definedstructures for the resolution protocol, which makes these systems very difficultto maintain as they evolve. More general proposals take into account currentcontext information, but they assume peers are theoretically homogeneous anddemand the use of a certain amount of resources which some peers cannot offer.This situation motivates the search for portable and flexible caching strategies.

This paper presents a catalog-based caching strategy that maintains a highlevel distributed catalog with information related to items cached by other peersin the system in order to decide, in run-time, the best resolution protocol to beapplied. The proposal is based on the protocol described in [4], but the maindifference is that decisions within a peer are based on indirections using thefunctional hierarchic level of the catalog information.

This paper is organized as follows. Section 2 illustrates some resolution pro-tocol styles. Section 3 presents the catalog-based caching strategy. Section 4presents the performance evaluation and analysis obtained in a large-scale envi-ronment. Finally, Section 5 concludes and gives perspectives on the future work.

2 Resolution Protocol Styles

This section proposes a resolution protocol classification based on the changesto the lookup process. Two styles were identified: (1) strategies that do notchange the process and (2) strategies changing the process, described respectivelyin subsections 2.1 and 2.2. Each style is analyzed according to four criteria:(1) resources needed, (2) cache admission protocol, (3) impact on the queryresolution process, and (4) maintenance process.

2.1 Strategies That Do Not Modify the lookup Process

These strategies try to reduced the time needed for the lookup process usingthe information of the path convergence without affecting the traditional lookupprocess. They attempt to find items during the lookup process without reachingthe owner, using the propagation of replicas on peers where lookup queries aremore frequently routed and/or peers capable of handling the load associatedwith the corresponding cached item.

The idea is to place replicas in peers that are increasingly away (one, two hops,and so on) from a node, until all replicas are placed, as shown in Fig. 1(a). When aquery arrives at a node A, it will find the object using the typical lookup process.Works using this style can be found in [7] and [9]. The associated maintenance isbased on the reassignment of replica items, when nodes join/leave the network,using the stabilization protocol defined by the underlying system.

52 M. Arnedo et al.

(a) Routing (b) Query (c) Interaction

Fig. 1. Resolution Protocol Styles

2.2 Strategies That Modify the lookup Process

These strategies also try to reduced the time needed for the lookup process butat a higher cost, because they use some additional information related to thequeries or the current environment. As a result, they modify the lookup processdefined by the underlying system. Here, two styles are distinguished: based onquery information and cache level interaction.

Based on Query Information. These strategies aim to provide a semanticlookup process based on past queries. The basic idea is that results of previousqueries are cached separately, so they can be used to answer the original andother queries. To achieve this they use a tree, where each vertex corresponds toa peer responsible for storing the result of a previous query and also, a catalogwhere it maintains information of sub/super queries as seen in Fig. 1(b).

So, when a query Q arrives at a node A, it looks for the responsible for Q. Iffound, it is returned. Otherwise, partial results can be found moving along thetree. Works using this information are described in [1] and [6].

For the first, the number of attributes in the domain indicates the number ofpeers at depth one in the tree. Thus, if the domain is large, the tree may notbe easily maintain. The maintenance of the tree consists in: detecting when anew query has arrived, converting it into Conjunctive Normal Form (CNF ) andappend it to the current tree. As a result, every time a new query appears, theabove operations need to be performed. The amount of maintenance operationsdecreases when many different queries have been executed.

The second strategy implements a variation in the process of caching, whereseveral nodes collaborate to decide what should be cached. The maintenanceof this tree is performed each time a join/leave is detected in order to reassignresponsibilities for specific queries.

Based on Cache Level Interaction. These strategies use the additional in-formation to provide knowledge to the process of deciding which peer shouldbe visited next in case of a miss. They try to improve efficiency through theinteraction of different levels as shown in Fig. 1(c).

A Catalog-Based Caching Strategy for Structured P2P Systems 53

Table 1. Summary of Resolution Protocol Styles

Style Additional Admission Modify Lookup Maintenance

Resources Protocol Process

Routing based None Cacheable condition No Periodic (join/leave)

Query Sub/super query Past Periodic

based information queries Yes (join/leave-new queries)

Level Information related to Periodic

Interaction the next node to visit Tunable Yes (changes in the system)

When a query arrives at a node A, the path chosen can be defined in threeways: pre-defined (configure by the application developer), tuned (periodicallyre-defined according to changes in the application/system) or in runtime (basedon decisions over a set of candidates).

ACS is a framework to construct cache services [2]. Particularly, it implementsa dual cache (two-level cache): at the object layer (object cache), matching idsto objects, and at the query layer (query cache), managing results of previousqueries.

The decision process is ruled by the information it obtains from its local cacheand search only for the rest according to a proximity relation. The maintenanceassociated to this strategy is defined by the relation between caches when a newquery arrives. Here, when the result is obtained, an entry in the query cachemust be added, and objects satisfying the query must be admitted to the objectcache, but without maintaining synchronization between them.

Another strategy using cache level interaction is called DHTCache [5], an in-dependent distributed cache service that distinguishes cache levels at the lookupand storage layers. The variation compared with ACS lies in the fact that thiswork also involves the interaction with the traditional lookup process. In thisway, when a miss occurs in cache, the information of the underlying system isused, in terms of exhausting the local knowledge of a peer. Then, if the processfails to satisfy the answer, other peers are contacted using the proximity relationdefined. The maintenance process associated to both strategies is related to theinformation about the the next peer to be visited.

2.3 Discussion

Every caching solution defines a resolution protocol in three ways: pre-defined,tuned or at runtime. In the first, the process is restricted and it cannot takeadvantage of current system characteristics. The second reduces this problem,but as the process is performed periodically, current characteristics are still nottaken into account. The topology defined by the resolution protocol should fitin a better way the current system characteristics and application requirements.

Table 1 summarizes the resolution protocol styles presented above. The firststyle can be adapted mostly to all structured overlays because they are notcoupled to the underlying routing protocol and do not change the lookup process.But, as P2P systems are heterogeneous and dynamic, with a single level cacheapproach is not easy to achieve high performance.

54 M. Arnedo et al.

Fig. 2. Peer Routing Table using Chord

The second style modifies the traditional lookup process with the aim of pro-viding a more suitable execution process based on the current characteristics ofthe system. But, the ones based on query information are tightly coupled withthe application level and use pre-defined structures not easily maintained.

In this way, resolution protocols based on cache level interaction are moreadequate to take advantage of current system characteristics. Most works as-sume some equivalence between physical resources of different peers. But, in anydistributed system, peers could be heterogeneous or not willing to cooperate(free-riders), which eventually can weaken the strategy implemented.

3 Catalog-Based Caching Strategy

Cache sharing protocol has proven to be effective for reducing network conges-tion and bottlenecks [4]. This paper describes a strategy based on this protocol,using a high level catalog that helps to decide in run-time, the resolution pro-tocol. This strategy profits of the existence of distributed caches at differentfunctional levels for improving efficiency during a query execution. So, decisionswithin a peer are based on indirections using the functional hierarchic level ofthe catalog information, guaranteeing that the path created is at most equal tothe traditional DHT path. Subsections, 3.1, 3.2 and 3.3 describe the catalog, thequery execution and the maintenance process of the strategy respectively.

3.1 Catalog Description

For this strategy every node implements cache at the lookup layer and storesinformation related to the cache implemented by its neighbors. This informationcan be included in any node independently of the underlying DHT-based system.On the one hand, cache at the lookup layer aims to reduce the time needed tocontact a peer. The cache entries can be related to popular or representativespeers from distant zones. On the other hand, the catalog information associatedwith neighbors caches aims to reduce the amount of time needed to find an item(peer, objects or query results). There are no restrictions about the number ofcaches provided by a peer.

A Catalog-Based Caching Strategy for Structured P2P Systems 55

Let us consider a P2P system using Chord [10] as the underlying DHT-basedsystem. Fig. 2 shows a peer extending its routing table and including the newinformation. This figure differentiates three zones. Zone A contains traditionalfingers in Chord. Zone B has the additional fingers (cache at the lookup layer)and Zone C has the catalog information of each neighbor cache. Each entry inthe Zone C is a pair < type, id1, id2, · · · , idn >, where type and “id” semanticrelates to the functional level of cache implemented by the corresponding peer.

3.2 Query Resolution

An important feature of this work is the way it uses the local catalog informationto resolve three types of queries: (1) peer contact information, (2) object retrieval,and (3) query execution.

This strategy allows the fast location of items based on indirections using thefunctional hierarchic level of the information maintained in the catalog. So, apeer performs an exhaustive search within its catalog to locate items, or to findinformation related to the responsible for an id locally1. If found, it is returned,and this way, latency is reduced. Otherwise, the next decision is related to finda closer peer containing the requested information2.

For the process of object retrieval, a peer attempts to find, first the actualobject, and if not found, locate the owner of the requested object. For the pro-cess of query resolution, a peer tries to find, the complete/partial results of therequested query. Then, the objects satisfying the query, and finally, the ownerof the corresponding objects. It is important to mention that this process canbe decomposed to search each term in the query separately.

Additionally, the process must decide whether to route a message to a peerwithout the complete certainty of that peer being still available. The idea isto maintain the same tolerance as the one provided by the underlying routingprocedure. Two strategies can be implemented in this situation.

1. If there are other candidates, re-send the request to one of those peers.2. If there are no more candidates, choose the peer ruled by the traditional

routing process.

Now, as the process of peer contact information and object retrieval are similar,only two examples are going to be presented: one for the process of object re-trieval, and other for the query execution process. From the foregoing, type 1, 2,and 3 represent cache at the lookup, object, and query layers respectively andN1 is chosen as the access peer.

Object Retrieval. Fig. 3(a) shows the object retrieval process, where N1 mustdecide what to do in each of the following cases.

1 The id semantic varies according to the corresponding functional level of cache.2 It is possible to find part of the requested information. In this case, the process will

only required to search for the rest.

56 M. Arnedo et al.

(a) Routing-based (b) Query-based

Fig. 3. Resolution Process

Case I: Looking object O6. Resolution within its local cache.

1. Verify if O6 appears in its local type 2 cache. If founded, return O6.2. Verify if the owner of the object (N6 ) appears in its local type 1 cache. If

founded, send the request to N6.

Case II: Looking object O4. Resolution using the catalog information.

1. Verify if any peer with type 2 cache have O4. If founded, each peer will beconsidered as a candidate.

2. Verify if any peer with type 1 cache have the owner of the object. If founded,each peer will be considered as a candidate.

Peer N1 must decide between candidates collected during the resolution of CaseII. In this way, the decision can be configured by an administrator or it canbe associated to three criteria: (1) replacement policies of the correspondingcache, (2) time since the last local maintenance process was executed, and (3)cache type. If both cases fail to provide a answer/candidate to the requester,the process will choose the peer ruled by the routing procedure defined by theunderlying system.

Query Execution. Fig. 3(b) shows the query execution process, where N1must decide what to do in each of the following cases.

Case I: Resolve query Q22 = Q12 ∨ Q3. Resolution within its local cache.

1. Verify if Q12 appears in its type 3 cache. If found, return the correspondingresults.

2. Verify if either Q12 and/or Q3 appear in its type 3 cache. If found, returnthe corresponding results. If needed, the rest of the query will be executedusing the catalog information.

Case II: Resolve query Q20 = Q8 ∧ Q6 Resolution using the catalog information.Assume neither Q20, Q8 and Q6 appear in its local cache.

A Catalog-Based Caching Strategy for Structured P2P Systems 57

1. Verify if any peer with type 3 cache have Q20. If found, each peer will beconsider a candidate.

2. Verify if any peer with type 3 cache have either Q8 and/or Q6. If found, eachpeer will be consider as a candidate.

Again, the decision between candidates can be performed using the criteria pre-sented earlier, and if both searches fail, choose the peer ruled by the routingprotocol.

3.3 Maintenance

In order to reduce the impact on performance, the idea is to provide a certainconsistency level between the information in the local catalog with the neighborsactual caches, by updating periodically the catalog information.

In this way, the process can incur in two types of errors: (1) false miss, therequested item is cached at a neighbor, but the local catalog does not reflect it,and (2) false hit, the requested item is not cached at a neighbor anymore, butthe local catalog reflects the opposite. The idea is to obtain the least amount offalse hits during the process.

During the stabilization protocol, the idea is for each peer to piggyback itscached information to all of its neighbors, only when it has changed. As a result,no additional messages are needed, and the increment in message size is nothighly impacted.

4 Performance Evaluation

This evaluation has three main objectives: first, show the impact of cache at thelookup layer over the query execution process, second, visualize that the timeneeded to resolve a query is at most equal to the one of the traditional queryprocess, both proven under a stable environment (scenarios 1 and 2). The thirdobjective is to evaluate cache invalidation. Subsections 4.1, 4.2 and 4.3 explaineach respectively.

1. Scenario 1 (Number of Peers): The scenario consists in deploying up to 2000peers in 30 physical nodes with 2000 objects. Each object has 5 meta-dataassociated which gives a total of 10000 items stored in the system.

2. Scenario 2 (Number of Items): The scenario consists in deploying 2000 peerswith up to 2000 objects in 30 physical nodes.

Caches at the lookup and query layers where constructed under the followingdecisions: (1) replacement policy: first in, first out (FIFO), (2) size: up to 5items. According to the results presented in [3], log(N) additional entries aremaintained in the cache at the lookup layer, where N is the number of peers.

58 M. Arnedo et al.

(a) Number of Peers (b) Number of Items

Fig. 4. Single Cache Implementation

(a) Number of Peers (b) Number of Items

Fig. 5. Two-level Cache Implementation

4.1 Cache at the Lookup Layer

To illustrate the impact of cache at the lookup layer, the idea is to comparethe same scenario using a single level of cache with one without cache. Then,compare these results with one scenario using two levels of cache.

Fig. 4 shows the percentage of profit earned between single cache strategiesand the one without cache while incrementing number of peers and items. Fig. 5shows the percentage of profit earned between single cache strategies and theone using cache at the lookup-storage (LS) and lookup-query (LQ) layers, whileincrementing the number of peers and items.

In Fig. 4 is evidenced that both, cache at the lookup and query layers offerhigher benefits, but the latter at a higher cost, because the amount of spaceneeded to store results of a query is in most cases, larger to the one needed tostore entries in the routing table.

In Fig. 4(b), is difficult to decide between the implementation of a single levelof cache, because the profit obtained using cache at the storage and query layersoverlap in two points (2500 and 7500 items). In Fig. 5(a) is evidenced that theprofit obtained using two-level cache is up to 18% above the gain obtained usinga single cache level. It is important to mention that the implementation of cacheat the lookup layer requires additional space, but the benefits achieved supportthis decision.

Strategies are scalable in terms of items, because the profit is not affected byits increment. In fact, using lookup layer reduces the impact of the number ofitems in single cache because this cache level is not affected by this information.In the case of (LS/S) the improvement is higher because the process will findobjects during the path, and for the rest, it will use the information maintainedby the cache at the lookup layer.

A Catalog-Based Caching Strategy for Structured P2P Systems 59

(a) Number of Peers (b) Number of Items

Fig. 6. Catalog-based Strategy vs. Traditional Strategy

4.2 Strategy Performance

To illustrate the improvement achieved by the strategy, the idea is to compare thetime of a query execution between the catalog-based and traditional strategies.Here, two processes were measured: object lookup and query execution. For thefirst, only caches at the lookup and storage layers were implemented. For thesecond, only caches at the lookup and query3 layers were implemented. Fig. 6shows the profit earned while incrementing the number of peers and objects.

As seen in Fig. 6, for both processes, the catalog-based strategy outperformsthe traditional strategy. This is evident because the combination between cachelevels improves the time needed to execute a query in the following way: Iflooking for an object, the process takes its decision based on locating the objectwithin its cache or a neighbor cache, always choosing a closer node. If not found,it additionally asks for the responsible of storing that object. In this way, theprocess exhausts both possibilities each time the question reaches a new peer.

Again, if executing a query, the process takes its decision based on the hierar-chic level defined in the previous section. As partial results can be found alongthe path, the process profits from the answer/candidate obtained in each cachelevel.

4.3 Cache Invalidation

The efficiency of this strategy is affected by two aspects: (1) replacement policiesof neighbor caches, and (2) churn rates. On the one hand, the replacement policyplays an important role when concurrent queries are executed, because it definesthe time an item remains in cache. As the stabilization protocol is performedperiodically, the time difference between these two values affects the number offalse hits during the process. On the other hand, when peers leave the system,the query execution process can suggests visiting peers that are no longer partof the system, which represents an extra message.

The following scenarios were deployed for each case.

1. Scenario 1 (Policy): Deploy 2000 peers with 2000 objects in 30 physicalnodes modifying with FIFO as the replacement policy for all cache levels.

2. Scenario 2 (Churn): Deploy 2000 peers with 2000 objects in 30 physicalnodes modifying churn rates between 10 and 40%.

3 Cache at the query layer was implemented storing partial results of a query inaddition to the complete result.

60 M. Arnedo et al.

Replacement Policy. To illustrate the impact of the FIFO replacement policyover the catalog-based strategy, the idea is to count the number of queries that donot incur in false hits while concurrent queries are being executed. Observationsshowed that the number of false hits increases due to the fact that changes inneighbors caches are faster than the time interval of the stabilization protocol.This observation suggests that there should be a balance between these times sothe strategy is not highly affected.

Churn. To illustrate the impact of churn rates over the catalog-based strategy,the idea is to count the number of queries successfully executed while churnis being induced over a period of time. As said in Section 3.2, the idea is tomaintain the same tolerance during join/leave of peers, as the one provided bythe underlying routing protocol.

It is clear that the number of false hits during a period of time increases inthe same way as the churn rate. But, once the stabilization protocol is performedthe values are refresh and the false hit problem is mitigated.

5 Conclusion

Time-changing environments related to the inherent dynamism of P2P systemsand the diversity of queries make it difficult to construct caches. Several pro-posals using static resolution protocols or routing/query information to providemore dynamic decisions have been proposed. However, peers autonomy and het-erogeneity are important in the process of cache construction.

This paper proposes a catalog-based caching strategy using the sharing cacheprotocol that describes the interaction between different cache levels, both lo-cally and distributed without any restriction on the caches each peer have toimplement, to define the resolution protocol in run-time.

Two aspects contribute to the low overhead of the strategy: the catalog isupdated periodically and the amount of space used is not large. It is importantto mention that the strategy is not coupled to a single DHT-based system. So,the catalog can be included in any node independently of the system.

As the strategy demands the implementation of cache at the lookup layer,results has shown that it provides a considerable profit during the query execu-tion. Additionally, the impact over the other cache implementations is evidentbecause it helps to obtain an additional profit (up to 18%) to the one with thesingle-cache implementation. Moreover, it is not highly affected by the incrementin number of items because it does not use this information at all.

Also, the performance evaluation showed that the catalog-based strategy out-performs the traditional strategy and obtains a profit of 50% at most. This isthe result of the combination of different cache levels in such a way, that a peerexhausts its local knowledge in each cache level in order to take better decisions.In terms of cache invalidation, false hits can be mitigated using an adequatevalue for the stabilization protocol and the corresponding replacement policies.

A Catalog-Based Caching Strategy for Structured P2P Systems 61

Questions related to decide which cache level combination is the more prof-itable using the catalog-based strategy, remains open. As decisions within a peerare based on three criteria, it would be important to show which decision betterfits the strategy. Moreover, for the replacement policies, to know which policyworks best for the strategy.

Additionally, assuming that free-riders participate in the routing process, theimpact over the strategy is not high only if the fraction of these peers is small.It is important to mention that if these peers do not implement any cache level,their corresponding entry in its neighbors routing tables will be empty, andwill only be taken into account as the traditional routing process. It would beinteresting to use reputation systems to mitigate the impact of this peers whenthe fraction is not small.

References

1. Bhattacharjee, B., Chawathe, S., Gopalakrishnan, V., Keleher, P., Silaghi, B.: Ef-ficient peer-to-peer searches using result-caching. In: Kaashoek, M.F., Stoica, I.(eds.) IPTPS 2003. LNCS, vol. 2735, pp. 225–236. Springer, Heidelberg (2003)

2. d’Orazio, L., Jouanot, F., Denneulin, Y., Labbe, C., Roncancio, C., Valentin, O.:Distributed semantic caching in grid middleware. In: Wagner, R., Revell, N., Per-nul, G. (eds.) DEXA 2007. LNCS, vol. 4653, pp. 162–171. Springer, Heidelberg(2007)

3. Deb, S., Linga, P., Rastogi, R., Srinivasan, A.: Accelerating lookups in P2P systemsusing peer caching. In: ICDE 2008, pp. 1003–1012. IEEE, Los Alamitos (2008)

4. Fan, L., Cao, P., Almeida, J., Broder, A.: Summary Cache: A scalable wide-areaweb cache sharing protocol. In: SIGCOMM 2000, pp. 281–293. IEEE, Los Alamitos(2000)

5. Gomez, C.E., del Pilar Villamil, M., Castro, H.E., d’Orazio, L.: DHTCache: Adistributed service to improve the selection of cache configurations within a highly-distributed context. In: Hameurlain, A., Tjoa, A.M. (eds.) Globe 2009. LNCS,vol. 5697, pp. 48–59. Springer, Heidelberg (2009)

6. Qian, W., Xu, L., Zhou, S., Zhou, A.: CoCache: query processing based on col-laborative caching in P2P systems. In: Zhou, L.-z., Ooi, B.-C., Meng, X. (eds.)DASFAA 2005. LNCS, vol. 3453, pp. 498–510. Springer, Heidelberg (2005)

7. Rao, W., Chen, L., Wai-Chee, A., Bu, Y.: Optimal proactive caching in peer-to-peer network: analysis and application. In: CIKM 2007, pp. 663–672. ACM, NewYork (2007)

8. Rowstron, A., Druschel, P.: Pastry: Scalable, decentralized object location, androuting for large-scale peer-to-peer systems. In: Guerraoui, R. (ed.) Middleware2001. LNCS, vol. 2218, pp. 329–350. Springer, Heidelberg (2001)

9. Sanchez-Artigas, M., Garcia-Lopez, P., Skarmeta, A.: On the relationship betweencaching and routing in DHTs. In: WI-IAT 2007, pp. 415–418. IEEE, Los Alamitos(2007)

10. Stoica, I., et al.: Chord: a scalable peer-to-peer lookup protocol for internet appli-cations. In: TNET 2003, pp. 17–32. IEEE, Los Alamitos (2003)