Skip to main content

Does JXTA support IGD UPnP enabled routers?

3 replies [Last post]
quitequick
Offline
Joined: 2008-11-15
Points: 0

I want to write a consumer level p2p cross internet browser based applet that does not require any router configuration. My average consumer does not have the knowledge/expertise/inclination to start opening ports on a router. I also don't want to have to support/pay-for infrastructure servers to to enable a working p2p network (although I know I would need something for peer discovery). I'm looking into p2p to avoid the client/server shortcomings. So I'm looking into JXTA to see if it would be a good fit.

In the JXTA docs, the section 'Firewalls and NAT' says...

'A peer behind a firewall can send a message directly to a peer outside a firewall, but a peer outside the firewall cannot establish a direct connection with a peer behind the firewall. The same is true for peers which are behind a NAT device.'

I interpret that to mean that if peer A is behind a NAT it will therefore need a relay beyond the NAT if it wants to communicate with peer B - which is somewhere across the internet - even if peer B is *not* behind a NAT . Am I correct in this interpretation?

It seems that all new routers have IGD UPnP these days - so much so that I am happy to make it a requirement to run my applet. I really want to avoid a client/server setup! However, in the future I may setup a server to handle those people that don't have IGD UPnP. I understand Spotify works on a similar principal.

I can see no reference to UPnP IGD devices anywhere in the docs. So my question is...

Does JXTA support automatic NAT port mapping on IGD UPnP enabled routers? If not, are there any plans to? If it does, does that mean that I don't need a relay for those peers behind such a device?

Thanks for reading!

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Hi,

it is not currently supported - if you have the skills you can port a new transport into JXTA. We can help you with that.

In the medium term I believe this is something the JXTA community will take on and implement.

Regards,
John

quitequick
Offline
Joined: 2008-11-15
Points: 0

John - Thanks for your reply.

I had sort of given up on JXTA - reading through some of the forum posts I got the impression the project was sort of... 'dormant'. Is it?

For applications that need to communicate between average consumer internet connections, JXTA may not be currently ideal for me. While there is a requirement to have a relay(s) beyond the NAT/firewall in the internet domain for all NATed peers, I'm not sure that JXTA is best addressing the consumer P2P problem. The relay seems to be replacing the server in a client/server setup, in so far as scalability is concerned. If the majority of peers are individual users at home behind NAT modem/routers, having a relay sounds not much different from a traditional client/server setup as far scalability is concerned.

Consumer P2P applications seem to have a big future, IMO. Spotify are interesting in that they have leveraged all sorts of industries and technologies and helped bring P2P out of its unwarranted 'murk'. Not least, they (and others) have a hybrid consumer P2P/client/server network that does not need any manual router config. The avoidance of manual router config (port forwarding) is totally crucial! It seems that the solutions to a restrictive ip4 address space (NAT) have severely limited the internet's potential in this respect!

If JXTA could alleviate the client/server scalability issue for P2P apps over the internet, that would be something good. One step to this happening could be having JXTA recognise and use UPnP IGD devices. Suddenly, all those peers behind UPnP IGD NATs become visible over the internet. And the potential number of peers behind UPnP IGD NATs I would estimate to be rather large.

Since I posted my original question and out of frustration, I have been playing around implementing my own P2P network which connects peers that are behind UPnP IGD NAT devices to peers who may or may not be behind NAT/firewalls/etc using combinations of connection reversal/hole punching/port 80 etc. It's all proof of concept stuff, but my tests do seem to work. And even if all UPnP IGN NAT devices are not what they could be and don't all work how they 'should', I reckon I can still get a very large number of directly connected peers in this way. This will reduce the dependence on and scalability issues of an external relay/server to make doing it worthwhile.

So I await eagerly for JXTA to support UPnP IGD. Is there a roadmap somewhere which will tells me when it's scheduled to start/release?

boylejohnr
Offline
Joined: 2008-10-27
Points: 0

Dormant? version 2.6 is in progress. As for a road map, there is a list of immediate changes in the change database. However, 2.6 is mainly performance, reliably and a beginning of a move to OSGi.

I agree the IGD is potentially a bigger hit for consumer market and also something we would be keen to engage in. At present there have been immediate improvements to the HTTP tunneling as from my perspective the mall business/corporates will not allow IGD. Throught this process we have determined how to implement new transports in JXTA and IGD would potentially be trivial.

JXTA in present form does improve client/server nature, since relays are dumb, therefore can have lots of them to improve scalability. If you have classic client/server where you have session state then JXTA would be an improvement.

JXTA is more than the transports it is an defined interface for lookup, security, communication and service provision. I guess on of the key things even with IGD is that you will likely require Lookup.

JXTA is no silver bullet but it is a defined interface for a P2P system and can plug in other transports.

As for UPnP and a time frame, I do not know but if you have the experience to implement we can assist to plug in under JXTA. Personally I think we may look at STUN/TURN implementations (ala Skype) in the near term first.