On Sun, Apr 02, 2000 at 01:26:37PM -0700, Doug Royer wrote:
> The largest problem with WAP is that they are now concerned that
> they have made a big mistake - they want the internet protocols
> so that they can interoperate with the internet. So they are
> backtracking and going with IP protocols.
Funny how the technically best solution often loses to convenience...
kindof like computer power supplies... I've always thought it'd be nice if
they all came with aux. DC power inputs, so that a UPS could just simply be a
battery. But instead we need these complicated inverter things to convert
to 120V AC because that's all the power supply can accommodate. Laptop
designers are forced to do better than that. Or, like LCD monitors...
they're inherently digitally addressable (dots are discrete elements)
but because VGA is the standard, the digital data has to undergo a
D/A/D conversion before the dots in VRAM can be translated to brightness
of the LCD dot. It adds a lot of cost to both the video board and the
monitor... and while digital alternatives are proposed the manufacturers
can't agree on one.
Anyway... yes it does seem like many Internet protocols are not optimized
for packet operation. SMTP is a really good example; the sender expects
to carry on a verbose, real-time conversation directly with the recipient,
regardless how many hops are between, where a store-and-forward scheme
makes more sense on just about any network, not just the most unreliable
ones. And this is important to me for my efforts at getting an email
gateway going. Local BBS operators need a gateway to which they can forward
outgoing email. The best solution proposed so far is to use the convention
[EMAIL PROTECTED]; and it turns out my sendmail is capable
of decoding that, and forwarding the mail to [EMAIL PROTECTED] I was glad
to find it wasn't going to be any extra trouble. But the route has to be
explicitly defined, how primitive. It'd be nice if it could determine the
route from the MX records, one hop or hop-sequence at a time. Maybe this
is possible, I'm not sure.
I've also grown fond of another idea I read about a couple weeks ago... a
decentralized alternative to the web. Each node has a stack of name/value
pairs, where the value is the "web page" so to speak (but could be any kind
of data object). The "name" is just a plain old string, no URL-style
hierachical conventions. If a request comes in to any node for some
object by name, and that node does not have the item, then it uses a
mathematical function to determine the best guess as to which other node
might have that item. Then it forwards the request. This continues until
the item is found. The item itself is sent back along the path which was
used to find it, and the node which got the request in the first place
then keeps a copy, in case somebody else asks for this item. Since only
finite storage is available at each node, the least recently used items
are discarded. So the end result is that data doesn't belong to any node,
it travels to where it's needed, is cached redundantly, and is resistant
to most censorship efforts. And the names can be easy to remember (but
I imagine namespace clutter would become a problem pretty fast). I think
a system like this would be great on packet. Maybe instead of a simple
string, the name should be a piece of XML metadata which can contain various
attributes of the item. Hierarchical naming of either servers or data
is way too simplistic.
Info about it is here: http://freenet.sourceforge.net/
Either way we're talking about one-hop-at-a-time routing, rather than
attempting to create real-time 2-way channels across arbitrary distances.
The mail system is a "push" model, where both endpoints are known in advance
but we're not sure which intermediate nodes are going to be available to
help with delivery; but freenet is the "pull" model, where we know what
we want but not where to get it from or how to get there. I think those
two basic methodologies could replace just about all the high-level
internet protocols, on unreliable networks.
--
_______ http://www.bigfoot.com/~ecloud
(_ | |_) [EMAIL PROTECTED] finger [EMAIL PROTECTED]
__) | | \__________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903
