my background is from Trey Ratcliff at http://www.stuckincustoms.com
Dumb Pipes Enable Optimization & Resilience for an Unpredictable Future
Last night I sent out an off the cuff ideal:
My one wish, to be capable of providing dumb unlimited pipes to everyone, and everything. Free the net, free the future.
Working Definition: Dumb pipes are communication channels which don't restrict the type of information which flows through them. Any form of restricted network can be implemented over dumb pipes.
Metaprotocols are Dynamic Protocols
The protocol the network is founded on is a restriction on the open nature of dumb pipes. In order to overcome this limitation, a network architecture may be mutable. This is achievable in a network woven together by dumb pipes. The caveat being both transmitter and receiver must be able to agree on a message description language, and handshake method. This form of self describing message is what I refer to as a metaprotocol. It's similar to metaprogramming, but instead of a self modifying language, a metaprotocol is an adaptive communication channel.
This would alleviate the necessity of predefined protocols, at the cost of protocol transfer/translation time. Some great protocols which provide wide flexibility are TCP/IP, HTTP, RSS, & the open Twitter API? A metaprotocol could emulate any of these formats by transmitting a protocol description in the header with a type and release ID. Local caching would eliminate the need to continually transmit/translate a protocol. Alternative (or additional) implementations could query a server for an unknown protocol from a provider (kinda like DNS for URL translation).
It's imperative we collectively understand why the nature of the Net, and our future as a connected global species depends on dumb pipes: maximum future flexibility.
I'll wrap up by calling attention to some of the primary features of dumb pipes. Network fans/pros are more than welcome to contribute to this list, leave a comment. As an eternal sophmore I make sure to minimize how much I "know" at any given moment ;).
- Channel Noise
- bandwidth
- latency
These basic features drive other descriptive channel parameters like:
- throughput: amount of information that can be transmitted and received is a combination of bandwidth & channel noise
- response delay: back and forth throughput + latency to respond
Note: I didn't mention message failure rate because it's captured by the channel noise parameter. For HTTP, message failure can cause a delay of a few seconds when an initial request fails to make a connection
Related articles by Zemanta
- Hooking the lizard brain up to the cerebral cortex (scripting.com)
- Trading one centralized net for another? (scripting.com)
- Twitter And Y Combinator Team Up For Startup Stream Access (techcrunch.com)