Subject: [P2Prg] JXTA x Plataform Independence

From: "Alexandre" <[email-masked]>
Date: Mon, 10 May 2004 00:15:45 -0300

One of the objectives mentioned in SUN's website is the complete platform
independence . In this article
http://www.jxta.org/project/www/docs/JXTAnetworkProgEnv.pdf,
the writer says that many p2p systems, except for the JXTA, offer a certain
degree for independence that, however, isn't complete. Citing:

"many p2p systems today offer their features or services through a set of
APIs that are delivered on a particular operating system usin a specific
net-working protocol. For example, one system might offer a set of C++ APIs,
with que system initially running only on Windows, over TCP/IP, while
another system offers a combination with C and Java APIs, running on a
variety of Unix systems, over TCP;IP but also requiring HTTP. A P2P
developer is then forced to choose wrich set of APIs to program to, and
consequently, which set of P2P customers to target.
Because there is little hope that the two systems will interoperate, if the
developer wants to offer the same service to both communities, they have to
develop the same service twice for two p2p platforms or develop a bridge
system between them. Both approaches are inefficient and impactical
considering the dozens of p2p platforms in existence. JXTA technology is
designed to be embraced by all developers, independent of preferred
programming languages, development environments, or deployments platforms."

In another article
 http://www-106.ibm.com/developerworks/java/library/j-p2pint1.html ) the
writer cite that JXTA is independent to the JAVA.

Many articles I've read quote about this complete platform
independency, but doesn't make clear what are the resources in
which jxta certifies that.

I'd like you to clarify this question and also indicate more specific
articles on the JXTA platform independence, with insider aspects.

thanks.

_______________________________________________
P2prg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2prg

---

From: Bernard Traversat <[email-masked]>
Date: Mon, 10 May 2004 08:44:10 -0700

>which jxta certifies that.
Alexandre,

JXTA is defined as a wire protocol, like TCP/IP. The
JXTA protocols can be implemented in many languages (C,
Java, .net, Python, etc..).

B.

-- 
"As Java implies platform independence, and XML implies language
independence, JXTA implies network independence."

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 09:38:04 -0700

Hi Bernard,

We can also note that Jxta abstracts the transport layer into an 
overlay network that is independent of the underlying real transports 
and link layers, and as a consequence Jxta peers can communicate with 
one another in a way that depends solely on the Jxta protocols and 
messages on the overlay network. Consequently, Jxta implementations on 
different transports and physical links are interoperable. In some 
cases Jxta rendezvous are required when the underlying transports 
differ: Imagine Bluetooth to TCP/IP on ethernet for example.

Another important consequence of the Jxta protocols is that application 
writers need not concern themselves with the underlying barriers on the 
physical medium like NAT and firewalls. These are transparent to the 
applications.

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Mon, 10 May 2004 13:36:14 -0400 (EDT)

So how does JXTA avoid the tcp-over-tcp problem?  When using a rendezvous,
are packets numbered and retransmitted?

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 11:13:58 -0700

Jxta has a reliable message protocol for its "messages." This is 
end-to-end. I wrote it.

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Mon, 10 May 2004 14:31:53 -0400 (EDT)

Does end-to-end mean that TCP isn't used?

Thanks.

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 11:53:39 -0700

It may or may not be used. A reliable real transport is required to 
assure that each jxta message arrives to the next hop reliably. The 
jxta msg reliable transport then guarantees reliable end-to-end 
delivery of the msg given any number of jxta relay hops (relays are the 
jxta equivalent of routers and are usually but not necessarily bundled 
with a rendezvous).

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Mon, 10 May 2004 15:01:31 -0400 (EDT)

Ok, so when TCP is used, does the jxta msg reliable transport do numbering
and retransmission?

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 12:38:16 -0700

Yes, of the messages. That's why it is reliable. It guarantees the 
delivery of each message in the correct sequence, retransmits to fill 
holes using selective acknowledgment, etc.

TCP assures a message gets from relay to relay but cannot guarantee 
message order or prevent drops. Note also that TLS can be used above 
the reliable transport thus breaking messages into 16k byte TLS records 
that are then sent as reliable jxta messages end-to-end.

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Mon, 10 May 2004 15:46:52 -0400 (EDT)

Ok, so then is a relevant issue --
"Why TCP Over TCP Is A Bad Idea"
http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
...
Note that the upper and the lower layer TCP have different timers. When
an upper layer connection starts fast, its timers are fast too. Now it can
happen that the lower connection has slower timers, perhaps as a leftover
from a period with a slow or unreliable base connection.

Imagine what happens when, in this situation, the base connection starts
losing packets. The lower layer TCP queues up a retransmission and
increases its timeouts. Since the connection is blocked for this amount of
time, the upper layer (i.e. payload) TCP won't get a timely ACK, and will
also queue a retransmission. Because the timeout is still less than the
lower layer timeout, the upper layer will queue up more retransmissions
faster than the lower layer can process them. This makes the upper layer
connection stall very quickly and every retransmission just adds to the
problem - an internal meltdown effect. "
...

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 12:59:20 -0700

This is well understood and compensated for in the Jxta reliable 
transport. Look at the code if you are curious. We are not naive when 
it comes to the IP stack and TCP behaviors.

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Mon, 10 May 2004 16:08:39 -0400 (EDT)

Fair enough.

-L

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 14:19:39 -0700

The important thing to keep in mind is that the Jxta reliable transport 
is not exactly TCP on TCP. It behaves like TCP but on large chunks of 
data which are the messages themselves. It's timers are tightly bound 
to the TCP timers across the hops in the sense that it can only do as 
well as the *poorest* behaving TCP connection in the end-to-end sending 
of a jxta message. It was a little *painful* to get it to work well in 
all of the various cases. Up to one's ears in TCP traces (-:

Bill

---

From: Lucas Gonze <[email-masked]>
Date: Mon, 10 May 2004 18:10:45 -0400 (EDT)

So it's actually aware of the TCP timers?  Wow.

---

From: Adam Back <[email-masked]>
Date: Mon, 10 May 2004 18:39:21 -0400

Hi

I think I must be misunderstanding something about the scenario:

If you are using TCP between hops how would you get out of sequence
messages or gaps?

Wouldn't it be more like a router?  If the connection fails the
application loses it's connection?  (Or suppose more accurately a TCP
relay).

Or is this because you are presuming one or more of the hops may be
unreliable?

I presume also that the default 99% case is that there are two hops
(both sides NATted, one relay), and that TCP is used as the transport
certainly for any internet app.

Is there much latency and bandwidth overhead to adding this end-to-end
TCP-like semantics in cases where it is not needed?

Thanks

Adam

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 16:17:28 -0700

The awareness is implicit rather than explicit. It is aware of TCP 
behavior - Slow start - congestion window, window etc - and gears its 
window and retransmission schemes accordingly and self- adjusts. I've 
tested this across a firewall to an external jxta relay and back: two 
jxta peers on the same subnet discovering one another by the means of 
an external rendez-vous, and then using the external relay to 
communicate. I wasn't particularly pleased with the throughput (it was 
jxta 1.0 and jxta is now at least at release 2.1) but it adapted well - 
and as expected.

OK. Need to do other things. By the way, I left Sun in January of this 
year and am no longer associated explicitly with jxta. I tried very 
hard to retire but was recruited by friends and now consult for the BBC 
Vect group in London. A lot more fun than Sun !

Bill

---

From: Bill Yeager <[email-masked]>
Date: Mon, 10 May 2004 16:36:03 -0700

You missed something I guess:

peer <-- Jxta RMP/TCP/IP --> [relay] <--- Jxta RMP/TCP/IP --> ... <--- 
Peer.

The problem is with the relays here. They may drop messages or reorder 
them.

peer <-- Jxta RMP/TCP/IP --> peer

One can experience dropped messages here because of the Jxta core 
protocol queues filling up and (incorrectly perhaps) not using TCP/IP 
backpressure to permit things to slow down. Rather, if a queue is 
filled, and another message arrives, it drops it on the floor. Really, 
Jxta should not read another message from TCP/IP until there is room in 
the queue. It could do this. It does not.

Bill

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 10 May 2004 19:50:17 -0400

JXTA does not require that all messages between two peers be transmitted
along the same route of endpoints.  Nor is it required that TCP be used 
as the transport between
each endpoint.  In fact, the endpoints themselves are not required to 
transmit all messages
in a reliable manner.  If one of the endpoints along the route is 
transient or very small
it is possible that it might drop messages as needed.  They will be 
retransmitted by the
source peer based upon a sliding window protocol.

Your assumption that TCP is the most frequently used protocol is true on 
the
Internet but would not necessarily be true on other types of networks. 

There is of course overhead which might be considered to be unnecessary 
on the
public internet.  However, even in the case where TCP is used 
throughout, there
are network configurations in which messages which are propagated across the
boundaries of secure private networks must be pulled out of one cloud 
and then
inserted into another.  It is these cases where the JXTA model truly shines.

Jeffrey Altman
Secure Endpoints Inc