Skip to main content

Multiple Rendezvous and Relays configuration

16 replies [Last post]
alexkaidalov
Offline
Joined: 2007-07-16

We'd like to create our p2p network and go public.

To manage peers behind firewalls we need to arrange rendezvous and Relay peers
somewhere in the internet accessible from anywhere.

I think we need several Rendezvous and Relay peers to be secure.

Is there any hints how to setup such network, how Rendezvous should see each other, or even Relays see each other? Because if for example we have one
Rendezvous peer and one Relay it's fine, if we add another pair we have problems
with peer discovery.

thanks for any help
Aleks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
adamman71
Offline
Joined: 2007-01-31

>
> What about autoStarted RDVs (peers that have auto
> become RDVs when needed)? How will they be
> used/seen/discovered by (new) peers?

They will be detected by other peers on the LAN assuming that they are part of the same peergroup. But if nothing else is done, they will remain alone in the dark.

> 1. Will they broadcast a rdv advertisement and all
> the peers in the group will see them?

Nope.

> 1.1 Will the peers automatically add them?

Nope.

> 1.2 Do peers have to register a rdv service listener
> and manually issue addRdvSeed?

Nope, don't do that, never. It is not necessary.

> 2. Do the newly promoted rdvs have to manually
> register to the central seeding uri?

If a newly promoted peers knows about other RDVs of the same peergroup (via the seeds its knows for example or via another RDV on the LAN when multicating is enabled) and manage to establish a connection to one of them, then it is enough. It will be part of the RDV peerview of the group (which is another way of saying that it will be well connected to the rest of the peergroup).

> 2.1 If so, the central uri will have to have a
> monitor for the list and periodically remove peers
> that are no longer online?

Nope. That is done automatically by JXTA. There is a mechanism probing peers and requesting them to answer to the probe within a specific delay. If not answer is received, the probed peers is assumed to have gone off-line and is taken out of the list.

> 2.2 When peers get demoted back from RDVs to edge
> peers will they have to manually remove themselves
> from the central seeding uri?
>

No, and the question is not relevant. There is no need for a RDV peer to get registered in a central seeding URI (although if decide to implement such a seeding center, then the answer to your question is yes).

> P.S.: Re firewall problems, I suppose the same
> solution as for RDVs will be applied. With the
> exception that there is no autostart here and newly
> (manually)started relays would in fact have to
> register to the central URI or, if not, be discovered
> by LAN multicast.
>

Correct. Keep in mind that if you set-up your peers in a peer group the proper way, you can seriously minimize the probability of having to rely on relays. Being nice to your network administrator and to your customer's network administrator pays a lot...

> Thanks for the help so far,
> Eduard.

enygma2002
Offline
Joined: 2008-12-22

Thank you!

enygma2002
Offline
Joined: 2008-12-22

Please see this message: http://forums.java.net/jive/thread.jspa?messageID=327102&#327102

It seems that the public RDVs are network islands. :( Is this normal?

adamman71
Offline
Joined: 2007-01-31

> Please see this message:
> http://forums.java.net/jive/thread.jspa?messageID=3271
> 02񏶾
>
> It seems that the public RDVs are network islands. :(
> Is this normal?

Yes it is normal. But seeds will help them connect to each other. Basically, if a RDV is connected to a 'seed' RDV or to a RDV that is (eventually transitively) connected to a 'seed' RDV, then everything will go fine. They will be part of the same peerview.

Cheers,

J.

enygma2002
Offline
Joined: 2008-12-22

I can`t access that forum section. The error I get is:

"Error: you do not have permission to view the requested forum or category. "

So the answer would be that the advertisements published by me on RDV A has not yet been propagated to RDV B, but eventually, they will both share the same state and my advertisement will be found on both? So it`s a matter of time?

It's weird that sometimes (rarely enough) it works just fine(and instantly), but most of the time, my group advertisement does not appear instantly on both RDVs and waiting that long is not an option (for unit testing).

adamman71
Offline
Joined: 2007-01-31

Your error is caused by the fact that the link has been split over two lines.

> So the answer would be that the advertisements published by me on RDV A has not yet
> been propagated to RDV B, but eventually, they will both share the same state and my
> advertisement will be found on both? So it`s a matter of time?

Your published advertisements are not propagated to RDV, never. However, RDVs implement an SRDI index + keep in mind that advertisements have some index fields. From time to time, the RDV's index is updated with the index fields of the advertisements located on connected peers, and (if I am not wrong) parts of SRDI indexes located on other RDVs.

This optimizes the forwarding of queries by RDVs to edge peers, who can reply to advertisements requests.

Imagine a network of 1 000 000 nodes where RDVs would have to store all advertisements published by every peer, it would automatically crash... Local peers are not capable of supporting this.

Hope this helps,

J.

enygma2002
Offline
Joined: 2008-12-22

Ok, I totally forgot about the SRDI :)

Thanks!

adamman71
Offline
Joined: 2007-01-31

Hi,

i) Typically, your relays peers must have a public IP address. Any IP packets must be forwarded as is by routers/firewall if these are located behind it. If you can make these relay peers RDV peers too, that is even better.

These will be your seed peers.

Then, make sure your edge/simple peers know how to contact those seeds peers. Typically, they could fetch that information from a URL.

ii) You may also want to let your edge/simple peers automatically become RDV when necessary. This will facilitate the overall connectivity of your network.

ii) > if we add another pair we have problems with peer discovery.

Can you describe the problems you face in this situation? Are you getting the same request several times? If yes, this could be because the request is sent via multicasting and forwarded by RDV peers too. JXTA does not guarantee that a request will arrive once and only once to a peer. The same request may arrive multiple times. This has to be managed.

iv) Keep in mind that it is possible to let a peer become a RDV automatically, but not a relay automatically.

Cheers,

J.

enygma2002
Offline
Joined: 2008-12-22

Hi!

1. What would be good enough reason not to always have Rendezvous and Relay roles on the same peer? (have only super-peers instead of specialized peers)

Is is that the peer will be too stressed with traffic?

1.1 Do you recommend always enabling autoStart on relay peers so that they automatically become Rendezvous peers automatically? (when needed. -- when exactly is this "when needed" happening?)

2. Also, back to the original question of this thread, how do you configure multiple seed peers to know about each other? For normal peers it's easy, you have 2-3 seeds and ask them to route requests and traffic.
What happens to the seed peers themselves? How do you configure a newly added seed? Is there a risk of creating 2 separate networks, one not knowing about the other?
How is this handled in JXTA?

Sorry for the numerous questions but I would really like to know.

Thanks.

adamman71
Offline
Joined: 2007-01-31

1. Relay peers are typically used as seed peers. RDV are not necessarily used as seeds (only a few ones are used to bootstrap your network's connectivity). You may end up in a situation where you need more Relay peers to run your network (because of traffic) than RDV peers to bootstrap your system's connectivity. So, you could have Relay only super-peers...

But a super-peer with a public IP address is something valuable, so my opinion is that it would be a good idea to use it as a RDV seed too.

1.1 If you are running JXTA on small devices (handheld, etc...), I would not use autostart, because it might be too much work for them. But on other PCs and server, I definitively would. The system would regulate automatically.

2. Just create the list of seeds (using route advertisements or IP addresses) and set this list as the set of seeds in your seed peers (and let the system work this out). You won't create 2 separate networks if everyone shares the same list of seeds.

You can have your peers fetch the list of seeds from a URL. They will regularly check it from time to time and take any modifications into account when necessary. So, you just have to update your list to add new seed peers.

If you use autostart for RDV and a unique list of RDV seeds, they system will work its way through to maintain overall connectivity between RDVs with the peergroup.

Cheers,

J.

enygma2002
Offline
Joined: 2008-12-22

Hi J!

Re: 2.

By this you mean something like the default seeds provided for jxta? (http://rdv.jxtahosts.net/cgi-bin/rendezvous.cgi?3)

If so, how do the rendezvous peers in the list know each other? Do they, themselves, have to check that list too when initializing themselves so that they learn one of each other and so they can also tell other edge peers about the other rendezvous peers?

To put it short:
(Manually?) Create a URL like http://rdv.jxtahosts.net/cgi-bin/rendezvous.cgi?3

A Rendezvous peer must:
- initialize the jxta network and set the central URL by using addRdvSeedingURI(java.lang.String).
-- the JXTA system will automatically serve incomming requests from edge peers and will forward requests to rendezvous peers in the provided list.

An Edge peer must:
- initialize the jxta network and set the central URL by using addRdvSeedingURI(java.lang.String).
-- the jxta system will automatically use rendezvous peers from the provided list.

Is this all the setup required?
Did I get something wrong?

P.S.: I suppose it is good practice to have at least 2 such seeding URL's. If one goes down, use the other. Here, the synchronization between the 2 would have to be manually done, right?
-- Also, please tell me if there is a JXTA mechanism for creating such a URL. (looks like an advertisement to me, but not sure how to make one like this and make it available trough HTTP)

Thanks!

adamman71
Offline
Joined: 2007-01-31

If so, how do the rendezvous peers in the list know each other? Do they, themselves, have to check that list too when initializing themselves so that they learn one of each other and so they can also tell other edge peers about the other rendezvous peers?

-> Let's imagine two pockets of peers connected by their own respective set of RDVs. What you need to achieve is to make sure that one RDV from one pocket gets to know about one RDV of the other pocket. That's enough to connect peers from both pockets.

To put it short:
(Manually?) Create a URL like http://rdv.jxtahosts.net/cgi-bin/rendezvous.cgi?3

-> That would be a solution. If you are running your own set of RDV to bootstrap your network/PeerGroup, you may want to create a 'secret' RDV seed for those RDV in order to help them connect to each other.

A Rendezvous peer must:
- initialize the jxta network and set the central URL by using addRdvSeedingURI(java.lang.String).
-- the JXTA system will automatically serve incomming requests from edge peers and will forward requests to rendezvous peers in the provided list.

-> Yes, though you could use a secret RDV peer with a secret URL for your bootstrapping RDVs. The point of doing this is that RDV peers can only accept a maximum number of connection. If that point is reached, you face the risk that pockets may not be able to connect with each other. The secret RDV reduces that risk.

An Edge peer must:
- initialize the jxta network and set the central URL by using addRdvSeedingURI(java.lang.String).
-- the jxta system will automatically use rendezvous peers from the provided list.

-> Yes, and it could also use RDVs it could find on the LAN using multicasting.

Is this all the setup required?

-> Yes if you ignore firewall issues

Did I get something wrong?

-> Nope.

P.S.: I suppose it is good practice to have at least 2 such seeding URL's. If one goes down, use the other. Here, the synchronization between the 2 would have to be manually done, right?

-> That would mitigate the risk of lack of connectivity, indeed. If all URL go down after the network has already been bootstrapped, the peergroup will survive for a long time with a high probability if the RDV don't get down themselves. Only new peers may find it hard to establish a first connection to other peers in the peer group. Typically, they would need to find a RDV from this peergroup on their LAN via multicasting. You can increase this probability of liveliness by letting your peers automatically become RDVs when necessary.

-- Also, please tell me if there is a JXTA mechanism for creating such a URL. (looks like an advertisement to me, but not sure how to make one like this and make it available trough HTTP)

-> It is an Endpoint Advertisement (unless I am wrong). You should find the factory object creating those advertisements in the JXTA code, then calle toString() or any other similar method. Put the result in a file and post it on a web server.

enygma2002
Offline
Joined: 2008-12-22

Very helpful J, thanks!

One last thing please:

What about autoStarted RDVs (peers that have auto become RDVs when needed)? How will they be used/seen/discovered by (new) peers?
1. Will they broadcast a rdv advertisement and all the peers in the group will see them?
1.1 Will the peers automatically add them?
1.2 Do peers have to register a rdv service listener and manually issue addRdvSeed?
2. Do the newly promoted rdvs have to manually register to the central seeding uri?
2.1 If so, the central uri will have to have a monitor for the list and periodically remove peers that are no longer online?
2.2 When peers get demoted back from RDVs to edge peers will they have to manually remove themselves from the central seeding uri?

P.S.: Re firewall problems, I suppose the same solution as for RDVs will be applied. With the exception that there is no autostart here and newly (manually)started relays would in fact have to register to the central URI or, if not, be discovered by LAN multicast.

Thanks for the help so far,
Eduard.

ryanblues
Offline
Joined: 2008-10-09

I'm also interested in this issue, and I think many other users do need the answers. Actually this thread provides a lot of useful information regarding the Rendezvous peer behavior, I'd like to propose to TOP this thread as as one of Rendezvous peer FAQ in the forum, so we could avoid to dig out all the information related to Rendezvous over the entire forum.

Best Regards,
Ryan

saerka
Offline
Joined: 2008-10-17

i have the same problem with you, and i want to know which redezvouse or relay peer i have connected, if you have solved this problem, will you please tell me? thank you!

alexkaidalov
Offline
Joined: 2007-07-16

No, my problem is how to configure several rendezvous and relays,
but you can use the folloving

RendezVousService.getConnectedRendezVous() -method
/**
* Returns an Enumeration of the PeerID all the RendezVous on which this
* Peer is currently connected. This returns the same result as
* {@link #getConnectedPeers()}.
*
* @return Enumeration enumeration of RendezVous.
*/