Skip to main content

Questions about relay servers

4 replies [Last post]
kg
Offline
Joined: 2007-08-08
Points: 0

Hello,

I understand enough about NAT traversal to see why relay servers are used in the JXTA framework. My application will involve a lot of bandwidth, so I have particular concerns about moving lots of data through relay servers. I also won't be able to afford hosting lots of relay servers myself. Can someone please provide me with perspective on the following?

1) In JXTA, are relay servers used as a primary means of circumventing NAT traversal, or are other techniques like STUN and tunneling used under the hood to limit the use of relay? Again, I'm interested in avoiding relay and would prefer to see direct peer to peer connectivity.

2) When I set up a peer group, will applications running in my group be able to use resources of relay servers that are not in my group? For example, if there are not enough relay servers in my group, will the JXTA community lend a hand? Or, am I limited to the instances distributed within my group?

3) What environment is best suited for a relay super peer to run? Do they have to be running somewhere with a public IP? I suspect a relay running from a home PC is not a good candidate if behind NAT unless that NAT is manually configured. Can someone please confirm?

Thanks!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
hamada
Offline
Joined: 2003-06-12
Points: 0

> 1) In JXTA, are relay servers used as a primary means
> of circumventing NAT traversal, or are other
> techniques like STUN and tunneling used under the
> hood to limit the use of relay? Again, I'm interested
> in avoiding relay and would prefer to see direct peer
> to peer connectivity.

Relay are used to traverse NAT/Firewall. There has been some experimentation with STUN/STUNT, however the only fruit was a UDP transport, mostly due to lack of STUN/STUNT server java implementation (at least license compatible). There's also has been some work enabling UPnP dynamic NAT configuration, some would integration work would have to be done though.

>
> 2) When I set up a peer group, will applications
> running in my group be able to use resources of relay
> servers that are not in my group? For example, if
> there are not enough relay servers in my group, will
> the JXTA community lend a hand? Or, am I limited to
> the instances distributed within my group?

The relay transport is a netpeergroup transport which is inherited by all sub-groups (unless of course overridden by a sub-group definition)

>
> 3) What environment is best suited for a relay super
> peer to run? Do they have to be running somewhere
> with a public IP? I suspect a relay running from a
> home PC is not a good candidate if behind NAT unless
> that NAT is manually configured. Can someone please
> confirm?

A relay node must be reachable by it's clients.

e.g.
edge relay edge
edge relay relay edge

As far as capacity planning, a node should offer relay services according to it's available resources (memory and bandwidth).

kg
Offline
Joined: 2007-08-08
Points: 0

Thank you both for taking the time to respond. Your input has been very helpful to me. I have a few more questions that may help me understand whether or not JXTA is a good fit for my project.

1) Thanks for confirming. All I can say is that Google seems to be doing some really interesting stuff with their Jingle library (http://code.google.com/apis/talk/libjingle/index.html). They provide something called Pseudo TCP which seems to be UDP transport with TCP translation at endpoints. They claim this facilitates direct P2P transfer 92% of the time (fallback to relay for the other 8%). Introduction of a similar solution to the JXTA framework would definitely require STUN, but I'm not sure I understand your remarks on previous attempts to do so. Is an open source implementation of a STUN server all that is required? Can you expand on the license issues a little?

2) Gotcha. Any idea if there is a way to get a fairly recent count of public relays floating around out there?

3) It seems that the potential for a peer to act as a relay is relatively low. I say this because it seems like introduction of wi-fi is making NAT more and more common amongst potential peers. In my scenario, we expect customers to be anything but technical, so I'm not banking on their ability/interest in manually configuring their environment.

At the same time, need for relays goes up as more peers behind NAT are introduced. This ratio is obviously bad for JXTA community as a whole, right? As a private entity, the only answer I see is to personally sponsor the operational costs (bandwidth/hardware/maintenance) of relay and exclude other peer groups. Unfortunately, this goes against my strategy of leveraging resources available amongst peers.

4) Given the obstacles mentioned in #3, is it possible that JXTA is currently better suited for enterprise rather than consumer solutions?

5) I haven't been able to find any benchmarks outside of latency analysis. Does anyone know of studies that focus on bandwidth or current relay super peer to peer ratios?

hamada
Offline
Joined: 2003-06-12
Points: 0

> Thank you both for taking the time to respond. Your
> input has been very helpful to me. I have a few more
> questions that may help me understand whether or not
> JXTA is a good fit for my project.
>
> 1) Thanks for confirming. All I can say is that
> Google seems to be doing some really interesting
> stuff with their Jingle library
> (http://code.google.com/apis/talk/libjingle/index.html
> ). They provide something called Pseudo TCP which
> seems to be UDP transport with TCP translation at
> endpoints. They claim this facilitates direct P2P
> transfer 92% of the time (fallback to relay for the
> other 8%). Introduction of a similar solution to the
> JXTA framework would definitely require STUN, but I'm
> not sure I understand your remarks on previous
> attempts to do so. Is an open source implementation
> of a STUN server all that is required? Can you expand
> on the license issues a little?

I knew of the jingle activities, however I have not followed up on their progress as of late, I'll check it out as soon as I get some free time.

as far as licensing, for source inclusion it must be JXTA license which is an apache variant. for runtime LGPL is acceptable.

>
> 2) Gotcha. Any idea if there is a way to get a fairly
> recent count of public relays floating around out
> there?

That would be difficult to quantify, as the public development network restrict nodes from offering rendezvous and relay service to those the ACL. In addition most deployments would further restrict access by deploying an alternate group from the default net peer group.

>
> 3) It seems that the potential for a peer to act as a
> relay is relatively low. I say this because it seems
> like introduction of wi-fi is making NAT more and
> more common amongst potential peers. In my scenario,
> we expect customers to be anything but technical, so
> I'm not banking on their ability/interest in manually
> configuring their environment.
>
> At the same time, need for relays goes up as more
> peers behind NAT are introduced. This ratio is
> obviously bad for JXTA community as a whole, right?
> As a private entity, the only answer I see is to
> personally sponsor the operational costs
> (bandwidth/hardware/maintenance) of relay and exclude
> other peer groups. Unfortunately, this goes against
> my strategy of leveraging resources available amongst
> peers.

It's key that we enable uPnP configuration, or STUN/STUNT support so that a larger pool of nodes can offer relaying services.

>
> 4) Given the obstacles mentioned in #3, is it
> possible that JXTA is currently better suited for
> enterprise rather than consumer solutions?

JXTA is best suited for hybrid deployments, whether it be enterprise or consumer. The idea is deploy a set of capable nodes to provide relaying and rendezvous services. However, I agree with, by enabling edge to offer limited relay/rendezvous goes to increasing scalability.

It's key that we support STUN/STUNT or NAT configuration to expose such capability.

>
> 5) I haven't been able to find any benchmarks outside
> of latency analysis. Does anyone know of studies that
> focus on bandwidth or current relay super peer to
> peer ratios?

I am not aware of any either, however a community member did offer to do so, but I have not heard from him yet.

drrsatzteil
Offline
Joined: 2007-03-23
Points: 0

Hello,

1) As far as I know relays are the only technique used as there is no way to pass messages between peers in NAT environments without a relay peer.

2) I'm pretty sure that relays do work no matter in what group they are.

3) Absolutely, the relay peer must not be behind a NAT or behind a manually configured one.

In our application we sent large amounts of small images through the network. When we used a single relay in a 100 peer network we got hundreds of megabytes of traffic in minutes. For relays that are not connected via fibre, unlike the one we used, this will be a huge problem.

I think you should have as many relays as possible in your network. Every peer that can be connected directly should be configured as a relay peer.