h a l f b a k e r yCeci n'est pas une idée.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
|
Good idea, but who decides what data flows through this data stream, and exactly who gets access to it? |
|
|
Peer participants would get access. I have performed small tests using 1k/sec streams. A symmetric peer2peer connection consumes 2k/sec bandwidth. The upshot is that peers have to choose to be hubs by establishing > 2 peer connections. |
|
|
Routing, of course, is the tough part. I have worked through a "route subscription" mechanism whereby people with something to send request a route allocation from their peer(s). Nothing can be sent without a subscribed route. True message data, not cumulative cryptographic stream data, would queue up at peer locations if they were congested. |
|
|
One of the keys to the stability of the system is that there would be no concept of bandwidth disparity becuase the channel bandwidth is explicitly limited. Streams that are statistically too fast or too slow get dropped. Pacing is part of the ConstantCrypto communications layer. The assertion is that if peers have N symmetric peer connections that are all bandwith choked then bytes in always equals bytes out. |
|
|
Needs a bit of chaffing to prevent analysis of groups that join at the same time. |
|
|
Why not high bandwidth? They are already rolling out 100mb/s consumer broadband connections in my area. |
|
|
Not everyone has a high bandwidth connection yet, last I heard a good percentage of US citizens are still stuck with dial-up modems. |
|
| |