Re: JXTA private net problems

I took another look at the NetworkConfigurator and wondered if 
config.setTcpPublicAddress(address, exclusive); wouldn't actually do the 
same ?

Vince


Jeff Schultz wrote:
>> Sorry for the confusion ;)
>> 10.1.14.132 is the IP of my PC and 192.168.13.6 is used in the DMZ and 
>> 83.64.248.67 is the external IP. But I just took my server out of the 
>> DMZ and directly connected it to the Internet and WOHOOOOO .... it 
>> finally works ;) I was able to connect to my Rdv/Relay!
>>
>> To sum up I had two problems:
>> 1) Using hostnames as seeding URI did not work.
>>     Only IPs are valid!
>> 2) Running a Rdv/Relay behind a router with portforwarding does not work!
>>     The server MUST have an Internet addressable IP for JXTA to work.
>>     
>
> It can't work unless the router is told to allocate a fixed port
> number, forwards the packets properly, and, critically, the JXTA RDV
> process knows it's happening.  This is because while the router
> changes outgoing packets to pretend they come from the external
> address, it can't do anything to the content, including the JXTAHELLO
> generated by the RDV.  (I'm not clear why it needs to announce the
> interface it's using in this way, but it does do it, and it needs to
> use the right, reachable, address for it.)
>
> If you're configuring the RDV programmatically, you'll need something
> like the following, with, in your example, localAddress
> "tcp://192.168.13.6:9901" and publicAddress "tcp://83.64.248.67:9901":
>
>     TcpTransportAddress tcpAddress = new TcpTransportAddress();
>     tcpAddress.setAddress(new URI(localAddress));
>     . . .  // more configuration
>     TcpTransport tcpTransport = new TcpTransport();
>     tcpTransport.setAddress(tcpAddress);
>     if(proxyURI != null) {
> 	PublicAddress publicAddress = new PublicAddress();
> 	publicAddress.setAddress(new URI(proxyURI));
> 	publicAddress.setExclusive(true);
> 	tcpTransport.setPublicAddress(publicAddress);
>     }
>
>
> Configured like this, it does work, but it has two problems:
>
> 1) It's a pain to deploy unless you're only setting up a couple of
> processes.  It's useless for an end-user deployment unless you feel
> like getting UPnP to work, and even then, I doubt it's worth trying.
>
> 2) Don't try this at home.  As Mark says, consumer-grade routers are
> unlikely to do the right thing all the time, although in my experience
> they work for a few tens of thousands of messages and then lock-up.
>
>
>     Jeff
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
>