Skip to main content

Routing in JXTA

6 replies [Last post]
galato
Offline
Joined: 2007-07-06
Points: 0

Hi all,

if this is not documented anywhere (in specs or otherwise) can anyone shed some
light on the details?

Peer A, behind a NAT let's say, will connect to a RDV
and send its info to it - what kind of info is this?
If it generates a server pipe and it advertises it with
the RDV, what kind of info does it send then? Do either of
these contains routing information?

Peer B, also behind a NAT, will contact the RDV to find
Peer A's server pipe. What does it get as information?
When does it realize that Peer B may not directly accessible
and it will need to go through a relay to find it? And
does Peer A need to have contacted the relay with its info
so that it knows where it is and it has a route to it?

The reason I am asking this is that I have the RDV and RLY both
residing in the public domain. Is it beneficial to have a relay
dedicated for each edge Peer behind a NAT advertising the public
IP of the corresponding router so that remote peers can find it?
Or is a public RLY a better soln?

Thanks

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
galato
Offline
Joined: 2007-07-06
Points: 0

One a related note -

in the 2.5 JXTA programmer's manual there were a couple of statements:

1. If you are behind NAT you should use http
2. if you need to use tcp then you should probably send your public IP Address to the router

Another one stated, usually a peer will get a message box in memory from the relay to help relay messages.

No other info on these. Are these statements still valid for 2.6 - and how do you interpret them? I don't think it is a requirement to use http if you are behind NAT - as we all know. Is it necessary if you are sending your public IP to also send your local IP address? I don't think so right? And what is this message box in memory for the relay case? I thought you setup your pipes the same way you would set them up if you were not behind the relay and the JXTA routing mechanism will take care of the rest.

Thanks

galato
Offline
Joined: 2007-07-06
Points: 0

Also, a 2.6 peer behind a NAT connects to the RDV/RLY - but the RDV/RLY cannot
form a connection back to the peer. It tries to find routes ( I don't show the complete
log) for a while but still no connection. This works if I switch the peers back toi 2.5:

RDV(Thread[PeerToPeerAdapter,5,main]): Has 1 peers connected to it

Sep 5, 2010 1:35:00 AM net.jxta.logging.Logging logCheckedInfo
INFO: Line 136 net.jxta.impl.endpoint.netty.NettyTransportClient.getMessenger()
processing request to open connection to tcp://72.90.155.75:19801

Sep 5, 2010 1:35:01 AM net.jxta.impl.util.threads.LongTaskDetector run
WARNING: task of type [net.jxta.impl.endpoint.netty.NettyMessenger$1] still running after 1,008ms in thread JxtaWorker-4, current stack:
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:146)
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:912)
java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1201)
java.util.concurrent.CountDownLatch.await(CountDownLatch.java:245)
net.jxta.endpoint.MessengerStateBarrier.awaitMatch(MessengerStateBarrier.java:59)
net.jxta.endpoint.AbstractMessenger.waitState(AbstractMessenger.java:245)
net.jxta.impl.endpoint.EndpointServiceImpl.getMessenger(EndpointServiceImpl.java:2044)
net.jxta.impl.rendezvous.PeerConnection.getCachedMessenger(PeerConnection.java:329)
net.jxta.impl.rendezvous.rdv.ClientConnection.connect(ClientConnection.java:98)
net.jxta.impl.rendezvous.rdv.RdvPeerRdvService.addClient(RdvPeerRdvService.java:507)
net.jxta.impl.rendezvous.rdv.RdvPeerRdvService.processLeaseRequest(RdvPeerRdvService.java:652)
net.jxta.impl.rendezvous.rdv.RdvPeerRdvService.access$200(RdvPeerRdvService.java:115)
net.jxta.impl.rendezvous.rdv.RdvPeerRdvService$StdRdvRdvProtocolListener.processIncomingMessage(RdvPeerRdvService.java:254)
net.jxta.impl.endpoint.EndpointServiceImpl.processIncomingMessage(EndpointServiceImpl.java:1027)
net.jxta.impl.endpoint.router.EndpointRouter.processIncomingMessage(EndpointRouter.java:1657)
net.jxta.impl.endpoint.EndpointServiceImpl.processIncomingMessage(EndpointServiceImpl.java:1027)
net.jxta.impl.endpoint.netty.NettyMessenger$1.run(NettyMessenger.java:148)
net.jxta.impl.util.threads.RunnableAsCallableWrapper.call(RunnableAsCallableWrapper.java:17)
net.jxta.impl.util.threads.RunMetricsWrapper.call(RunMetricsWrapper.java:50)
net.jxta.impl.util.threads.QueueTimeRunMetricsWrapper.call(QueueTimeRunMetricsWrapper.java:34)
net.jxta.impl.util.threads.RunMetricsWrapper.run(RunMetricsWrapper.java:93)
net.jxta.impl.util.threads.QueueTimeRunMetricsWrapper.run(QueueTimeRunMetricsWrapper.java:9)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
java.lang.Thread.run(Thread.java:595)

Sep 5, 2010 1:35:05 AM net.jxta.impl.endpoint.netty.NettyTransportClient getMessenger
INFO: Netty transport for protocol tcp failed to connect to tcp://72.90.155.75:19801 within acceptable time

Sep 5, 2010 1:35:05 AM net.jxta.logging.Logging logCheckedWarning
WARNING: Line 449 net.jxta.impl.endpoint.router.EndpointRouter$EndpointGetMessengerAsyncListener.messengerReady()
null messenger for dest :jxta://uuid-59616261646162614E504720503250336ECCFFB1609C49A9B022EB4A22C8297303

adamman71
Offline
Joined: 2007-01-31
Points: 0

> Peer A, behind a NAT let's say, will connect to a
> RDV
> and send its info to it - what kind of info is this?
Minimum = route adv and peer adv

> If it generates a server pipe and it advertises it
> with
> the RDV, what kind of info does it send then?
pipe adv

> Do
> either of
> these contains routing information?
if adv is exchanged, then route adv is exchanged too

> Peer B, also behind a NAT, will contact the RDV to
> find
> Peer A's server pipe. What does it get as
> information?
pipe adv and route adv (and may be peer adv)

> When does it realize that Peer B may not directly
> accessible
> and it will need to go through a relay to find it?
By checking endpoint addresses in known route adv to target peer.
If don't work, try more. Eventually fetch more routes to target peers from other peers. Relay routes have lower priorities, faster routes are attempted first.

> And
> does Peer A need to have contacted the relay with its
> info
> so that it knows where it is and it has a route to
> it?
No. If B can fetch route to A. It is enough. If B 'sees' relay, relay will tell it knows how to contact A.

>
> The reason I am asking this is that I have the RDV
> and RLY both
> residing in the public domain. Is it beneficial to
> have a relay
> dedicated for each edge Peer behind a NAT advertising
> the public
> IP of the corresponding router so that remote peers
> can find it?
Relay behind NAT does not make sense, unless it has a public IP address.
One relay for many peer is enough.

> Or is a public RLY a better soln?
Yes. The other option is not a 'solution'.

> Thanks

galato
Offline
Joined: 2007-07-06
Points: 0

Ok on most of these - regarding the relays. Let's take this example:
Peer A behind NAT
Peer B behind NAT
RDV/RLY in public domain

Both peers are aware of the public relay - each of them have a seeding with
the IP address of the RDV/RLY. Once they are connected to the RDV/RLY
the super peer will be aware of routes to each of the peer. Both peers
advertise a server pipe with the RDV and each of them get each other's
server pipe adv. When they attempt to establish connection to each other's
server pipe they will see that direct comms with each peer is not possible,
so they will find out from the relay how to reach each other. Comms thereafter
will need to travel through the relay.

And as long as the relay seeding in both relays as well as the relay setup
is correct then this relaying should occur automatically while both the relay
and the peers attempt various routes - correct?

Jerome, in the transition from 2.5 to 2.6 the code that dealt with NAT needed
to be fixed/refactored right? Would it be easy for me to find out which incidents
were opened for this purpose so that I can look into the improvements and fixes
that were made?

Thanks

adamman71
Offline
Joined: 2007-01-31
Points: 0

> Both peers
> advertise a server pipe with the RDV and each of them
> get each other's
> server pipe adv.
You don't necessarily need to post it on the RDV.

> When they attempt to establish
> connection to each other's
> server pipe they will see that direct comms with each
> peer is not possible,
> so they will find out from the relay how to reach
> each other. Comms thereafter
> will need to travel through the relay.
>
> And as long as the relay seeding in both relays as
> well as the relay setup
> is correct then this relaying should occur
> automatically while both the relay
> and the peers attempt various routes - correct?
Yes. It fact, this would also work if they were connected to different relays and the relays had a route to each other.

> Jerome, in the transition from 2.5 to 2.6 the code
> that dealt with NAT needed
> to be fixed/refactored right? Would it be easy for me
> to find out which incidents
> were opened for this purpose so that I can look into
> the improvements and fixes
> that were made?
Yes. I think I have already mentioned this incident to you before during email exchanges. It is the patch from Mirron Rosanov. Check closed incidents for 2.6.

Subversion allow searching code history too.

galato
Offline
Joined: 2007-07-06
Points: 0

Ok good - thanks Jerome. Yes I remember the incident now so I will follow up with it.