The three major python implementations of Kad are Khashmir, SharkyPy and
Entangled. However, all three do not mention about NAT traversal. Even if
we had such an UPnP enabled python implementation, we must look into its
compatibility with our mobile agent too. And as far as I have seen there
are no Android alternatives. And making two bytecode oriented languages
talk with each other is much worse.
The best thing is to go for a NAT traversal enabled C++ implementation (say
maidsafe-dht) connected to our desktop agent (Python) and mobile
agent(Android-java) through native extensions. Though it looks little tough
at the first sight, this gives great flexibility. And since the base
implementation is native C++, its going to be faster too.
On Mon, Mar 26, 2012 at 4:09 PM, Adriano Marques <[email protected]>wrote:
> This turned out into a good discussion, and I definitely want to see on
> the proposal how students wants to tackle this challenge :)
>
>
> On Sun, Mar 25, 2012 at 11:43 PM, Zhongjie Wang <[email protected]> wrote:
>
>> Hi guys,
>> Yeah, DHT is an option and we may also need to consider those
>> nodes behind NATs. So I recommend we use the super agents as trackers. The
>> super agents are those peers who have public IPs and could surely connect
>> to the aggregator. They can help with forwarding messages between nodes,
>> and also if an agent can connect to a super agent, then it messages can be
>> sent to the aggregator. Kad is using some protocol like gossip, we may also
>> bring this idea in.
>>
>> Regards.
>> Alan
>>
>>
>> On Mon, Mar 26, 2012 at 4:02 AM, Zubair Nabi <[email protected]>wrote:
>>
>>> Guys,
>>>
>>> You also need to consider the mobile agent. The same DHT algorithm needs
>>> to be applicable to the mobile agent as well. First, and foremost, we need
>>> to come up with a solution for pure P2P communication assuming that both
>>> peers are behind a NAT. One option is to use tcp hole punching. In such an
>>> architecture, can some of the desktop agents --with public IPs -- serve as
>>> relay servers between other desktop agents and mobile agents? This was a
>>> major impediment that we ran into last year. I know of a couple of Kademlia
>>> libraries in C++ and Java that have UPnP-enabled NAT traversal. Do the
>>> Python implementations consider NAT traversal? In addition, for people
>>> interested in working on the mobile agent, are there any Android Java
>>> libraries to this end?
>>>
>>> Best,
>>> Zubair
>>>
>>>
>>>
>>> On 25 Mar 2012, at 20:48, Narendran Thangarajan wrote:
>>>
>>> Yeah I get it. So we need to implement a P2P routing overlay so that
>>> Peers can form clusters among themselves. There are a horde of options like
>>> Gnutella, DHT, Semantic routing etc. Since we are focusing on a global
>>> scale, I feel the best option is to go for Distributed hash tables
>>> implementation. It is fast and doesn't flood the network with redundant
>>> requests. Moreover, the system gets decentralized, thus it is easy to scale
>>> on demand.
>>>
>>> Among the DHT algorithms, I feel that making a Kademlia based
>>> implementation of DHT is a more viable option in python. Added advantage is
>>> that, certain Kademlia implementations provide out-of-the-box visualizers
>>> for monitoring all the peers. This will greatly enhance the user experience.
>>>
>>> Thanks,
>>> Narendran Thangarajan.
>>>
>>>
>>> On Sun, Mar 25, 2012 at 7:16 PM, Zhongjie Wang <[email protected]> wrote:
>>>
>>>> Hi Narendran,
>>>> Actually there's not a notification system yet. I know you mean
>>>> to
>>>> implement a notification system at the agent side. The method we are
>>>> using now is periodically checking the aggregator. The agent sends
>>>> GetEvent messages to the aggregator and gets the events happened
>>>> in its region or the global Internet. The notification system might not
>>>> be
>>>> a quite urgent job for now. We can add some code to pop-up a small
>>>> window for notification.
>>>> I think the routing strategy is a problem needs to be solved.
>>>> Also
>>>> we need to figure out how to form a stable peer network, in which the
>>>> peers could dynamically gather into clusters, and bypass the blockage.
>>>> Currently the aggregator url and super agent addresses (the entrance
>>>> for a new agent) are written into the db of the agent statically.
>>>> We still need to think out more ideas for a new peer to find
>>>> its neighbors
>>>> and the super agents. Although we are using a cloud-based aggregator
>>>> to scale our service, we are building a huge network covering the
>>>> whole
>>>> world! So management of peers should be decentralized, by the peers
>>>> themselves or the super agents. Remember the essential task is to
>>>> spread the information in a network with blockage. :)
>>>>
>>>> Best Regards.
>>>> Alan
>>>>
>>>> On Sun, Mar 25, 2012 at 12:01 PM, Narendran Thangarajan <
>>>> [email protected]> wrote:
>>>>
>>>>> Hi,
>>>>> I looked into the reporting mechanism in ICM-desktop agent. I see
>>>>> that once the agent logs in, there are three looping calls that
>>>>> perform the following :
>>>>> 1. Get peer list and populate the peerinfo.
>>>>> 2. Schedule tasks and add reports
>>>>> 3. Upload the generated reports.
>>>>>
>>>>> But I can't find logic, how the peers make use of the
>>>>> Website/service reports generated from other peers or aggregator. If
>>>>> its available, where should I find the logic? If not, I would like to
>>>>> implement a notification system, which notifies the peer user of any
>>>>> network / website outages. This tool will be really helpful for
>>>>> admins/end users at various scales (On a global level or within a data
>>>>> center - thanks to the flexible design of the OpenMonitor system).
>>>>> This can be implemented using an evented I/O (say gevent).
>>>>>
>>>>> Thanks,
>>>>> Narendran.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> This SF email is sponsosred by:
>>>>> Try Windows Azure free for 90 days Click Here
>>>>> http://p.sf.net/sfu/sfd2d-msazure
>>>>> _______________________________________________
>>>>> Umit-devel mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Zhongjie Wang
>>>> Master Candidate
>>>> Computer System Architecture
>>>> Peking University, China
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF email is sponsosred by:
>>> Try Windows Azure free for 90 days Click Here
>>>
>>> http://p.sf.net/sfu/sfd2d-msazure_______________________________________________
>>> Umit-devel mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>>
>>>
>>>
>>
>>
>> --
>> Zhongjie Wang
>> Master Candidate
>> Computer System Architecture
>> Peking University, China
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Umit-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/umit-devel
>>
>>
>
>
> --
> Adriano Monteiro Marques
>
> http://www.openmonitor.org
> http://www.umitproject.org
> http://www.thoughtspad.com
>
> "Don't stay in bed, unless you can make money in bed." - George Burns
>
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Umit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/umit-devel
