Skip to main content

Relay per groups or per network?

22 replies [Last post]
Joined: 2008-12-22


I have several questions regarding relay peers:

1) Are relay peers required to be in the same group as the peers that use them, like it happens for RDV peers?
1.1) Can relay peers outside the group a peer is communicating in be used? (like from the initial seedingUri of the network bootstrap).

2) How do relay peers get discovered besides multicasting?
2.1) Is there a mechanism similar to the rdvService that announces new relay peers as they join the network(group?)?
2.2) Does each relay need to subscribe to the central seedingUri used for bootstraping the network and the peers will use them when their destination is not directly accessible? (this would be the less preferred).

I`d appreciate your help.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2008-12-22

Thank you!

That sounds just like what I need.

- Some relays provided for network connectivity (dynamically changing in the seedingUri by the network administrator) so we make sure people can talk even if they are behind NAT/Firewall.
- Some dynamic relays that *can* be set up and automagically discovered by *group members* if they want to boost up their group communication performance for NAT/Firewalled peers (because JXTA knows how to do efficient routing, right?).
- The down side of this is that they can not be sure that their relay will be private and the rest of the network won't use it as well, slowing their communication.
- Maybe the public Relays could be used as well as a backup alternative :)

As pointed out by turbogeek, the HTTP protocol filtering problem still limits communication but I think this is a very remote case. Good point thought!

The main goal being network connectivity rather than performance, I would say that my question is now answered. Thank you very much guys. I will eventually test all this and if problems occur, I will let you know.

Joined: 2007-08-17

"Some dynamic relays that *can* be set up and automagically discovered by *group members* if they want to boost up their group communication performance for NAT/Firewalled peers (because JXTA knows how to do efficient routing, right?)."

Honestly I don't know how this happens.

Can you be more specific about this subject please?

Joined: 2008-12-22

What I meant to say was that, besides the relays for the network located in the seedingUri and managed by the P2P network admins, peers might want to add their own relays to help network connectivity by becoming themselves Relay peers. This could also loosen the dependency to the network Relays.

Being members of a group (and also relays), I imagine that it will be much faster for them to be discovered first by other group members and be preferred as Relays by others in comparison with using the network provided Relays.
In most of the cases, peer members will be topologically more close one to each other than to the "general" network Relays provided by the P2P network admins(seedingUri). This could boost network performance / load balance. JXTA *should* be smart enough to decide which one is faster: the discovered Relay or the network Relay.

Maybe this is just wishful thinking :)

Joined: 2003-06-10

Perhaps wishful thinking at least at the present time.

The issue with this is that discovery of Relay/RDV are booth randomized beyond the seed you first get. In other words, find a Relay, download a list of infrastructure peers, select a random peer for Relay and RDV. There is no optimization other than the fact that these peers have a max number of connections.

There is no ping and test of latency. There is no measure of actual load. This needs to be part of implementing both reliable messaging and load management. Going back to the battlefield scenario, you currently would need additional software to determine dynamically the optimal network and use voting of peers as RDV and filtering via ACL the specific Relay to use. This would need to be fairly dynamic and you would encounter a few issues with bouncing communications as RDV and Relay change as the network optimizes.

I think the only thing that Jxta does is try to connect without a Relay for pipes when it is possible.

Here is the bottom line. I have said this many times. Jxta is not currently built to be efficient. It is unreliable despite the fact that it could be reliable. It seems to only have had one goal, at least from the original designer's point of view, is to be self healing and limit two way communications because it is not always possible.

Sadly the idea that self-healing is more important than 'unreliable' and 'non-optimized' are perfectly acceptable when you think that way. In reality these are both possible, just harder and do require a little more bandwidth. Sadly the lack of reliability and optimal performance is the leading reason why Jxta is not as as popular as it could be.

You may now proceed to call me a heretic. It's my cross and I'll nail myself to it if I want to :o) I'm somewhat at the disadvantage that I don't have the bandwidth or cash to fix this. If I win the lotto, you can bet this is the first thing I'd do as I believe this is extremely important for the future of the web.

Some more facts before you run away screaming. Jxta isn't too bad. Don't think you are going to send large amounts of data at the most optimal speed. You need to avoid overloading peers or you will loose data. Don't think you can reliably use the discovery service for many situations. However if you have a network that uses well-known ID or has a lot of peers giving redundant services, it is pretty good. I have written many applications and currently working on a commercial application. I would not be here if I didn't think that despite problems it is pretty cool cheese.

Joined: 2007-08-17

In my opinion this is a critical aspect when using jxta for commercial applications.
What we miss is a guide called "Best practices when using jxta in commercial applications". A lot of people seem to ask the same questions over and over on the forum.

Back to Relays - it is critical that peers can be promoted dynamically to Relay status for a network to function properly. I can imagine that a network with thousands of users will need a lot more Relay peers than those provided as seeds.
We want to avoid the cost of deploying a lot of Relays in our network, and we want to use the capable peers to provided the relaying for other peers. This is one of the main reasons we chose jxta, because we cannot afford to pay lots of money for infrastructure.

So, to wrap it up: if I start a peer as relay, and it is not among the relay seeds, can it be used by other peers in the network? This is crucial for network scalability.

Joined: 2008-12-22

Yes ivarulz, that is the one million dollar question! Can peers use relays no in the seedingUri?

Thanks turbogeek for your precious info and we would really like a straight answer to this question.

P.S.: hamada previously answered "YES" over here: .

All we need is more confirmation.


Joined: 2007-08-17

:) I read hamada's post, but indeed, we need more assurance in order to take it as a sure fact.

Joined: 2003-06-10

>"(there is no law that says you can't mix traditional web with P2P)."
>>Actually it is. This is a single point of failure that decentralized

I wanted to cover this thought so that you understand what I am getting at here. Mixing other connectivity or information sources can optimize your P2P network.

A good example is the original file sharing software, Napster. It uses one database of music and peers that had the music. Compared to decentralized systems it was very efficient at finding the music. The more expensive costs of music delivery was done via a P2P network. The primary flaw in the ointment is not the centralization of this server infrastructure, but the legal implications of sharing intellectual property. In other words, this was a very efficient and viable service except they went against people that could shut them down with legal means.

So, the main thing to learn about Napster is that it was a good idea, just vulnerable to an attack that had nothing to do with its implementation.

You can argue that there is a single point of failure by using non-P2P. This is only true if you fail to add redundancy. In fact, it is much easier to add redundancy and even recover from very catastrophic failures of fixed infrastructure.

I worked with a company that implemented a backup solution using Jxta. The used LDAP servers for authentication and key management. They had servers in geographically different locations and these servers had their own failover/redundancy at these locations. The LDAP reduced the overall complexity of authentication and provided a means for users to find their data which was hosted on the peers in the network. The result was the application was very fast, had minimal hosting costs and avoided some firewall issues.

The next issue is the peers themselves. One of the greater issues is the Tragedy of the Commons. Simply you need to prevent individual peers from over utilizing resources or even a group from over using specific peers.

Voting, self-selection, and other methods of allocating server peers and client peers is one method, but not always reliable or even easy. Sadly none of this is a built-in service of Jxta. The faster way to build such management is through simple web-based services. I'd also include large databases as this is easier to maintain and we have a pretty good idea of performance.

We currently use simple methods to publish seeds. You go to a URL and scrape the contents from a simple web page. You can have a list of URL in case one site goes down. Bandwidth costs are low and it is easily synced. The same method could be used for publishing public keys or new content or updates.

The key point is that non-P2P should have much lower CPU and bandwidth requirements. Of course easily replicated. That is why I said their is no law you can't use this sort of thing. P2P puts the brunt of the cost on the peers.

Let's look at Relays and infrastructure to this thread. A Relay has a very specific need for what type of connectivity it supports. You must also have the CPU and bandwidth for the client peers. These are not necessarily peers in the true sense. They are servers. They are just running the protocols. It would only be pure P2P if your Grandmother's computer with a dial-up account could be a true contributer to the infrastructure. They are servers, just that I may add and delete these as long as I can get to at least one via a seed that is either published or will never change and is part of my initialization (I use this method myself).

Another example is how I manage my presence service. Simply I have the infrastructure peer handling notifications of peers entering and leaving the group. This is more efficient than other methods, but does mean my infrastructure peer has this burden. I could use a simple web service if I wanted, but went this route because I did not have another server to share port 80.

So, anything is possible. Just think about replication and how either the design is efficient or how you might have fewer problems with affecting the performance or violations of a peer's resources as compared to other peers. I am using a server :0) I have a single point of failure, but only because I have not deployed more servers at this time. In future I will probably add an LDAP because I need to track paying customers and will have a database I need to have centralized for security. Overall though, I will have 99.5% of my system using Jxta.

So, a bit more clear? Have not talked through these things in a while. Always nice to add people to the fold and help you be successful. In case you don't know who I am, I was on the Jxta Board of Directors for many years, wrote a book on Jxta (now out of date), and have many paying jobs where I wrote Jxta applications. Have not been around for a while due to my current job as Chief Architect at No Magic. Writing from our Bangkok office in Thailand but live near Dallas, Texas. You can reach me at turbogeek zat

Message was edited by: turbogeek

Joined: 2003-06-12

- Relay transports are inherited by sub-groups, therefore they only need to be defined in the net peer group

- Relay are also discovered using one of the bootstrapping methods jxta employs (i.e. discovery protocols, and rendezvous/relay bootstrapping protocols, seeding, etc.)

- It is not necessary to isolate a rendezvous/relay from the public dev network, as the public net is by default walled by a ACL, and will not accept other nodes, unless they're defined in it's ACL

- Dynamic relay binding is automatic and does not require a restart, it may however require some network activity to expedite the discovery/bootstrapping/binding.

hope that answers the inquiries.

Joined: 2003-06-10

The big problem with the ACL is that it is not dynamic. You must know the Relay first :o) Also, has anyone tested this? If you can't add a new seed, how would you add it if you did know it?

But this all goes back to the pinning of Relays to the Net group. We go through a lot of trouble to create nice dynamic groups and then throw that away with Relays. Bottom line, how can you limit access to a Relay to one or more groups?

Let's take a battlefield scenario. No reason, just more fun. If I drop a wireless network into place with a relay, I can't ensure the Relay I want the local guys to use will be used. Any reachable relay is fair game, even if it is via several network hops and restricted bandwidth.

A little more talk on connectivity because i heard that was a big concern. On my private infrastructure, I use a RDV/Relay that runs http protocol on port 80. This is one way to get around a large proportion of firewalls. The only barrier is a protocol firewall that only allows a subset of http traffic.

The only time I have seen protocol firewalls was on Wall Street. Sadly folks are paranoid, some with good reason.

If your are running a web server on your Relay box, you are out of luck unless you have a second network card.

Joined: 2003-06-12

> The big problem with the ACL is that it is not
> dynamic. You must know the Relay first :o) Also, has
> anyone tested this? If you can't add a new seed, how
> would you add it if you did know it?

Dynamic ACLs are fully supported, as an ACL is defined as a URI which is periodically refreshed.

> But this all goes back to the pinning of Relays to
> the Net group. We go through a lot of trouble to
> create nice dynamic groups and then throw that away
> with Relays. Bottom line, how can you limit access to
> a Relay to one or more groups?

Define a relay transport for the sub-group!

Joined: 2003-06-10

> Define a relay transport for the sub-group!

Oh? So, that sort of makes sense. However I had never seen an example of this. I have always been told that this is only in the Net group. Seems reasonable.

The question is, are you saying write a transport or to simply use the code that exists and initialize it for the subgroup?

In other words are you saying extend Jxta or turn on something that already exists in Jxta? If it is the later, are there examples?

Joined: 2008-12-22

I found this discussion in the jxta-users mailing-list around 2007:

The topic is Relay discovery.

I see there mentioned the seedingURI and managing it (but it also is a single-point-fo-failure), Multicast discovery(that works outside of LANs too?), route management made by all peers (not just relays) trough a "back-channel" (each peer answers with known routes), RdvAdvertisement used by Relay peers and the fact that a Relay could be discovered if it were a RDV as well.
The question is still not officially answered, or maybe I have missed it.

The last mail states the actual requirements of this problem:
[b]Relay peers are[/b] the most [b]expensive[/b] components of the jxta network. They do the heavy traffic and [b]bandwidth costs money.[/b]
A [b]department/organization[/b] (a [b]group[/b] in my case) would [b]not[/b] like to share their Relay's resources with the rest of the network and would like to have it relaying traffic [b]only[/b] for the current private group.

The seedingURI relays are the ones provided by the network admins in order to ensure connectivity, but they have a connection limit and are ment to be used to bootstrap the network.
This almost forces each group to set up, besides a RDV peer, a Relay peer to ensure communication.
That group Relay peer [b]must[/b] be discovered by the group and used [b]only[/b] by that group.

These are the requirements for, IMO, a very common use-case of the JXTA platform.

So? :)

Joined: 2007-08-17


That was a useful discussion.
I think there were to wires in this discussion:
1) implementing ad-hoc relays and make other peers use them.
Basically this is what we talked about.
2) Limit the connectivity to a relay inside a single group.

1) My conclusion is that ad-hoc relay peers cannot be discovered by other peers in the network (unless on the same subnet via multicast).
The application developers need to provided a bootstrap relay seeds uri.
All peers will use this URI.
A peer that wants to offer relaying services needs to add itself to the list provided by the URI (through web-services, whatever technology you might use to update that list). The main idea is that this is a mechanism outside of jxta.

2)Limit the connectivity to a relay inside a single group. - it's not the case to talk about this in this thread.

Joined: 2008-12-22

In the absence of other *official* confirmation, your conclusion is the only certain thing we know right now.

P.S.: For 2) I`ll start a tread soon because I would really like to achieve this as well.

Joined: 2008-09-22

Hi, well as you know already :) I am using relay peer, but unfortunately I can't help you
because my relay is at the same time RDV and seeding peer.

I would say that peer must be in a peer group to be able to give any sort of service to that group.

Btw relay service is not part of jxte specification, but is only implemented in JXTA, and is activated when peer acts as a relay.

peers will use relay automatically when destination is unreachable without them,

but I don't know is there any other way of discovering relay peer but from seedingURI

Joined: 2008-12-22

Thank you for answering.

So we are talking besides multicast...

The idea was that the seedingURI is used to connect to the network (netPeerGroup) and I was wondering if it will be used to deliver messages to inaccessible peers inside a custom peer group.

So, there are these 2 groups:
NPG (RELAY1, RDV1 - both in seedingURI)

In order to join G1, you first connect to NPG by using seedingURI as entry point and relay.
Now you join G1 and start using RDV2 in order to communicate with the peers inside the group.

Lets assume that RELAY2 is not in the same subnet as you so multicast can't help you locate it automatically. But you can not talk directly to the other peer group members so what do you do?

Will JXTA automatically try to use RELAY1 of the NPG ?

If not, is there any way of figuring out if a peer is a relay peer? (probably you could set a flag in the peer's advertisement. Then you could add that peer as relay peer and jxta should start using it)

Any feedback is appreciated!


Joined: 2008-09-22


well now i Know exactly what you want.

In Practical JXTA book is written that relay peers should be set as seeds for users peers and that RELAY peers need to have static IP address.

So i guess there is no dynamic discovery mechanisms which would discover RELAY peers regardless on multicasting.

In your scenario, It means that you would need to put RDV2 to seedingUriList.

Unfortunately I don't know if RELAY peer can act as a RELAY peer even if it isn't part of the peer group in which relying of traffic is needed. Or in other words I am not shure if you need RDV2

Now even if you could dynamically discover relay peers, i don't think there is a way to make EDGE peer start probing for incoming traffic that discovered peer.

I hope I helped.

Joined: 2003-06-10

As far as I know, this has not been developed. It us a long standing issue as it puts a damper on dynamic scalability. I had thought it was scheduled for 2.5 but it currently does not have it.

Ideally you should just be able to add Relays to your network. However, this can't be managed in intelligent ways for regional performance or to allocate specific users to a higher or lower performance Relay.

There is a workaround. Relays are allocated based on your NetPeerGroup. It is a simple matter to change the ID of this group. You need to have peers start up with the specific network, so you can't manage it as the peer is running. You could log into a network that knows about the load and then join one with a Relay that has capacity. You can also do this based on another method, like a web service that gives you the group (there is no law that says you can't mix traditional web with P2P).

Changing the NetPeerGroup is also important for creating your own private Jxta network. This isolates you from any other network. Only peers that have this id can join. If you are setting up a private network for a commercial application, this is what you want to do. This ensures that you and only you determine the Relay/RDV and who has access.

Here is some code to get the job done. I do it through a properties file. There may be a different way that sets the ID via the API, but this is the only one I use.

net.jxta.peergroup.PeerGroupID pgID = MD5ID.createInftrastructurePeerGroupID(infraBase,infraSeed);
String idStr = pgID.toString();
id = idStr.substring(id.indexOf("jxta:")+5);

System.setProperty("NetPeerGroupDesc","My group description ");

// We can write this so that JXTA can see it.

public static void writePrivateGroupProperties(String infraBase, String infraSeed, String myNameForNetGroup,String mydesc){
File file = new File("");
net.jxta.peergroup.PeerGroupID pgID = MD5ID.createInftrastructurePeerGroupID(infraBase,infraSeed);
String id = pgID.toString();
if(id.indexOf("jxta:") !=-1){
id = id.substring(id.indexOf("jxta:")+5);
FileWriter writer = new FileWriter(file);
}catch(IOException ioe){
LOG.error("Unable to create",ioe);

Joined: 2008-12-22

So, you are suggesting:
1) change the infrastructureID to a custom one so I can safely be detached from the public network. (good ideea, thanks)
2) use a bootstraping network or a web service that manages network load and that tells me what network(rdv/relay seeds) to join in order for the load to be balanced.

I am not interested in regional performance as much as in network connectivity. I want my peers to communicate more than I want them to communicate extra fast. That would be nice too, but it's the second priority.

"(there is no law that says you can't mix traditional web with P2P)."
Actually it is. This is a single point of failure that decentralized, p2p solutions try to avoid. The jxta bootstrap process (seedingURI) is quite an issue just as it is(luckily multicasting is supposed to help fix this), there is no need for another such (static) element.

Thanks for the idea but it seems a bit cumbersome to manage all of that.

Back to my original question:
"Can sub-group peers automatically use network(netPeerGroup) relays for communication when point-to-point is not possible?"
For rendezvous it seems this is not possible, each group requiring at least one RDV peer.

My network layout is simple:
- networkRoot (netPeerGroup) with seedingUri pointing to a web location. (entry-point)
- secure network groups (each having auto-start RDVs ot enable communication inside the group)

Peers may change groups but all communication is made inside the group.

For this simple layout I have solved the RDV problem by making the group creator automatically RDV. Joining peers will automatically be RDVs by default as well but will have auto-start enabled to they can be demoted or re-promoted back to RDV/EDGE by JXTA based on the network's state.

For the Relay problem I haven't got a solution yet.

The main communication in my group is made trough propagate pipes, meaning through RDV peers. But when RDVs can't communicate with their destination peers or when (occasionally) a peer needs to talk to another peer and can not do so directly, I need Relays.

If a peer joins a group as Relay, I would like the other peers to use it when they need to. It is a shame there is no such notification mechanism as for RDV events. A possible work-around would be for relay peers to publish advertisements and for other peers to query them. When they see a relay advertisement, they should register that relay.

Here we have another problem. Registering a relay is done at network connect time though the network manager. This means that a peer has to disconnect, add relay seed the new relay and reconnect. This sounds really nasty. (more or less like your proposition turbogeek)

P.S.: Is it really required to restart the network in order to use the manager.addRelay/RendezVousSeed(...) method of adding seeds?

Thank you for your help and I would really appreciate other suggestions as well.

Joined: 2008-10-22


> P.S.: Is it really required to restart the network in
> order to use the manager.addRelay/RendezVousSeed(...)
> method of adding seeds?
I am dealing with that issue, too. When I use the rdv-method while a peer is running, it has absolutely no effect, so until now I think restarting the network is the only way...


Joined: 2008-12-22

Nobody worked with Relay peers?