No subject

 c. As I understand, in the diagram, there is another component that "makes a decision" as to which peer should be used to serve a particular wiki based on load sharing. It can be simple heuristic to start with (serve from local machine if available, otherwise pick one of the other peers, which have the read-only copy, at random. I am not sure how the implementation of "closest peer" will work? ).
 
There are two issues to solve. Issue 1 is passing firewalls using the closest 'node' (there is no load balancing here and this is what I was talking about). Here instead of sending the peer IP address to the central registry it's the node IP that goes in the central registry and DNS server.

The second issue is when replication is in place, how to choose the right peer based on the IP address of the requester. Indeed random or round robin is the easy choice that will work right away probably without mydns changes. Closest peer could be handled using some geolocalisation (there are some public databases of location - at least countries - of IP addresses). If the IP are on the same network it could be an easy solution too. I know akamai has done some work in this area so it is possible to build huge database on the best choices. This won't be possible right away, but we can suppose that in a future release mydns would be modified to ask an external function for the best solution among the existing replicas: String getBestIP(String RequestorIP,String[] ReplicaIPs) 

 d. firewall traversal: Any of the "nodes" in the diagram can act as intermediary in case of firewall or does the central registry act as the intermediary for all firewall traversals?
 
The nodes... Nodes have to accept HTTP connections and would relay them to one of their P2P clients permanently connected to them using an upstream connection.. In a first release, the central registry could be the only node available, but the architecture should be build to have mutiple nodes and level of nodes.

 e. There is security concern related to how the dns will be updated... There is security problem related to redirection as well. I don't sufficiently understand how mydns work, so i think i will explore this later once i have a basic implementation, is this reasonable? Having a separate discussion on security may be a good idea.
 
Let's suppose the nodes are trusted (so if a node sends back info to the central registry then it's fine.. This probably means communications needs to be signed). P2P clients are authenticated when connected to the nodes. They are the only master for their own wikis. That info is sent back from the nodes to the central registry. There is an issue with declaring having a complete replica of a wiki.. This could be handled using a hashcode.. Now once the request goes to the peer, the peer can serve whatever it wants.. I don't think the HTTP only version can validate what another peer is sending back.. only a P2P client could validate what another peer is sending back.. I'm not sure we want to solve this right away or even at all.. 

Action Plan for SoC

1/ I will start with the action plan that Erwin outlined with implementation for redirection and host resolution. Security and Firewall traversal are the issues are the ones that will be taken care of in the future.

Ok

2/ inorder for ludovic.p2p.xwiki.com to be resolved correctly, there needs to be some changes to the xwiki.com dns server - so that it can invoke a web service call to mydns and return the correct ip address. I will need a test platform for this.

Ok.. we'll look at what we can do.. I think I will take p2pxwiki.com so we can have everything separate for now... We will setup a mydns server with a database somewhere and open that database from updates from java over the internet.. once we have this you could have a central registry anywhere that updates the database. In production the central registry would probably be on the same machine.

I think you can also set that up for testing on your local machine (that might be more efficient to verify you can update the DB fine). 

> Registry for P2PXWiki name resolution
> -------------------------------------
>
>          Key: XWC-22
>          URL: http://jira.xwiki.org/jira/browse/XWC-22
>      Project: XWiki Clients
>         Type: Task
>   Components: XWiki P2P
>     Reporter: bikash agarwalla
>     Assignee: bikash agarwalla

>
> Implement a registry for p2pxwiki name resolution. 
> There is a central registry for name resolution. The central registry allows for the wiki names to be distinguishable. Also it helps in solving the problem of wiki-hijacking. 
>     * extension: central registry can be replicated between a set of servers
>     * extension: central registry functionality can be handed by peers. There will be a need for ensuring the integrity of the registry data in this case.
> More on this in the design issues section http://www.xwiki.org/xwiki/bin/view/Dev/Design+Issues 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.xwiki.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira