Skip to main content

why need to connect to http://rdv.jxtahosts.net/cgi-bin/rendezvous.cgi?2

4 replies [Last post]
tcytree
Offline
Joined: 2004-03-04

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bondolo
Offline
Joined: 2003-06-11

> I just have to point out the elephant in this room-
> if I were inclined to program a system which
> depended, for its proper functioning, on a dedicated
> machine whose utility was it's a well-known, publicly
> available, always-on resource, I'd use the DNS
> system- i.e. regular internet protocols.

Using DNS to round-robin or for load balancing is indeed the recommended approach for seeding Relay and Rendezvous servers in production JXTA networks. The "http://rdv.jxtahosts.net/cgi-bin/rendezvous.cgi?3" is used by the JXTA public network for historical reasons that don't impose any restrictions on the approaches which can be used by JXTA deployers. As has already been mentioned, the JXTA public network exists primarily for development and testing purposes. It's not something actual JXTA deployments should use for production applications. The network has neither the capacity nor appropriate support for doing "real" work. Because the JXTA public network frequently runs test versions it is probably only "2 Nines" reliable (see Myth of the Nines) whereas we would expect a production JXTA relay rendezvous server to be better than 4 Nines.

> But this guy's question goes to the heart of a larger
> issue, which is, it's not clear - and this may be
> from a near total lack of documentation on JXTA from
> Sun - how JXTA is fundamentally different from other
> "need-a-well-known-resource-to-work" solutions to p2p
> programming, i.e. napster (R.I.P.) et.al. Despite
> nice high level overviews that combine hype with a
> *certain* level of technical documentation, like the
> ones in this series:

JXTA deployments do not necessarily require a well known resource to work though having such a resource is a great convenience and improves network stability and connect speed.

> http://www.ibm.com/developerworks/java/library/j-p2pin
> t1.html
>
> the elephant remains in the room.
>
> I cannot fathom the lack of documentation except that
> it's motivated by one of two things. Either the part
> of Sun that does a fine job with its tutorial-series
> of books (such as those edited by Lisa Friendly )
> does not know about the JXTA project or there is some
> sort of intra-company feud or something of that sort
> or, alternatively, JXTA is, in reality, a not ready
> for prime time, thrown over the wall technology from
> Sun. If the later is the case then obviously Sun does
> not want TOO widespread adoption of JXTA because the
> core is likely to shift at any moment, infuriating
> adopters who are likely to get mouthy about the
> affair and ruin the whole franchise in the process.

Like every other project JXTA has limited resources. The project was initiated by Sun and Sun continues to remain very involved in and supportive of JXTA. Within the last 6 months we've seen a JXTA-C release, a major JXSE release, a major update of the JXTA Programmers Guide and also the significant move to join the java.net community. 2008 promises to see new contributions and major JXTA announcements from Sun. Sun is very actively using JXTA within it's own offerings (see https://shoal.dev.java.net/ for one example.) and JXTA should be more visible in Sun offerings in 2008.

What absolutely essential documentation do you find missing? Keep in mind that as you have probably seen by these forums the JXTA community is very resourceful, collaborative and creative in getting the information needed to make best use of JXTA. JXTA is a complicated enough technology that for many questions there is no one single correct answer, instead the solution space is a balance of tradeoffs. Additionally because web technology and JXTA continue to change and improve in various ways the best answer last week may not be the best answer today. The JXTA deployer/developer's best resource is always going to be the other JXTA deployers and developers who make up the JXTA community. In this way the JXTA community is much like the Apache HTTPD community.

> I know this sounds harsh, but it's meant as a jibe
> and a spur. JXTA promises much, offers a little, and
> explains even less. Not that many job-loving CIOs or
> CTOs are going to recommend its adoption. There are
> elephants in rooms that credible, clear and
> accessible documentation could herd up in a jiffy,
> but no such documentation is forthcoming, supposedly
> for lack of resources. Independent authors and
> publishers of the sort that were around in 2001-2002,
> ready to act as knowledge brokers between eager
> programmers and JXTA seem to have dried up and blown
> away. None of this augers well and none of it is very
> confidence inspiring.

With all of the clamouring and apparent interest in a "new and up-to-date" JXTA book I am very surprised that an independent author and/or publisher hasn't taken up the challenge and written one.

An article I read just today at Coding Horror seems to have summed up my feelings about some of the JXTA early adopters. They were attracted by JXTA when it was new and cool but have long since moved on by the time JXTA has become useful and interesting. There has never been a better time than now to get involved with JXTA.

propaangas
Offline
Joined: 2007-06-18

jxtahosts.net provides a public rendezvous network, mostly for testing purposes. Afaik it was never intended to run production on. If you are concerned about the stability, you should start running your own rendezvous and relay nodes where your application's edge nodes connect to.

swv
Offline
Joined: 2007-05-28

I just have to point out the elephant in this room- if I were inclined to program a system which depended, for its proper functioning, on a dedicated machine whose utility was it's a well-known, publicly available, always-on resource, I'd use the DNS system- i.e. regular internet protocols.

But this guy's question goes to the heart of a larger issue, which is, it's not clear - and this may be from a near total lack of documentation on JXTA from Sun - how JXTA is fundamentally different from other "need-a-well-known-resource-to-work" solutions to p2p programming, i.e. napster (R.I.P.) et.al. Despite nice high level overviews that combine hype with a *certain* level of technical documentation, like the ones in this series:

http://www.ibm.com/developerworks/java/library/j-p2pint1.html

the elephant remains in the room.

I cannot fathom the lack of documentation except that it's motivated by one of two things. Either the part of Sun that does a fine job with its tutorial-series of books (such as those edited by Lisa Friendly ) does not know about the JXTA project or there is some sort of intra-company feud or something of that sort or, alternatively, JXTA is, in reality, a not ready for prime time, thrown over the wall technology from Sun. If the later is the case then obviously Sun does not want TOO widespread adoption of JXTA because the core is likely to shift at any moment, infuriating adopters who are likely to get mouthy about the affair and ruin the whole franchise in the process.

I know this sounds harsh, but it's meant as a jibe and a spur. JXTA promises much, offers a little, and explains even less. Not that many job-loving CIOs or CTOs are going to recommend its adoption. There are elephants in rooms that credible, clear and accessible documentation could herd up in a jiffy, but no such documentation is forthcoming, supposedly for lack of resources. Independent authors and publishers of the sort that were around in 2001-2002, ready to act as knowledge brokers between eager programmers and JXTA seem to have dried up and blown away. None of this augers well and none of it is very confidence inspiring.

lmikhailov
Offline
Joined: 2007-05-22

I agree with most of what you say in your post. Jxta tutorials have some up to date info and samples. The biggest problem with Jxta tutorials is that most of the samples show how JXTA works with ADHOC peers (i.e. on a local network) and imply that the samples will work without change with EDGE/RENDEZVOUS peers. From my experience it is not the case most of the time.

You can get some relevant info from the books you mentioned (published around 2001-2002). Most of the content in these books is still relevant, in particular general architectural issues like the one you are discussing.

Regards,

Leon