Bob La Quey wrote:
On 8/21/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote:
I stand by my NAT hole punching test. If you can't use the framework to
do that, it doesn't have enough flexibility.
Other than a narrow band interpretation of the term URI I cannot
see why you are being so dogmatic, Again it appears you miss or
do not understand the main point.
The point is this:
Where does the abstraction leak? JXTA meet NetKernel.
Any system that says: "All resources are the same. You access them from
a unified space." has an abstraction problem. Period.
What happens when getting resource A takes 100 times longer than getting
resource B? (Their answer seems to be caching) What happens when you
only ever access a resource once? (latency problem) What happens when
you cache a resource and it changes out from under you? (coherency) How
do lower level failures ask the upper application layers for advice on
recovery?
UDP hole punching is just my way of putting a concrete problem down to
highlight the issues.
UDP hole punching has all of the features necessary to test what's going
on. Resources behind firewalls are harder to get to than local or
non-firewalled resources. Connections can suddenly block and need to be
renegotiated, or, worse, the connection can get dropped *and* the
resource then changes.
A low-level failure (dropped connection) may have multiple recovery
strategies: ignore (non-critical or latency critical), error correct
(let the high level application ride through the problem with coding,
etc.), retry (force the low-level to reconnect and retransmit),
alternative (find another resource at the application level or transport
level), die (no viable recovery).
All resources are not the same and do not have the same characteristics.
Low-level sometimes *does* matter--generally when performance is on
the line.
When performance doesn't matter, almost anything will work. I, however,
want something that will work even at the high performance end, or, at
least, give me the hooks to do what I need when performance matters.
The trick is to not have to invest too much extra when things are simple
and yet still have the ability to handle the complex.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
