Re: [ProtoPeer-general] ProtoPeer suggestion and routing protocol question
Status: Alpha
Brought to you by:
wojtg
From: Krzysztof F. <krz...@uj...> - 2009-10-02 14:42:04
|
Hello Wojciech, Wojciech Galuba pisze: > Hi, > > The Peer class was never intended to have multiple interfaces. The Peer > exposes only a single network interface to the applications (peerlets) > running on the peer. > The "network interface" name might be a bit misleading since it's not > like a eth0 or wlan0 ;) It's a message passing interface. > > I'm not sure what exactly is the goal here, but as Frank mentioned in > one of his posts, modeling routing sounds like something that should be > done at the lower layer in the ProtoPeer architecture, i.e. at the > network model layer (NetworkInterface, NetworkInterfaceFactory, > Topology) instead of at the application layer (Peer, Peerlets). > In my project Topology is handling the physical topology, while routers are handling the routing. That is because every router has to take a decision on where to send a packet. Putting all routing tables to customize routing into one class doesn't sound like a good idea to me. > The flow-based network model is probably the right place to implement > this type of stuff, more specifically, you could try to subclass the > Topology class to have more control over routing. > Already done :) > Another way to do that would be to implement a simple NetworkInterface > which would internally be using multiple NetworkInterfaces and do the > "routing". In a sense, it would emulate a multi-home node, but to the > application it would still appear as a single interface. > > The advantage of doing all this at a lower layer is that you can then > simply take a BitTorrent implementation (in ProtoPeer) and run it on top > of your network model, to see what ASes the data crosses. If you go for > the multi-interface Peer it might break the current applications which > are designed to work with the single-interface Peer. We would need to > considerably rework the class hierarchy to avoid that, which sounds like > effort ;) > This doesn't have to be much effort. Adding a superclass of Peer, lets call it "NetworkingElement" would not change existing applications. Methods like NetworkInterface.setHostPeer(Peer hostPeer) whould just change to NetworkInterface.setHostPeer(NetworkingElement element). This would allow introduction of other types of elements that use ProtoPeer framework like Peers do, but are not Peers. Krzysiek |