David Barrett wrote:
Does JXTA do any sort of "simultaneous connect" NAT traversal (ala STUN/ICE)
or does it only use relay server (ala TURN)?
I would say there are solutions at two different levels in JXTA.
JXTA relay service can make use of different transports, current
implementation supports both HTTP and TCP.
At transport level, if you are using TCP transport, you can implement
STUN or TURN.
They can exist simultaneously, and if you like, use multiple of them.
Cheers,
Henry
-david
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:p2p-hackers-
[EMAIL PROTECTED] On Behalf Of Henry Jen
Sent: Sunday, February 04, 2007 11:23 PM
To: theory and practice of decentralized computer networks
Subject: Re: [p2p-hackers] JXTA-C evolution
Günther Starnberger wrote:
On 12/20/06, Henry Jen <[EMAIL PROTECTED]> wrote:
Hello,
Don't know how libjingle+XMPP works. If you know some good reference I
can look at, I will try to compare.
Jingle does allow for different transport implementations, but the
current implementation by Google uses ICE as transport (see
http://www.xmpp.org/extensions/xep-0176.html and
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-12.txt).
Finally spent some time to finish reading the ICE draft, basically JXTA
provides a similar mechanism.
A peer is responsible to collect its own endpoint addresses with all
different transports it utilizes and publish those in its peer
advertisement. Endpoint service will use those information to pick up an
address can reach the peer. Noted that JXTA is not assuming the
transport would be IP-based.
With current implementation, TCP transport supports the host candidates,
Relay service provides NAT traversal capability by relaying JXTA
messages.
It is desired to implement STUN support for IP-based transport to add
Server Reflexive Candidate. Since JXTA has its own relay service,
Relayed Candidate is purely optional.
As the Jingle to be used as a signal channel, as it is XMPP where an
agent needs to connect to a particular server(understand it could be a
cluster), where JXTA uses the discovery service to locate peer, which
can be using multicast and/or using on rendezvous service.
JXTA use relays for NAT traversal, that said, it is totally possible to
implement STUN with UDP transport. It's a matter of resources to pick
up
that task.
Does it use one or several fixed relays or can it dynamically use
other JXTA peers which aren't behind a NAT (similiar to Skype)?
It can dynamically use other peers as Relay if those peers are willing
to be a relay server.
This is really depends on the policy implemented in the peer group. JXTA
defines a set of protocol allow peers to self-organized into peer
groups, with some attention, it is totally possible to start a isolated
JXTA network. That gives application developers total control on their
network.
Cheers,
Henry
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers