Submitted by:Inna Gelfer Lily Itkin

Vladimir Shulman Ziv Rabizanovich

Table of contentsTable of contents..................................................................................................................2Introduction..........................................................................................................................3Software & Hardware properties & requirements...............................................................5Project design.......................................................................................................................6

GUI design.......................................................................................................................8Map Layer..........................................................................................................................10

Map main flows.............................................................................................................11Load Region...............................................................................................................11Get Item.....................................................................................................................11Change Item...............................................................................................................11

BackGroundManager.........................................................................................................12BackGroundManager flow............................................................................................12

Application........................................................................................................................13Components...................................................................................................................13Class Diagram................................................................................................................13

b2b.application Class Friend....................................................................................13b2b.application Class User.......................................................................................13b2b.application Class LocalConfiguration...............................................................14b2b.gui Class ApplicationGui...................................................................................15b2b.gui Class ChatManager......................................................................................15b2b.gui Class GeneralMapGUI................................................................................16b2b.gui Class GuiManager.......................................................................................16b2b.gui Class HouseItemGUI...................................................................................17b2b.gui Class MapGUI.............................................................................................17b2b.gui Interface RemoteGuiManager.....................................................................17

System main flows.........................................................................................................18Login..........................................................................................................................18Logout........................................................................................................................18Goto...........................................................................................................................18

Chat Feature.......................................................................................................................19Sip..................................................................................................................................19Proxy..............................................................................................................................20Messenger......................................................................................................................21

Network Layer...................................................................................................................22Overview........................................................................................................................22Design decisions, principles and considerations...........................................................22Class diagram.................................................................................................................24Flows..............................................................................................................................28

Join.............................................................................................................................28Find Node..................................................................................................................28Leave..........................................................................................................................29Add/Remove item......................................................................................................29Find items..................................................................................................................30

Bibliography......................................................................................................................31

Introduction

In the present time, a lot of machines are connected to the Internet, some of them are providing a lot of services to a lot of endpoints, they are large and powerful, and some of them are small, used by one user at the time, this type is the most common one. These kinds of machines are called Servers and Clients, respectively. The client machines, when connected among them, can provide services to different amount of users and devices at the same time.

This powerful structure can be very useful in a lot of ways, and many initiatives were made in order to take an advantage of such a structure. There are several ways that it can be done – on hierarchical base, managed centrally; or collaborative basis, with no centralization and small amount of coordination from central location. P2P is a technology, which uses the second way.

Some of the preceding technologies are:

Star Topology, associated with Master-Slave Architecture Intra-Organisational Client-Server Architecture

Internet-Mediated Client-Server Architecture

Those technologies raised some serious problems, which was solved by P2P.

lack of robustness lack of resilience

lack of scalability

incapacity to service levels of demand that are very high

vulnerability to attack

P2P protocol has the following characteristics:

Many devices perform server-functions Any device that performs server-functions is able to perform all server-functions.

Any device that is acting as a client is able to find one or more devices that are performing server-functions.

Servers assist clients to find more servers.

Many multiply-connected devices

Generally speaking, as Roger Clarke mentioned in his article, "Peer-to-Peer (P2P) - An Overview": "Peer-to-peer (P2P) is a network architecture in which nodes are relatively equal, in the sense that each node is in principle capable of performing each of the functions necessary to support the network, and in practice many nodes do perform many of the functions…".

The project described below performed in frame of EE Software Lab in Technion. The project's main subject is a P2P-based system, supplying a platform for map-based interactive application.

The purpose of the project is to demonstrate a possible usage of the P2P technologies. An additional purpose is educational; studying about a problems and possible solutions characteristic for P2P-based system development.

Software & Hardware properties & requirements

OS: application developed and tested on XP 32 bit OS and should be run on any platform supporting java version 1.5 and higher.

Rest of hardware requirements can be found at the following sites:

Java environment: http://java.sun.com/j2se/1.5.0/download.jsp.

JMF: VOIP feature is supported within JMF 2.1.1.e: http://java.sun.com/products/java-media/jmf/2.1.1/download.html

Project design

P2P2DSpace is a P2P-based system, supplying a platform for a map-base interactive application.The system composed of several layers – the Network, Map and Application layer.Lets define non-Application layers as “middleware” layer.

During the design of the system, several design decisions were taken.

In order to avoid logical connection that is too tight between the user and the server he's logging into, logical separation was made between the region, which the server is responsible of, and a "user's room". Upon login, coordinate being assigned to user (according to username hashing). In this coordinate a link to user's room created. The link represented by house item.

The users are able to walk around the global map, to come in to other users houses and to locate or activate objects on the global map.

Due to the fact, that user can travel between regions of different servers, and the application should present the relevant background. It is calculated by querying the servers that are responsible for the logical region, that need to be presented on the screen. The querying is performed via Middleware layer, which is providing URI of the server responsible for a specified coordinate.

Due to the fact, that several users can be located and performing actions on objects in the same region simultaneously, a problem arises – how can all the users get the most updated map? The considerations were supplying the most updated information versus the messaging burden amongst the different peers. The decision was made, to create a "refresh" button, such as every time a user would like to get the most updated map, he will press this button. The actions taken care on object will be registered at the peer responsible for the region. If several actions performed simultaneously, it's up to the peer in charge to decide in which order the actions would be carried out. Naturally, after performing an action on item, the user will receive the most updated map.

The Middleware layer will supply to the application the following services:

Finding the peer IP by user name or coordinate (topology-related issues)

Login/Logout – The data (IP and username) of the peer, which should receive/give responsibility region (according to the Login/Logout algorithm), will be supplied.

The system allows each user to design his own “house”, meaning he can choose the background for the “house” and place items in it. Also, the user can “travel” to other users' houses. User can enter a house by clicking on it.

Generally, global coordinate system is used within both application and lower levels. (0,0) coordinate stands for the upper left corner of the map. The coordinates used inside "houses" are local per each house

The system composed of 3 main layers: Application, Middleware and Communication. The intercommunication between the layers is shown below:

Application – a layer, which is responsible for the interaction with the user, and different user services.

Middleware (combined of the Map and the Node components) – a layer, which is responsible for the topology of the P2P system and the communication amongst different nodes.

Communication – a layer, which supplies the communications services to the Middleware.

GUI designThe user interface has the following appearance:

Figure 1: User home base

Figure 2: Global map

This is how global map looks like

Map Layer P2P2DSpace was designed in 3 layers.First layer application, 3rd layer network. In order to reduce complication of application layer, map layer was added as a middleware between application and network. Its role is to detach application from network implementation. All application sees is 2D map with items, coordinates and background. Map layer takes care of all communications with the network like: requesting via network from several computers (network’s functionality) their items, bringing background of the region from 3rd party server (Background Manager), transporting items from one computer to another via network.

Map layer’s main function is to store items according to their coordinates in a very large 2D world. It is required to allow fast access to the stored items, and also to be memory efficient. In order to answer these demands sparse matrix structure was implemented.

Backbone of map layer is SparseMatrix module. It is hash map based implementation of sparse matrix, which is ideal for storing items on their 2D coordinates in a large 2D world. 2D map represented by space matrix of appropriate size and can be accessed by single coordinate or by region. SparseMatrix is used to represent a region and items contained in it (also used by application and network layer).

It is actually 2D linked list. This way it allows to store many different coordinates in memory efficient way. The problem with linked lists is slow access to individual item

stored in it. In order to overcome this problem sparse matrix is backed up by hash table. This allows us to find single item stored in sparse matrix in O(1) in average, or to verify it’s (non)existence in the structure.The only ‘inefficiency’ in sparse matrix is retrieving several items by region. In order to do this we must traverse the matrix not by relevant region, but by the matrix axes, which sometimes means covering much more items than exist in the region. In average (when requested small regions) this is done in O(n) for n*n matrix. In worst case it is O(n2).

Map is a private peephole of each application to the world. When application ‘travels’ from world to world, it uses someone else’s map. It is also capable of changing it. Therefore there’s a need in synchronization. There’s a thread safe version of SparseMatrix: SyncSparseMatrix. While SyncSparseMatrix is used as part of each module, SparseMatrix is transferable unit between application and map layers.

Map main flows

Load Region Bring from the network all relevant items and background to local computer

for application’s use

Get Item Return to application item whose coordinate is equal to passed parameter

Change Item Send: Send changed item via network to the owner’s computer

BackGroundManagerP2P2DSpace represents a very large 2D area. It would be not practical to transfer large bitmap by demand via network. Therefore a 3rd party server is created. It holds a bitmap of a world and supplies parts of it by demand, as if all applications look at the word through a small peep hole.

It was decided to make one central known to all servers for dealing with background. It is possible to give each application its own background manager.And everyone asking for application’s map would also get relevant background manager’s address. The problem with this design is that there’s no central control over the looks of the word, but each node in the network which is given responsibility over some region of the world can decide how it will look.

Future developments – it is possible to load into background manager a collection of small pictures. When asked to bring certain region, it can glue together those small pictures into required size picture of the region. Thus providing applications with more flexibility over controlling the looks of the background of the world.

BackGroundManager flow Cut out from stored bitmap rectangle of asked size, if rectangle stands out of

the bitmap use modulus math to replicate bitmap’s parts for the missing parts of requested rectangle.

Application

ComponentsThe following components composites the application layer:

IM component – JAIN SIP package. The open source package providing proxy server and IM client is partially used for voice and textual messaging. Will be described more detailed in the following section.

Map (composed from items + background) – containing the information about the region the peer is responsible for, relevant for presenting region graphically: bitmap, list of items, houses and users located in the region, etc. Logically located at the Middleware layer

House – extending Map, used for containing the background and items of user's house.

UI component (including different configurations possibilities)

Class DiagramThe description of the main classes used in the application layer:

b2b.application Class Friend

Method Summary int getOwnerChatPort()

            int getOwnerNetworkPort()

            java.lang.String getOwnerURI()

            java.lang.String getUsername()

           

b2b.application Class User

Method Summary void addFriend(Friend friend)

           

 java.awt.Image getAvatar()            

 java.awt.Image getDefaultBackground()            

 java.util.Map getFriendsList()            

 java.lang.String getUsername()            

 java.lang.String getUserURI()            

 void removeFriend(java.lang.String friendName)            

 void setAvatar(javax.swing.ImageIcon avatar)            

b2b.application Class LocalConfiguration

Method Summary void addDefinedItem(java.lang.String text,

java.util.List paths)            

 java.lang.String getAvatarPath()            

 java.awt.Image getBackg()            

 java.lang.String getBackgPath()            

 java.lang.String getBgrMngrIP()            

 java.lang.String getBgrMngrPort()            

 java.lang.String getBgrMngrURL()            

 java.util.Set getDefinedItemsList()            

 java.util.Map getDefinedItemsMap()            

 java.util.Map getFriends()            

 java.util.List getItemsList()            

 java.lang.String getMyURL()            

 int getNetworkStartPort()            

 java.awt.Image getPathToAvtr()            

 java.lang.String getProxyConfPath()            

 java.lang.String getProxyIP()            

 int getProxyPort()            

 java.lang.String getUsername()            

 void storeConfiguration(java.lang.String pathToStore, b2b.map.HouseItem houseItem)            

b2b.gui Class ApplicationGui

Method Summarystatic void createAndShowGUI(b2b.logic.ApplicationLogic logic)

           static void exit()

           static void main(java.lang.String[] args)

           

b2b.gui Class ChatManager

Method Summary void createMainPanel()

          Create the GUI and show it.

b2b.gui Class GeneralMapGUI

Method Summary void changeHouseItem(b2b.map.Item itm, java.lang.String uri,

java.lang.String username)            

 void chosenItem(b2b.map.Item item)            

 void mouseClicked(java.awt.event.MouseEvent arg0)            

 void mouseEntered(java.awt.event.MouseEvent arg0)            

 void mouseExited(java.awt.event.MouseEvent arg0)            

 void mousePressed(java.awt.event.MouseEvent arg0)            

 void mouseReleased(java.awt.event.MouseEvent arg0)            

abstract void

paint(java.awt.Graphics g)            

 void setGuiManager(GuiManager manager)            

 void setULCorner(b2b.node.Coordinate coord)            

b2b.gui Class GuiManager

Method Summary void actionPerformed(java.awt.event.ActionEvent event)

            void changeHouseItem(b2b.map.RemoteHouseItem itm,

java.lang.String username, java.lang.String uri)            

 void createMainPanel(java.lang.String username)           Create the GUI and show it.

 void openChatWindow()            

 void openChatWindow(java.lang.String ownerUserName)            

 void setConnectionStatus(java.lang.String status)            

b2b.gui Class HouseItemGUI

Method Summary void paint(java.awt.Graphics g)

           

b2b.gui Class MapGUI

Method Summary void paint(java.awt.Graphics g)

           

b2b.gui Interface RemoteGuiManagerAll Superinterfaces:

java.rmi.Remote All Known Implementing Classes:

GuiManager

Method Summary void openChatWindow()

            void openChatWindow(java.lang.String ownerUserName)

           

System main flows

Login When user logs into the system, the following parameters are loaded from his

configuration file:o Paths to his: avatar, background of his homeo List of friends (with usernames and URLs)o List of items which located inside his house (including location, possible

state and current state).o Parameters of the background managero Parameters of chat proxy.

Now the user can “organize” his home, change the background, move, add or delete the items and perform action on them.

If user wishes to connect to the global map:o If he wish to create his own world, it chooses to connect via <New User>

(the default), and his peer will be the root of this world.o If he wishes to connect to an already existing world, he should choose (in

friends list) some user that will be his bostrapper.

LogoutUpon logout, the users’ personal information saved to configuration file, in order to recreate all the relevant data upon user re-logon.

Goto Go To coordinate: shows a piece of global map, while the requested

coordinate is its center Go To user: goes to the requested user home, located on global map. The

needed coordinate is computed by username hashing. Go To home: shows users’ home base.

Chat Feature

SipSession Initiation Protocol (SIP) is a signaling protocol for creating, modifying and destroying dialogs between multiple endpoints:– Request/response protocol (like HTTP, but peer-peer)– Simple and extensible– Designed for mobility (proxy/redirect servers)– Bi-directional authentication– Capability negotiation

SIP is used for controlling the signaling that enables manipulates of sessions such as:– Instant Messaging sessions– Phone calls over the Internet– Gaming servers– Resource Location

The chat feature in based on JAIN SIP implementation of the SIP protocol. JAIN SIP implementation takes advantage of Java technology and makes the deployment procedure comfortable.

Sip implementation used in the project can be found at: https://jain-sip.dev.java.net/

ProxyProject can be found at: https://jain-sip-presence-proxy.dev.java.net/Jain-sip-presence-proxy is the application which serves as a communication center of all the users. The proxy gathers information about available users at each point of time. In order to contact another user in the system, the user registers at the proxy, and, in the case the destination user is available, sip id is obtained from the proxy and used while chatting session. It is important to notice that proxy presents a single point of failure. Upon a proxy crash, users are not able to contact one with another

In order to avoid any kind of ‘centralization’ in our application, it is decided that each host should run the proxy. In such way, in the case some user fails, alive users are still able to communicate.

There is a tradeoff between running the centralized proxy and running a private proxy on each host. Better connectivity is reached by exploiting users’ CPU.

Original proxy package includes both protocol and gui implementations. Since the gui part is not relevant to our application, it is not used. Appropriate changes have been done in order to ‘hide’ the proxy. Currently it is started with the application and user actually is not aware of its existence.

The proxy runs on the default port. During its lifetime proceeds a couple of received message types: register/unregister messages, textual chat messages and voice chat messages.

The proxy shut down cannot be initiated apparently from the rest of the application: it shuts down upon an application shut down.

MessengerThe utility that makes feasible both textual and vocal interaction.The project can be found at: https://jain-sip-applet-phone.dev.java.net/

Generally, the proxy project includes an implementation of instant messaging. One of the project goals was to integrate a VOIP feature, so NIST messenger project was chosen to make VOIP feature within our project.

Just like in the case of the proxy project, the original gui implementation was replaced by our gui to fit the graphical design of the rest of the project. Additionally, some original functionality that could be used in the original project, after performing certain actions is replaced by methods that called automatically, without user’s interaction. The example that represents it very clearly is the registration: when a user is about to have a textual or voice chat with another user, according to the original technology, must be registered on the same proxy as the destination user.

To remind to the reader, our project does not exploit any centralized resource, so each user runs its own proxy autonomously of other users. Once a user is interested to interact with other user, it’s of his charge to locate the destination user’s proxy, register there and start instant messaging protocol via the destination user proxy.

Assuming the proxy on each user’s host runs on the default port <4000>, it’s enough to know user’s ip in order to contact him. In that way, behind the curtains, registration to destination user’s proxy happens and instant messaging protocol is ran via that proxy. So for the both users’ eyes an interaction with the proxy is not seen at all.

Network Layer

OverviewThe purpose of the Network Layer is to provide a layer of p2p network for the P2P2DSpace application’s use. The Network Layer was designed to provide a scalable and easy use of p2p network as a middleware for P2P2DSpace application, while the major requirement for it, is network’s scalability.

This network represents a virtual two-dimensional space. Each peer in the network is awarded a region of responsibility in this virtual space, while the coordinate location of the peer in this space is calculated uniquely using the user name. Size of the region of responsibility depends mainly on number of peers in the network. The network itself is represented as a tree with up to 4 sons per each node (peer), when each son receives quarter of the fathers region of responsibility as its own region of responsibility. The network is able to map peer to unique virtual region. The network is able to map each coordinate of virtual region to peer who owns the region by user name only. Each peer is able to map application's items to coordinates of virtual region that under its responsibility.

Design decisions, principles and considerations1. Major issue of this project is to provide a flexible implementation of virtual 2d space and regions, while maintaining scalability of the implementation. In order to allow simple way of describing regions was decided that each region may be divided into 4 equal new regions, while they may be given to other peers who joined the network.

2. In order to provide network’s peers with ability to find each other in the network in a scalable way, the network was designed in a tree form, while each peer is a node in the tree. Each level in a “tree” represents a layer in a virtual world of regions of same size, some of which were divided into smaller regions (have sons) or represents a node in a tree which is responsible for navigation from above nodes to this node's sons.

3. Efficient disconnection of node from the network.When node connects to the network, it gets from its father region of responsibility with application items in this region. It may happen that other nodes will connect to the network through this node, and thus this node will transfer them regions of responsibility with applications items. For enabling efficient disconnection of this node from the network, it was decided that if there were 4 sons connected to this node, all items of this node are divided between sons and this node continue to be used only for navigation in the tree. Now, during disconnection of this node, it just needs to ask some node, which is leaf in this node’s sub-tree, to return items to leaf node’s father and replace this node. This solution also helps to keep region of responsibility with items in each node to be integral and not be broken to many small peaces (that may require unbound allocation of memory).

Design

The network layer module provides network services to other layers thought two interfaces: NodeMap interface for Map layer and NodeApp interface for Application layer. In general, the NodeApp interface provides Application layer with connect/disconnect to/from the network and the NodeMap interface provides Map layer with all functionality regarding managing (find/add/remove) items of Peers. The principal class of the network layer is NodeImpl class which implements the abovementioned interfaces. The NodeImpl class is designed to instantiate a Node object that is a singleton in the Peer and in order to ensure this, the creation of Node is only possible through the factory: NodeFactory class.

The major design issue was regarding performance – how to allow network’s nodes to communicate with each other in efficient and scalable manner. Using Java’s RMI mechanism for communication between network nodes is inefficient since it blocks the initiator of the method invocation until method’s run is completed on remote computer. Therefore, communication is done via message passing between nodes through sockets. In order to find destination node, messages from source node are passed through nodes of the tree, but reply from the found node returned directly to the source node.

Mapping coordinate of virtual region to unique user name is done by calculating hash of the user name using MD5 algorithm which generates digest of 128bit. First 64bits are taken for X value of the coordinate and the last 64bits for Y value.

During peer’s life, it sends and receives many messages and it may receive many messages at the same time. Processing message may take a time, and in order to prevent denial of service it was decided that receiving and processing of messages will be done asynchronously. There is need for two threads: one receives messages and puts them into the queue (producer) and second one gets messages from queue and processes them (consumer).

Every peer is able to send and receive many message types. Every type of message needs its special handling of sending and processing. There was done an implementation effort to generalize messages handling in order to make it easer to extend the protocol with new message types.

Class diagram

All following class diagrams are divided per packages of the network layer.

Package b2b.node : b2b.node – contains node and node’s related classes implementations. For example classes which are used to describe a node: region, coordinate – used to describe to which region the node is mapped to be responsible in a 2d virtual space.

AppNodeListener<<interface>>

Coordinate

+MIN: long+MAX: long+x: long+y: long<<create>>+Coordinate()<<create>>+Coordinate()+equals()+toString()

NodeApp<<interface>>

NodeException

<<create>>+NodeException()<<create>>+NodeException()<<create>>+NodeException()<<create>>+NodeException()

NodeFactory

+getNodeApp()+getNodeMap()

NodeImpl

+DISCONNECTED: byte+CONNECTING: byte+CONNECTED: byte+RECONNECTING: byte+DISCONNECTING: byte~getNode()+setAppListener()+setMapNode()+connect()+setConnected()+disconnect()+setDisconnected()+getReplaceData()+getStatus()+getStatusName()+getKey()+connectNode()+replaceNode()+disconnectNode()+reconnectNode()+addItem()+addItem()+removeItem()+removeItem()+findItems()+findItems()+setFoundItems()

NodeMap<<interface>>

NodeSons

<<create>>~NodeSons()+getNodes()+pickNode()+size()+isFreePlace()+addNode()+freeNode()+getResponsibleNode()+isHasSon()+toString()

NodeUtil

+getCoordinate()

+coordinateMIN

+coordinateMAX

Region

<<create>>+Region()+getCornerL()+getCornerG()+contains()+overlap()+split()+equals()+toString()

+wholeWorld

ReplaceData

<<create>>+ReplaceData()+getRegion()+getItems()+getFatherKey()+getSons()+toString()

Package b2b.node.network : b2b.node.network – contains the manager of the network functionality of the node and classes which implement this functionality.

AbstractSender

+SOCKET_TIMEOUT_MILLIS: int<<create>>+AbstractSender()<<create>>+AbstractSender()~setSenderNodeKey()~run()#send()#sendPacket()#receivePacket()

NetworkManager

<<create>>+NetworkManager()+start()+stop()+getKey()+run()

NodeKey

+MIN_PORT_NUM: int+MAX_PORT_NUM: int<<create>>+NodeKey()+getHostName()+getMsgPort()+equals()+toString()+isHostLegal()+isMsgPortLegal()

Package b2b.node.network.senders : b2b.node.network.senders – contains classes which implement message sending classes used in protocols of the network - protocols such as connecting / disconnecting to the network.

All the following Senders classes are extending the AbstractSender class from the b2b.node.network package.

AddItemSender

<<create>>+AddItemSender()#send()

ConnectAcceptSender

<<create>>+ConnectAcceptSender()#send()

ConnectRequestSender

<<create>>+ConnectRequestSender()#send()

DisconnectRequestSender

<<create>>+DisconnectRequestSender()#send()

FindItemsSender

<<create>>+FindItemsSender()#send()

FoundItemsSender

<<create>>+FoundItemsSender()#send()

ReconnectRequestSender

<<create>>+ReconnectRequestSender()#send()

RemoveItemSender

<<create>>+RemoveItemSender()#send()

ReplaceAcceptSender

<<create>>+ReplaceAcceptSender()+getReplaceData()#send()

ReplaceRequestSender

<<create>>+ReplaceRequestSender()#send()

Package b2b.node.network.packets : b2b.node.packets - nodes communicate with each other via messages which include packets. The package contains all packets used by the system for communication.

AddItemPacket

<<create>>+AddItemPacket()+getInitiatorNodeKey()+getItem()+getCoordinate()+toString()

ConnectAcceptDataPacket

<<create>>+ConnectAcceptDataPacket()+getRegion()+getItems()+toString()

ConnectAcceptPacket

<<create>>+ConnectAcceptPacket()

ConnectRequestPacket

<<create>>+ConnectRequestPacket()+getInitiatorNodeKey()+getInitiatorCoordinate()+toString()

DisconnectRequestPacket

<<create>>+DisconnectRequestPacket()+getRegion()+getItems()+toString()

FindItemsPacket

<<create>>+FindItemsPacket()+getInitiatorNodeKey()+getRegion()+toString()

FoundItemsPacket

<<create>>+FoundItemsPacket()+getRegion()+getItems()+toString()

Message

<<create>>+Message()+getPacket()+getSourceNodeKey()+toString()

Packet+CONNECT_REQUEST: String+CONNECT_ACCEPT: String+CONNECT_ACCEPT_DATA: String+ADD_ITEM: String+REMOVE_ITEM: String+FIND_ITEMS: String+FOUND_ITEMS: String+FIND_NODE: String+FOUND_NODE: String+REPLACE_REQUEST: String+REPLACE_ACCEPT: String+REPLACE_ACCEPT_DATA: String+DISCONNECT_REQUEST: String+RECONNECT_REQUEST: String+RESPONSE: String<<create>>+Packet()+getType()+isNodePacket()+toString()

ReconnectRequestPacket

<<create>>+ReconnectRequestPacket()+getReplacedNodeKey()+toString()

RemoveItemPacket

<<create>>+RemoveItemPacket()+getInitiatorNodeKey()+getCoordinate()+toString()

ReplaceAcceptDataPacket

<<create>>+ReplaceAcceptDataPacket()+getReplaceData()+toString()

ReplaceAcceptPacket

<<create>>+ReplaceAcceptPacket()

ReplaceRequestPacket

<<create>>+ReplaceRequestPacket()+getInitiatorNodeKey()+toString()

ResponsePacket

<<create>>+ResponsePacket()+getStatus()+toString()

Package b2b.node.network.servers : b2b.node.network.servers – contains classes which are responsible for the server like behavior part of the node (i.e. listening on a pre-defined port via socket, open another port for communication, processing received message).

BlockingQueue+MAX_THRESHOLD_DEFAULT: int<<create>>+BlockingQueue()<<create>>+BlockingQueue()+enqueue()+dequeue()+isFull()+clear()

MessageAnalyzer

<<create>>+MessageAnalyzer()+run()+stop()+isRunning()+process()

MessageListener

<<create>>+MessageListener()+run()+stop()+isRunning()+getKey()

Queue#queue: LinkedList<<create>>+Queue()+enqueue()+dequeue()+peek()+isEmpty()+size()+clear()

Package b2b.general : b2b.general – contains general helper classes for the project.

B2bException

<<create>>+B2bException()<<create>>+B2bException()<<create>>+B2bException()<<create>>+B2bException()

B2bProperties

+NODE_INITIAL_MESSAGES_PORT: String+PORTS_TO_TRY_NUM: String+NODE_INITIAL_MESSAGES_PORT_DEFAULT: int+PORTS_TO_TRY_NUM_DEFAULT: int+props: Properties+setFilePath()+loadPropertiesToSystem()+storeProperties()

B2bRuntimeException

<<create>>+B2bRuntimeException()

Logger

+printMessagies: boolean+log()+log()

Flows

Assuming uniform scattering of the nodes coordinates in the 2D space, all following algorithms in worst case work O(log n), where n is the number of nodes in the network tree.

JoinWhen joining, a node has NodeKey of one (random) node in the tree (friend) or null if it intends to be the root of the new network tree.

Every node is defined by nick name (chosen by user) and NodeKey.

join()1. calculate nick name’s 128bit hash code (hash)2. determine location coordinate by the hash (coordinate)

a. x – first 64 bit of hashb. y – last 64 bit of hash

3. father = friend. findNodeForJoin(coordinate, NodeKey)4. father.adoptSon(coordinate, NodeKey) (this action connects son to father using

three way hand shake protocol and father returns to the son responsibility Region allocated for him, with existing item in it)

a. Three way hand shake:i. Father asks son if it is still wants to join (using

ConnectAcceptPacket)ii. Son replies OK (using ResponsePacket)

iii. Father connects son and replies him with allocated responsibility Region with items (using ConnectAcceptDataPacket)

5. Son remembers father’s NodeKey (back link)

findNode(coordinate, initNodeKey) action is similar to findResponsibleNode action with difference that in last step the father doesn’t send his NodeKey to initNodeKey, but starts three way hand shake.

Find NodeThis algorithm finds the Node in the location.

findNodeForJoin(coordinate, initNodeKey)1. if node with initNodeKey already connected to me, return2. if coordinate not under my responsibility:

a. father. findNodeForJoin(coordinate, initNodeKey)3. else:

a. if I have a free place for son, accept connection to me (see adoptSon)and return

b. else find son which is responsible for the coordinatec. and do son. findNodeForJoin(coordinate, initNodeKey)

adoptSon(coordinate, NodeKey)1. divide region to 4 equal squares (if not already divided)2. assign the first empty region to the sonNote: All not assigned regions are of father responsibility.

Leave

When node leaves the network, it must find the replacement node which will take its responsibilities: region and items.

leave()1. if I have no sons

a. notify father (back link) of leaving – return region and items (using DisconnectRequestPacket)

b. if I am the last father's son , father can discard area partitioning2. else

a. find my offspring which will replace me (using ReplaceRequestPacket) with algorithm findOffspring(myNodeKey) started on one of my sons

b. my offspring notifies me that he will replace me and I transfer him my responsibility region and items

Notifications to my father and my other sons about replacement are sent by my replacing offspring.

findOffspring(leavingNodeKey)1. if I have at least one son, pick one of them and ask him

findOffspring(leavingNodeKey)2. else I am an offspring:

a. send accept replace to leavingNodeKey and get from him replace data: region and items

b. leave my father using Leave algorithmc. send reconnect request to the father of leavingNodeKeyd. send reconnect request to all sons of leavingNodeKey (except me, if I his

son) - to change their back links to me (using ReconnectRequestPacket)

Add/Remove item

In order to add/remove item in specific coordinate, first need to find node which is responsible for that coordinate.

addItem(item, coordinate) / removeItem(coordinate)

1. run findNode(coordinate) algorithm in order to find node which is responsible for the coordinate

2. found node adds or removes the item

findNode(coordinate)1. if coordinate is not in my region, ask my father to findNode(coordinate) and

return2. else

a. if I have a son which is responsible for the coordinate, ask him to findNode(coordinate) and return

b. else I am responsible for the coordinate, and I need to perform the request

Find items

When finding items in some region, there might be many nodes which are responsible for parts of this region, and we need to collect items from all of them.

findItem(region, initNodeKey)1. check if my region overlaps the requested region2. if no overlaps, send findItem(region, initNodeKey) to my father and return3. if regions overlapping partially, send findItem(region, initNodeKey) to my

father and continue with handling of the request4. if I have sons which regions overlapping the requested region, send

findItem(region, initNodeKey) to them (except son from which came this request)

5. collect item in my responsibility, that is in requested region and send them to the initNodeKey (using FoundItemsPacket)

Bibliography

P2P technology , algorithmshttp://www.anu.edu.au/people/Roger.Clarke/EC/P2POview.htmlo http://pdos.csail.mit.edu/papers/chord:hotos01/hotos8.pdf www.igd.fhg.de/igd-a1/RSPSI/papers/RSPSI-Weis.pdf (algorithms overview)

http://research.microsoft.com/~antr/PAST/pastry.pdf (Pastry algorithm) http://berkeley.intel-research.net/sylvia/cans.pdf (CAN algorithm) Wikipedia links used

http://en.wikipedia.org/wiki/P2p. http://en.wikipedia.org/wiki/Chord_project

Sip project http://www-x.antd.nist.gov/proj/iptel/ SIP RFC http://www.rfc-archive.org/getrfc.php?rfc=3261