In this paper, we present extensions of JXTA protocols to support file sharing in P2P systems with the aim of overcoming the limitations of server-mediated approaches. The empirical study revealed advantages and disadvantages of using the JXTA protocol for P2P file sharing systems. One of the main concerns. Peer-to-Peer (P2P) systems have become popular due to file sharing between millions of users worldwide.
Indeed, there are still many issues that need to be better understood and addressed in the P2P file sharing domain. In fact, there is a whole range from server-mediated architecture P2P systems to fully decentralized systems, and appropriate architectures that match different needs of P2P file sharing applications need to be investigated. Furthermore, these file-sharing programs use a centralized architecture that requires either a server or a very special node to manage the entire network.
Motivation
P2P networks are the alternative to the traditional client-server applications by replacing client-server communication with peer interactions; Peers can serve as clients, servers, edge peers, giving much more flexibility; a peer can request files from others and share files with other peers. In the domain of P2P protocols, JXTA technology [4], [6] is an interesting alternative in the field of file sharing, as its protocols allow the development of P2P platforms, either pure or mixed. This feature is certainly important, since pure P2P does not need the presence of a server to manage the network.
Unfortunately, JXTA protocols do not support file sharing, however it provides a number of basic protocols, such as ad publishing, that can be further developed and used for file sharing purposes.
Problem Statement and Objectives
CHAPTER
LITERATURE STUDY
- What is P2P ?
- P2P Concepts
- Peer to Peer Routing
- Architecture
Each peer in a network can act as one or more peer types, with each type specifying a different set of responsibilities for the peer to the P2P network as a whole. A simple peer is designed to serve a single end user and allows that user to provide services from their own device and consume services provided by other peers in the network. Peers issue discovery queries to a peer for a meeting, and the meeting provides information about the peers it knows on the network.
A router peer provides a mechanism for peers to communicate with other peers separated from the network by a firewall or Network Address Translation (NAT) equipment. The capabilities of this service will be unique to the peer and will only be available when the peer is connected to the network. As long as one member of the peer group is connected to the network and providing the service, the service is available to the peer group.
Peers: A peer needs an identifier that other peers can use to locate or specify it on the network. Pipes: To enable communication, a peer needs a way to identify a pipe that connects endpoints on the network. The last two techniques involve connecting to the network to perform discovery and are considered active discovery techniques.
The possibility that cached ads become obsolete and describe resources that are no longer available on the network. Page | 16 the network he knows about, including other meeting peers who also spread the request to other peers. Cached Ads - In the same way that regular peers can use cached ads to reduce network traffic, a meeting can use cached ads to answer a peer's discovery questions. . Scalability: a measure of how well a system performs when the number of nodes and/or the number of messages in the network increases.
Join and Leave: Upon joining, a node hashes its IP to form a number and sends a request to any node on the network to find successor(number). In this way, SRDI can answer ad requests in the network by locating the peer that has the desired ad. The query is resolved by the network (actually the rendezvous super-peer network) by hashing the key to the required value.
JXTA Protocols
CHAPTER 3
EXTENSION OF JXTA PROTOCOLS
Publishing of the advertisements: In the JXTA- Overlay, the file advertisements are sent very frequently (within very short time intervals) and
This is done to ensure that only online peers have active advertisements. However, if a peer shares a large amount of files, the file advertisement will be large and computationally expensive to publish and handle; again, publishing the file ad very often can certainly be problematic. Our solution is that the file advertisements should be sent periodically at quite long time intervals, which solves the large number of files to be processed.
However, ads with this specification must have a longer lifetime, which means that if a peer goes down, its ads continue on the network. To solve this problem, we use broker peers: whenever the broker works with ad files, it always checks if the user is connected, thereby verifying the existence of the info ad (and its main attributes), which each peer sends to the network to report, that it is online. The main peerGroup is a NetPeerGroup to which connection is made according to the equivalent configuration: (a) connection to the default JXTA meeting.
This is certainly inefficient as we cannot control the meeting; (b) connection with the meeting predetermined by the specific JXTA application; (c) relating to the appointment specified in an appointment list. In this later case, the JXTA application simply needs to know the address where it can find the appointment list. Note that the meeting list can be changed independently of the application, which is desirable in P2P applications.
Page | 30 main peerGroup, any peerGroup can join if it knows the GroupAdvertisement of such groups. But for this to be possible, there must be peerGroups, there must be at least one meeting, and GroupAdvertisements must be propagated. In our peer-to-peer P2P network of brokers and customer peers, brokers are network managers and group organizations.
So broker peers are in charge of creating the groups and distribute the Group Ad accordingly.
CHAPTER 4
IMPLEMENTATION DETAILS
- Required Components
- Implementation Steps
- Results
- CHAPTER 5
JXTA's core uses 13 other JAR files such as Jetty portable Web/Servlet Server, Log4J apache's generic logging API. New ad types must be registered with the AdvertisementFactory by extending META-INF/services/net.jxta.document.Advertisement. If the peer finds the matched group, it joins, otherwise it creates a new group and publishes its advertisement in the network.
If the user passes the membership validation, they join the group and publish their ad. When the user shares a file, the overlay calculates its full attribute and saves the configuration to the file ./userData/username/clientConf/groupname. The next time the peer joins the overlay, this configuration is loaded and the files are checked for possible changes.
At each predetermined time interval (15 minutes in our program), information about shared files is collected in advertisements published on the network. A user can search for a file with some specific parameters (filename) with the goal of finding specific files that are shared on the network. After the user enters the parameters, the peer client sends this request to the peer group broker.
After receiving the request, the broker will find in the appropriate advertisements all the files that the users share, according to the search parameters. Page | If a broker finds it, it means the peer is connected, because peer info ads have a very short lifespan. Once the broker checks a peer's advertisement, it starts checking one by one all the files that this peer has shared in this peer group and stores in a list all the files that have all the attributes that the user requested.
It then sends the complete list of found files to the requesting peer, which displays this information to the user in a table from which the user can request to download different files.
Conclusion and Future Works
Page | 42 In this thesis, we presented extensions of JXTA protocols to support the development of file sharing systems in JXTA-based P2P applications. The extension of JXTA's core protocols required the definition and management of file advertisements to enable file sharing and efficient file searching. File advertisements can impose a significant computational burden on peer brokers due to the large size of file advertisements and the large amount of file advertisements published by different peers that need to be processed by the broker.
Another important issue is the lifetime of file advertisements to increase the reliability of the file systems in the P2P network. Admittedly, short lifetime values would imply very frequent posting of ads, which in turn could provoke broker colleagues to collapse; on the other hand, large values of the lifetime would imply. Our approach proposes a separation of types of advertisements into peer proper information ads, file ads, and group file ads.
This separation allows the lifetime parameter to be fine-tuned accordingly depending on the ad type. With this approach, we can relieve the computing load of the intermediary and increase the reliability of file systems in the P2P network. We investigated the approach experimentally by deploying a JXTA-based P2P network in a small LAN of our institute.
In our future work we plan to complete the experimental study considering a larger P2P network (PLANET LAB). Also, we would like to study the differences between P2P file sharing and web traffic of server-mediated file sharing approaches, which may reveal important differences in both approaches. In the same context, it would be interesting to study the potential bandwidth savings in JXTA-based P2P file sharing architectures.
Finally, we are interested in using our JXTA-based P2P file sharing system to support collaboration between online teams on our virtual campus.