Uh, duh, the idea of Open Software may be fairly new, but it's certainly not *untested* (I test it every day by running Linux - works fine for me. If it doesn't for you, don't use it. Geesh, nobody said you had to. Now if only nobody said we *had* to use Microsoft [yes, I'm referring to job environments here]).
Most political theorists have simply rationalized their contemporary system - Burke, Hobbes, Aristotle, Plato, etc. They made good points sometimes in so doing, but still, they rationalized a lack of change. Rousseau, somebody on the other side, proscribed a new system which has never, as far as I am aware, been implemented except in microcosm. Marx, whom you were probably referring to, looked at the system around him, got a lot wrong, but got a lot of key things right - welcome to the humanities department. Marx has even been quoted as saying "I am not a Marxist" by which he meant that he did not wish to be associated with people who misinterpereted his ideas. He didn't intend the USSR, nor China, nor Cuba, you get the idea, to become communist - he intended Germany, an already industrialized, wealthy nation to become the first communist country - or a nation much like it. So of COURSE his theory failed, because it was not given the correct prerequisites. It's actually an impressive dillema of communism - the working classes in those countries that *could* go communist didn't and don't wish to. So it's untested and has remained so, despite the claims of "communistic" states, one never existed. Perhaps one never can, but don't knock that which has never been truly put into practice for a test run.
And about the treaty.... It makes next to no social sense for the megacorps to be forcing their views on the world. And economical..... only if you believe in trickledown economics. Which *has* been implemented - by the past nine Republican presidents.... and has been linked with nine downturns in the economy, each within six months of the president's assent to office.
So sorry to waste page space, but I feel better now. Thanks.
The pessimist in me wants to say "bend over and kiss your ass goodbye" - the next step to a corporation-controlled digital age.
Maybe (maybe) it will get better before it gets really bad, but reality's shaping up a lot like this. Can anybody point a link to a list of all the countries that have so far bought into this?
If you're trying to minimize Hamming distance, wouldn't it be better to establish the first connection without an ID then ask the peer for its ID and the IDs around it? Then we pick a non-occupied one and use it.
Then we can just start making connections, getting their IDs, and dropping the furthest out, yes?
I like the idea of "introduction" via peers - watch addresses that come by, if one is a certain Hamming distance or shorter away from one of our connections, tell that connection. 's that basically how it works?
Finding Hamming distance sounds like a parity-class problem (XOR and sum, right?) so it shouldn't be bad at all. Though is there an easier way for the sum part of it than "if the last bit is one, increment counter, rotate right, repeat"? This might not be a problem, and that's an O(n) loop (right?) - not bad, but is there an O(1) solution? Maybe we'll just want to check addresses at random rather than every one - save cycles for more useful things. Also, saturated hosts will probably not even bother with comparisons - if all n of our local peers are right, then why bother?
If we use the introduction method, won't the "core" of the network [those hosts that stay on for a long long time] eventually fall into place as a proper hypercube?
How do we handle address space conflicts? If, say, the network were to partition itself in two, somehow (links just happened to be dropped in the right way), and then a host comes up that bridges the two segments, what do we do? Worse, what happens if two perfect hypercubes overlap [all n connections in each are only one bitflip away, and all have the same numbers]?
What about self-updating viruses? Take Code-Red, add already-infected detection so Target knows when Infector is scanning it, then Infector checks its local database of attacks and asks Target if it 1) has additional, 2) would like one of the ones it doesn't have that Infector does and 3) for success-statistics on every known method (just two counters, success / total attempts). If the success / total ratio goes too low, the virus could shed that attack, assuming that it has become patched everywhere. Shedding might be done in a non-probabilistic manner so that not all the viruses shed an attack (there will be *somebody*).
Additionally, using non-random address generators could help (OH, look, I'm on 192.168.0.10/24... let's attack all the 192.168.0.* hosts first) and get some interesting virus (beowulf? Sorry...) clusters up.
Innovation would be slower, because companies could not expect to receive as much profit from the VERY EXPENSIVE RESEARCH that goes into these designs. Without some protection, the profit motive is gone. Without profit, the research doesn't get done.
Without patents, we'd still be using abacuses
Excuse me, no. Research is VERY VERY EXPENSIVE, yes, but SO IS CONSTRUCTING THE FAB PLANTS for *anything*. A high barrier to entrance means that it will *always* be easier for Intel to upgrade their cleanroom facilities than somebody to come along and build new ones (think replacing a filter vs. building an entire building). And in terms of software... until MS, nobody really thought of commodifying the OS - maybe that's a better world we didn't enter. I think it certainly has potential. Extrapolate upwards from the OS. Software's just data... do we have a right to encapsulate data and sell it at excessive prices (more than media cost)?
I think you misunderstand - my bad. The first error message should probably be "Transfered N files from client X with resulting MD5 hashes that did not match advertized MD5 hash - mistrusting this client." A client would advertize an MD5 hash of the file as they had it stored. ID3 tags would carry into the hash you advertized and the file I recieved, unless you were cheating or the network was bad or my box was borked.
-Knots
Re:When the ISPs all start blocking P2P....
on
Cringely's Bank Shot
·
· Score: 1
Massively heirarchical routing schemes sound cool, but how are we going to enforce these in a truly anarchistic system? We can't trust The Technology, because I for one (and I'd imagine others) want perfect control over their equipment.
Yes, WAPs can do DHCP. That's cool for the internal network (I do something similar at my house but instead of a WAP it's my old router computer) - I hand out 192.168.*.* addresses to my internal LAN and do bridging out to my publicly assigned IP address. Now there's the problem. In a truly peer-to-peer system, how does anybody's router get a valid external IP address? GARP is one way, but that would be *a lot* of returns. Maybe pick random IPv6, ARP it, repeat until one's found that's clear... so we have an address, cool.
Ok, so we have an address. If we are to have this system use anything like the internet routing protocols, such randomly distributed IPs are going to be slightly painful, I'd think... either everybody ends up broadcasting EVERYBODY's packets (ala Gnutella where it's just TTL that prevents infinite loops) or we do some kind of multi-WAP routing. If the latter, our routing tables grow enormous unless we have good heirarhical control over the network. But without "ultrapeers" or somesuch (servers), we don't.
For an average setup I'd imagine there'd only be one WAP. Ok, this setup runs GNUTELLA style and rebroadcasts everything, docking TTL by one. Somebody down the street picks it up.
Eventually we either get to a MASQed internet connection and the packets are pulled off the wireless network (while still maybe propagating across other links and maybe being resent there... doesn't make websites happy when they see what looks like a DDoS) and routed or we end up being sent over some kind soul's tight-beam 802.11 connection (or other) [this person is running a multi-WAP setup and has the huge routing tables] to another part of the OpenNetwork and the routing mayhem begins again.
Imagine a very simple network composed of a small city in which three people have outside links - one a cable modem, one a DSL line, and one a 802.11 tight-beam relay to an adjacent city. Now, one random house in this city sends out a packet. Their neighbors ALL pick it up and retransmit it. Eventually it finds its way to ALL the ways off the local WLAN (DSL, CM, TB) and follows ALL those routes AT ONCE. So all packets get cloned 3 times then passed on to the general internet and... multiply by a huge number of users.. it's a DDoS without intending one.
Maybe some kind of RIP protocol would be needed combined with some form of localized onionrouting? So if I maintain a router to another city / the internet / wherever, I publish such information via RIP to everybody in the local community over the WLAN (broadcast to our internal MAC addresses, harvested via ARP caching?). As the broadcast propagates, additional payload is added to the packet - effectively a traceroute. So then the clients, if they wish to use my uplink, sourceroute their packets via the reverse of the shortest chain - so packets do not get cloned because other recieving WAPs drop them. I think that works...
Sounds like a great project to get thinking on / researching.
Thanks for the responses, Mr. Neutron!
-Knots
Re:When the ISPs all start blocking P2P....
on
Cringely's Bank Shot
·
· Score: 2, Insightful
Alright, wireless anarchy is very very cool to talk about, but raises some serious problems.
1) Routing tables could potentially grow HUGE to handle loops within the system.
2) I think (am I wrong?) that a system would require point-to-multipoint or at least WAP-to-WAP, which IIRC 802.11b was bad at.
2.1) Either that or we need two or more 802.11b repeaters on anybody's internal network. Not necessarily a bad thing, but it's more complicated, since one (or more) would have to be able to touch somebody else's WAP. Is there some combination of AdHoc and AP modes that the 802.11 system can operate in?
3) How do you assign an IP address? No DHCP servers, can't be static... messy, no?
4) Suddenly route-advertising and route-discovery would have to become standard features on all WAPs.
That said... it sounds really cool and I'm thinking of solar-powered UPS-backed PC/104 with PCMCIA 802.11 cards being put up around a community ("For $small we can all share internet access and be online anywhere in {area}"). Maybe just a dream.
Any attempt at cheat-proofing karma requires a central system which is by definition not a peer.
So while it's a nice try, you'd have to trust people to keep their karmas right. And the minute you put in a system for that, you may as well just rely on a pubkey web of trust. That could work, but only if the web becomes dense enough (and even then you either need keyservers or have to carry around huge chunks of the trust-web's data in your device).
So that defeats the peer-to-peer nature of the network. Seems to me that we'll need semi-smart clients - "Transfered two files from client X with incorrect MD5 hashes - assuming bad netlink or untrusted peer", "Data transfered is not advertized size", etc. Maybe a given peer could keep a short term "karma-cache" of a couple hosts (user configurable number). Then at a LAN party, say, a misbehaving client could get automagically shut-out of the network while clients that behaved correctly gradually increased their trust. Add in a little button "Trust +1" or "Trust -1" in the client and we're good to go.
Maybe I'm just talking out of my ass but it sounded cool to me!
So you set up some search queries with priorities ahead of time and the system regularly sends out broadcast pings and/or listens for others to send out pings.
Either way, once the devices have each other's MAC addresses, they can handshake and then:
1) request other device's file list
let's say name, size, and MD5 hash at minimum.
2) search against pre-set search criteria.
3) request download of highest (if multiple) priority match - if tie or no priorities, then just pick a random one. Or maybe shortest if link quality is bad.
4) Repeat 3 as long as device is in range.
5) Optionally delete any incompletely transfered / incorrectly transfered (differing MD5 hash) files.
Sounds really cool to me - a good use for an IBM MicroDrive, maybe.
V1.0 gives a nice feeling of culmination to the project (granted, I know they won't stop). Good software always gets past V1, but it's an important milestone!
(sorry, could not contain my enthusiasm for WINE. If necessary, moderate me to -1 never to be seen again.)
True, an overloaded network is congested. There's nothing (or little) we can do about a congested network link that is carrying traffic besides ours. I'm not trying to necessarily reduce congestion on a given link - I'm just trying to cut down on total packets traversing the internet.
Reading your responses I am becoming less sure that this is a worthy goal.
You sound like you're fighting congestion. I'm worried about overloading the networks because we were not responsible with watching to whom we connected.
There's nothing, I agree, a client can do if other clients are making a given link congested aside from not use that link.
But I still think it's important that the network should not make unnecessary total traffic by selecting hosts without at least including as a minor factor their traceroute distance.
This is, again, not an exclusive thing. Seems almost genetic to me: if the network's fine in terms of load then we needn't worry. But if the network is getting congested it makes more sense to hit fewer routers (lower connection count, pull the other end closer, find another route [not likely]). So if we have two links that are perfectly identical, shouldn't we drop the one that's further away? Your n-x idea, in essence.
Maybe I'm still confused, but I think you misunderstand me. I don't want the network to exclusively do this - I just want there to be a minor "evolutionary nudge" towards a flattened out network.
Yes, it's expensive to traceroute. But it's a one-time per-link cost. Seems reasonable to me, though maybe it isn't.
I should clarify: traceroute hop count should not be the *only* statistic used when determining whether to make or drop a link. I think it should, however, be one. Include ping time for some sense of congestion on established links, include malformed packet count, include looped packet count, etc.
Wouldn't a gnutella network that "flattened out" to mimic the underlying structure of the routers be better than one that insisted in creating links that spanned more routers? In the latter the odds of a given router handling lots of streams seems likely, whereas if we keep the connections netwise nearby, packets can potentially stay off the backbones for a hop or two and keep ISP's upstream traffic down (answer to all those "you do know your ISP can't handle all of its users at full bandwidth at once" issues).
For instance: A and B are on the same trunk of a cable modem, C is on a different trunk handled by the same ISP, and D is on an entirely different network.
In theory, nothing prevents gnutella from establishing any particular link setup. Ranging from "everybody connects to one host" (worst case here would be D) to A-B-C-D linkage. Wouldn't "nudging" the network to A-B-C-D instead of [ABC]-D be better? In the latter, every query from A,B,C,or D results in at least three (QUERY) packets that cross the cable-modem's upstream connection. (for instance, A. A->D, D->B and D->C).
Now watch what happens if the network has flattened out to mimic the routers. A sends a query to B. That's on the same trunk! B forwards on to C. That doesn't hit any backbones - it's just ISP internal traffic. C forwards on to D. Ok, we hit the backbone *once*. Not three times.
An answer from D will hit the backbone again. Answers from B or C will not. In the first "Everybody pile on D" senario, answers from B or C would have hit the backbone TWICE! (B->D, D->A)
I remain convinced that tracerouting and "Flattening out" (it's my term, is there a better one) for router mimicing "Oh, a host with 250ms latency that's six fast routers away. I'll use it until I can get a closer one." is better than "OH, Look, there's a host I have no clue where it is but it's ping latency is 250ms. Let's go there." A ping latency of 250ms could be a modem right next to you (no backbone hitting, though slow) or a host across one of the big ponds and your ISP happens to have a favorable peering agreement with somebody who owns a cross-pond fiber line. Perhaps ping would urge the network to flatten out, but it does not seem to have a sufficient push if any.
Perhaps the goodness function on a link should be something like:
goodness() = pong_responses - ping latency - hops - malformed packets - duplicate packets. Perhaps with tuning coefficients on each term. More terms might be good, too. Drop links with the worst goodness if we have too many of them and/or drop links whose goodness value drops below a given threshold. (One may also wish to drop links based on other functions, like say just on malformed packets - any more than X or Y% of them and we drop the link).
This should also work with the "ultrapeer" stuff that's crept into the gnutella protocol (on which I pass no judgement, not being familiar enough with it.)
Here's a really wacked-out thought I had that I've been working on.
Gnutella clients can sometimes have more "potential" connections out to the network than MAX_CONNECT (because they open, say five, expecting two and get four). If so, why not do a traceroute to each of the hosts and crop out the one that is the most hops away? Iterate cropping until there are MAX_CONNECT active connections.
This would tend to favor a network that closely reflected the underlying structure of the network - thus reducing any earth-shattering impact on the inet backbone?
To further force a short-inet-distance perhaps clients should (optionally) not accept connections from far-flung hosts?
Additionally, clients should count already-seen packets (which they are supposed to drop) against the goodness of a given link - thus reducing routing loops in the network and forcing it to flatten out instead of clump together.
These might allow clients to have a higher TTL without increasing net net (har har) bandwidth - less duplicated, circularly-routed, lengthy-path, etc, data.
I suspect (have not checked) that some clients do the latter (routing loop prevention), but I know of none doing the formers.
I will get around to coding this soon, unless somebody can tell me it's a stupid idea (for a good reason).
The problem is that NT has had numerous long-time-from-discovery-to-patch root^WAdministrator exploits. A virus could *easily* include the exploit in itself and run as, ta-da, a user executable jumping to ring 0 and then activating its self-replication and payload functions.
To my knowledge, there have been some root exploits in Linux, mostly in daemons. But the difference has been that they are typically fixed quickly.
Recall the GUID in MSWord bit allowing the feds ("they") to secure the identity of a virus writer?
Perhaps you're right - GUID (which I always though was Globally Unique IDentifier) only id the system on which the software (since.doc is just a container, it can include VB macros and is thus "software") was created - but it's not a nonissue like you make it seem, since it has been (ab)used in the past.
Contains the artist information [account to be paid is all that matters]
Then if we can take an arbitrary file (say Out-of-SYNC's latest hit) and just change the artist encoding information inside the.NAP to your account or somesuch - just change it. Now, somebody fetches the file, and it pays... the new guy? Sounds like an interesting way to rip people off.
Oh, and a theoretical (but I doubt likely) way that Napster could use pubkey crypto:
Alice owns the file already.
Bob wants the file.
Eve is trying to steal the file during transfer.
Napster wants Alice to only be able to play Alice's copy of the.NAP and Bob to only be bale to play Bob's.
Bob sends Alice his public key and request for the file (after searching).
Alice runs the file through her private-key decryptor (or Alices's Napster program does, keeping the data hidden from Alice herself) then encrypts it with Bob's public key. This can be done as a stream operation.
This is then sent to Bob. Eve, intercepting every packet, would have to know Bob's private key, but that wasn't sent. Eve gets the shaft, Napster gets what they want, Alice is happy and has done a Good Deed of sharing her bandwidth, and Bob's your Uncle.
Now the decoder would have to be called twice (to play and to send), but it doesn't seem otherwise too expensive... another packet for public key and some CPU time.
_Knots
I find it amusing as hell that the record companies actually think that they can still hold on to their more conservative models of distribution.
Even if Napster becomes a $10/mo. service and the download caps are file-count based (as opposed to size, though I'd rather have no caps) and still above the size of a CD... why complain? You get the music in a "Secure" (*AHEM*) file format [and, especially if you're not a US citizen, if it's not "secure" yet::wink wink:: then make it so], more than a CD's worth, and at ~half the price of a normal CD.
Perhaps a better model would be $10/mo for a given (say 50 file) cap, and $.50 for every file above that? This way you can still get music and if you just have to have a lot of music one month... can do, sure thing. Still cheaper than a CD.
Hey, I might even go for this. Especially if the.NAP format is opened up^W^W"secured", Napster does a bunch of their own hosting (guaranteed availibility), and the RIAA promises not to sue Napster again. Though I'd like it better if... Napster paid the *ARTISTS* and the ARTISTS could hold their own copyright.
That last part is what's preventing me from singing up for a for-pay service. Yes, using things like LimeWire is stealing. But so is paying the RIAA - it's just been relocated.
Somebody HELP ME, here.... I like music, I like MP3, and I love controlling my own files. How do we best reorganize copyright law? Or do we delete it alltogether? (And, while we're on it... can we delete/severly reorganize the government?)
This has been around a long while. I recall (sorry, no reference, somebody help me out here!) reading this about a long while ago in Science/Nature/SciAm.
Still, the technology's fascinating. Though I'm a little shocked that the latest articles still have no other examples (in detail, that bit about HAL doesn't count) than the two-tone recognition.
More detail (if memory serves): the FPGA outputs a logic LOW on a 100-Hz wave and a logic HIGH on a 1000-Hz wave. It is programmed by an evolved bit-sequence fed from a host PC computer. IIRC they started with random noise to wire the gates, so that's cool.
Slashdot Mirror
Uh, duh, the idea of Open Software may be fairly new, but it's certainly not *untested* (I test it every day by running Linux - works fine for me. If it doesn't for you, don't use it. Geesh, nobody said you had to. Now if only nobody said we *had* to use Microsoft [yes, I'm referring to job environments here]).
Most political theorists have simply rationalized their contemporary system - Burke, Hobbes, Aristotle, Plato, etc. They made good points sometimes in so doing, but still, they rationalized a lack of change. Rousseau, somebody on the other side, proscribed a new system which has never, as far as I am aware, been implemented except in microcosm. Marx, whom you were probably referring to, looked at the system around him, got a lot wrong, but got a lot of key things right - welcome to the humanities department. Marx has even been quoted as saying "I am not a Marxist" by which he meant that he did not wish to be associated with people who misinterpereted his ideas. He didn't intend the USSR, nor China, nor Cuba, you get the idea, to become communist - he intended Germany, an already industrialized, wealthy nation to become the first communist country - or a nation much like it. So of COURSE his theory failed, because it was not given the correct prerequisites. It's actually an impressive dillema of communism - the working classes in those countries that *could* go communist didn't and don't wish to. So it's untested and has remained so, despite the claims of "communistic" states, one never existed. Perhaps one never can, but don't knock that which has never been truly put into practice for a test run.
And about the treaty.... It makes next to no social sense for the megacorps to be forcing their views on the world. And economical..... only if you believe in trickledown economics. Which *has* been implemented - by the past nine Republican presidents.... and has been linked with nine downturns in the economy, each within six months of the president's assent to office.
So sorry to waste page space, but I feel better now. Thanks.
The pessimist in me wants to say "bend over and kiss your ass goodbye" - the next step to a corporation-controlled digital age.
Maybe (maybe) it will get better before it gets really bad, but reality's shaping up a lot like this.
Can anybody point a link to a list of all the countries that have so far bought into this?
If you're trying to minimize Hamming distance, wouldn't it be better to establish the first connection without an ID then ask the peer for its ID and the IDs around it? Then we pick a non-occupied one and use it.
Then we can just start making connections, getting their IDs, and dropping the furthest out, yes?
I like the idea of "introduction" via peers - watch addresses that come by, if one is a certain Hamming distance or shorter away from one of our connections, tell that connection. 's that basically how it works?
Finding Hamming distance sounds like a parity-class problem (XOR and sum, right?) so it shouldn't be bad at all. Though is there an easier way for the sum part of it than "if the last bit is one, increment counter, rotate right, repeat"? This might not be a problem, and that's an O(n) loop (right?) - not bad, but is there an O(1) solution? Maybe we'll just want to check addresses at random rather than every one - save cycles for more useful things. Also, saturated hosts will probably not even bother with comparisons - if all n of our local peers are right, then why bother?
If we use the introduction method, won't the "core" of the network [those hosts that stay on for a long long time] eventually fall into place as a proper hypercube?
How do we handle address space conflicts? If, say, the network were to partition itself in two, somehow (links just happened to be dropped in the right way), and then a host comes up that bridges the two segments, what do we do? Worse, what happens if two perfect hypercubes overlap [all n connections in each are only one bitflip away, and all have the same numbers]?
--Knots
Huh? Small-government lets-leave-it-all-to-the-market monopoly-friendly the-huge-corporations-are-our-friends-really libertarian?
How's *that* going to help? Yes, some of the libertarian politics (ending the war on drugs) are good... but...
I've been trolled.
-Knots
What about self-updating viruses? Take Code-Red, add already-infected detection so Target knows when Infector is scanning it, then Infector checks its local database of attacks and asks Target if it 1) has additional, 2) would like one of the ones it doesn't have that Infector does and 3) for success-statistics on every known method (just two counters, success / total attempts). If the success / total ratio goes too low, the virus could shed that attack, assuming that it has become patched everywhere. Shedding might be done in a non-probabilistic manner so that not all the viruses shed an attack (there will be *somebody*).
Additionally, using non-random address generators could help (OH, look, I'm on 192.168.0.10/24... let's attack all the 192.168.0.* hosts first) and get some interesting virus (beowulf? Sorry...) clusters up.
Comments?
--Knots
Innovation would be slower, because companies could not expect to receive as much profit from the VERY EXPENSIVE RESEARCH that goes into these designs. Without some protection, the profit motive is gone. Without profit, the research doesn't get done.
Without patents, we'd still be using abacuses
Excuse me, no. Research is VERY VERY EXPENSIVE, yes, but SO IS CONSTRUCTING THE FAB PLANTS for *anything*. A high barrier to entrance means that it will *always* be easier for Intel to upgrade their cleanroom facilities than somebody to come along and build new ones (think replacing a filter vs. building an entire building). And in terms of software... until MS, nobody really thought of commodifying the OS - maybe that's a better world we didn't enter. I think it certainly has potential. Extrapolate upwards from the OS. Software's just data... do we have a right to encapsulate data and sell it at excessive prices (more than media cost)?
-Knots
I think you misunderstand - my bad. The first error message should probably be "Transfered N files from client X with resulting MD5 hashes that did not match advertized MD5 hash - mistrusting this client." A client would advertize an MD5 hash of the file as they had it stored. ID3 tags would carry into the hash you advertized and the file I recieved, unless you were cheating or the network was bad or my box was borked.
-Knots
Massively heirarchical routing schemes sound cool, but how are we going to enforce these in a truly anarchistic system? We can't trust The Technology, because I for one (and I'd imagine others) want perfect control over their equipment.
Yes, WAPs can do DHCP. That's cool for the internal network (I do something similar at my house but instead of a WAP it's my old router computer) - I hand out 192.168.*.* addresses to my internal LAN and do bridging out to my publicly assigned IP address. Now there's the problem. In a truly peer-to-peer system, how does anybody's router get a valid external IP address? GARP is one way, but that would be *a lot* of returns. Maybe pick random IPv6, ARP it, repeat until one's found that's clear... so we have an address, cool.
Ok, so we have an address. If we are to have this system use anything like the internet routing protocols, such randomly distributed IPs are going to be slightly painful, I'd think... either everybody ends up broadcasting EVERYBODY's packets (ala Gnutella where it's just TTL that prevents infinite loops) or we do some kind of multi-WAP routing. If the latter, our routing tables grow enormous unless we have good heirarhical control over the network. But without "ultrapeers" or somesuch (servers), we don't.
For an average setup I'd imagine there'd only be one WAP. Ok, this setup runs GNUTELLA style and rebroadcasts everything, docking TTL by one. Somebody down the street picks it up.
Eventually we either get to a MASQed internet connection and the packets are pulled off the wireless network (while still maybe propagating across other links and maybe being resent there... doesn't make websites happy when they see what looks like a DDoS) and routed or we end up being sent over some kind soul's tight-beam 802.11 connection (or other) [this person is running a multi-WAP setup and has the huge routing tables] to another part of the OpenNetwork and the routing mayhem begins again.
Imagine a very simple network composed of a small city in which three people have outside links - one a cable modem, one a DSL line, and one a 802.11 tight-beam relay to an adjacent city. Now, one random house in this city sends out a packet. Their neighbors ALL pick it up and retransmit it. Eventually it finds its way to ALL the ways off the local WLAN (DSL, CM, TB) and follows ALL those routes AT ONCE. So all packets get cloned 3 times then passed on to the general internet and... multiply by a huge number of users.. it's a DDoS without intending one.
Maybe some kind of RIP protocol would be needed combined with some form of localized onionrouting? So if I maintain a router to another city / the internet / wherever, I publish such information via RIP to everybody in the local community over the WLAN (broadcast to our internal MAC addresses, harvested via ARP caching?). As the broadcast propagates, additional payload is added to the packet - effectively a traceroute. So then the clients, if they wish to use my uplink, sourceroute their packets via the reverse of the shortest chain - so packets do not get cloned because other recieving WAPs drop them. I think that works...
Sounds like a great project to get thinking on / researching.
Thanks for the responses, Mr. Neutron!
-Knots
Alright, wireless anarchy is very very cool to talk about, but raises some serious problems.
1) Routing tables could potentially grow HUGE to handle loops within the system.
2) I think (am I wrong?) that a system would require point-to-multipoint or at least WAP-to-WAP, which IIRC 802.11b was bad at.
2.1) Either that or we need two or more 802.11b repeaters on anybody's internal network. Not necessarily a bad thing, but it's more complicated, since one (or more) would have to be able to touch somebody else's WAP. Is there some combination of AdHoc and AP modes that the 802.11 system can operate in?
3) How do you assign an IP address? No DHCP servers, can't be static... messy, no?
4) Suddenly route-advertising and route-discovery would have to become standard features on all WAPs.
That said... it sounds really cool and I'm thinking of solar-powered UPS-backed PC/104 with PCMCIA 802.11 cards being put up around a community ("For $small we can all share internet access and be online anywhere in {area}"). Maybe just a dream.
-Knots
If I recall correctly, this has been done and actually went to the Supreme Court (here in the US) and was not, in fact, ruled theft.
Granted, the owner of the coil also owned the land over which the high-tension lines passed.
-Knots
Any attempt at cheat-proofing karma requires a central system which is by definition not a peer.
So while it's a nice try, you'd have to trust people to keep their karmas right. And the minute you put in a system for that, you may as well just rely on a pubkey web of trust. That could work, but only if the web becomes dense enough (and even then you either need keyservers or have to carry around huge chunks of the trust-web's data in your device).
So that defeats the peer-to-peer nature of the network. Seems to me that we'll need semi-smart clients - "Transfered two files from client X with incorrect MD5 hashes - assuming bad netlink or untrusted peer", "Data transfered is not advertized size", etc. Maybe a given peer could keep a short term "karma-cache" of a couple hosts (user configurable number). Then at a LAN party, say, a misbehaving client could get automagically shut-out of the network while clients that behaved correctly gradually increased their trust. Add in a little button "Trust +1" or "Trust -1" in the client and we're good to go.
Maybe I'm just talking out of my ass but it sounded cool to me!
--Knots
So you set up some search queries with priorities ahead of time and the system regularly sends out broadcast pings and/or listens for others to send out pings.
Either way, once the devices have each other's MAC addresses, they can handshake and then:
1) request other device's file list
let's say name, size, and MD5 hash at minimum.
2) search against pre-set search criteria.
3) request download of highest (if multiple) priority match - if tie or no priorities, then just pick a random one. Or maybe shortest if link quality is bad.
4) Repeat 3 as long as device is in range.
5) Optionally delete any incompletely transfered / incorrectly transfered (differing MD5 hash) files.
Sounds really cool to me - a good use for an IBM MicroDrive, maybe.
--Knots
Urhm.... I doubt anybody'd be using EEPROM for something as dynamic as web indexing.
1) It's slow to write and must be erased either byte-at-a-time or block-at-a-time.
2) Most EE chips can't store data well after 100000 write-erase cycles.
Given that google updates every other day or so, I highly highly doubt they're using E^2.
--Knots
I say way to go WINE!
V1.0 gives a nice feeling of culmination to the project (granted, I know they won't stop). Good software always gets past V1, but it's an important milestone!
(sorry, could not contain my enthusiasm for WINE. If necessary, moderate me to -1 never to be seen again.)
True, an overloaded network is congested. There's nothing (or little) we can do about a congested network link that is carrying traffic besides ours. I'm not trying to necessarily reduce congestion on a given link - I'm just trying to cut down on total packets traversing the internet.
Reading your responses I am becoming less sure that this is a worthy goal.
--Knots
I think we're fighting different issues.
You sound like you're fighting congestion. I'm worried about overloading the networks because we were not responsible with watching to whom we connected.
There's nothing, I agree, a client can do if other clients are making a given link congested aside from not use that link.
But I still think it's important that the network should not make unnecessary total traffic by selecting hosts without at least including as a minor factor their traceroute distance.
This is, again, not an exclusive thing. Seems almost genetic to me: if the network's fine in terms of load then we needn't worry. But if the network is getting congested it makes more sense to hit fewer routers (lower connection count, pull the other end closer, find another route [not likely]). So if we have two links that are perfectly identical, shouldn't we drop the one that's further away? Your n-x idea, in essence.
Maybe I'm still confused, but I think you misunderstand me. I don't want the network to exclusively do this - I just want there to be a minor "evolutionary nudge" towards a flattened out network.
Hey, thanks for all the responses.
--Nathan
Yes, it's expensive to traceroute. But it's a one-time per-link cost. Seems reasonable to me, though maybe it isn't.
I should clarify: traceroute hop count should not be the *only* statistic used when determining whether to make or drop a link. I think it should, however, be one. Include ping time for some sense of congestion on established links, include malformed packet count, include looped packet count, etc.
Wouldn't a gnutella network that "flattened out" to mimic the underlying structure of the routers be better than one that insisted in creating links that spanned more routers? In the latter the odds of a given router handling lots of streams seems likely, whereas if we keep the connections netwise nearby, packets can potentially stay off the backbones for a hop or two and keep ISP's upstream traffic down (answer to all those "you do know your ISP can't handle all of its users at full bandwidth at once" issues).
For instance: A and B are on the same trunk of a cable modem, C is on a different trunk handled by the same ISP, and D is on an entirely different network.
In theory, nothing prevents gnutella from establishing any particular link setup. Ranging from "everybody connects to one host" (worst case here would be D) to A-B-C-D linkage. Wouldn't "nudging" the network to A-B-C-D instead of [ABC]-D be better? In the latter, every query from A,B,C,or D results in at least three (QUERY) packets that cross the cable-modem's upstream connection. (for instance, A. A->D, D->B and D->C).
Now watch what happens if the network has flattened out to mimic the routers. A sends a query to B. That's on the same trunk! B forwards on to C. That doesn't hit any backbones - it's just ISP internal traffic. C forwards on to D. Ok, we hit the backbone *once*. Not three times.
An answer from D will hit the backbone again. Answers from B or C will not. In the first "Everybody pile on D" senario, answers from B or C would have hit the backbone TWICE! (B->D, D->A)
I remain convinced that tracerouting and "Flattening out" (it's my term, is there a better one) for router mimicing "Oh, a host with 250ms latency that's six fast routers away. I'll use it until I can get a closer one." is better than "OH, Look, there's a host I have no clue where it is but it's ping latency is 250ms. Let's go there." A ping latency of 250ms could be a modem right next to you (no backbone hitting, though slow) or a host across one of the big ponds and your ISP happens to have a favorable peering agreement with somebody who owns a cross-pond fiber line. Perhaps ping would urge the network to flatten out, but it does not seem to have a sufficient push if any.
Perhaps the goodness function on a link should be something like:
goodness() = pong_responses - ping latency - hops - malformed packets - duplicate packets. Perhaps with tuning coefficients on each term. More terms might be good, too. Drop links with the worst goodness if we have too many of them and/or drop links whose goodness value drops below a given threshold. (One may also wish to drop links based on other functions, like say just on malformed packets - any more than X or Y% of them and we drop the link).
This should also work with the "ultrapeer" stuff that's crept into the gnutella protocol (on which I pass no judgement, not being familiar enough with it.)
Maybe I'm barking up the wrong tree.
--Nathan
Here's a really wacked-out thought I had that I've been working on.
Gnutella clients can sometimes have more "potential" connections out to the network than MAX_CONNECT (because they open, say five, expecting two and get four). If so, why not do a traceroute to each of the hosts and crop out the one that is the most hops away? Iterate cropping until there are MAX_CONNECT active connections.
This would tend to favor a network that closely reflected the underlying structure of the network - thus reducing any earth-shattering impact on the inet backbone?
To further force a short-inet-distance perhaps clients should (optionally) not accept connections from far-flung hosts?
Additionally, clients should count already-seen packets (which they are supposed to drop) against the goodness of a given link - thus reducing routing loops in the network and forcing it to flatten out instead of clump together.
These might allow clients to have a higher TTL without increasing net net (har har) bandwidth - less duplicated, circularly-routed, lengthy-path, etc, data.
I suspect (have not checked) that some clients do the latter (routing loop prevention), but I know of none doing the formers.
I will get around to coding this soon, unless somebody can tell me it's a stupid idea (for a good reason).
--Nathan
The problem is that NT has had numerous long-time-from-discovery-to-patch root^WAdministrator exploits. A virus could *easily* include the exploit in itself and run as, ta-da, a user executable jumping to ring 0 and then activating its self-replication and payload functions.
To my knowledge, there have been some root exploits in Linux, mostly in daemons. But the difference has been that they are typically fixed quickly.
_Knots
Uhm...
.doc is just a container, it can include VB macros and is thus "software") was created - but it's not a nonissue like you make it seem, since it has been (ab)used in the past.
Recall the GUID in MSWord bit allowing the feds ("they") to secure the identity of a virus writer?
Perhaps you're right - GUID (which I always though was Globally Unique IDentifier) only id the system on which the software (since
-Knots
So maybe he only got classical music? Though I guess the performance of that is copyrighted... somebody tell me!
is broken eventually (soon, no doubt)
Contains the artist information [account to be paid is all that matters]
.NAP to your account or somesuch - just change it. Now, somebody fetches the file, and it pays... the new guy? Sounds like an interesting way to rip people off.
Oh, and a theoretical (but I doubt likely) way that Napster could use pubkey crypto:
Alice owns the file already.
Bob wants the file.
Eve is trying to steal the file during transfer.
Napster wants Alice to only be able to play Alice's copy of the .NAP and Bob to only be bale to play Bob's.
Bob sends Alice his public key and request for the file (after searching).
Alice runs the file through her private-key decryptor (or Alices's Napster program does, keeping the data hidden from Alice herself) then encrypts it with Bob's public key. This can be done as a stream operation.
This is then sent to Bob. Eve, intercepting every packet, would have to know Bob's private key, but that wasn't sent. Eve gets the shaft, Napster gets what they want, Alice is happy and has done a Good Deed of sharing her bandwidth, and Bob's your Uncle.
Now the decoder would have to be called twice (to play and to send), but it doesn't seem otherwise too expensive... another packet for public key and some CPU time.
_Knots
Then if we can take an arbitrary file (say Out-of-SYNC's latest hit) and just change the artist encoding information inside the
That's worse?
::wink wink:: then make it so], more than a CD's worth, and at ~half the price of a normal CD.
.NAP format is opened up^W^W"secured", Napster does a bunch of their own hosting (guaranteed availibility), and the RIAA promises not to sue Napster again. Though I'd like it better if... Napster paid the *ARTISTS* and the ARTISTS could hold their own copyright.
I find it amusing as hell that the record companies actually think that they can still hold on to their more conservative models of distribution.
Even if Napster becomes a $10/mo. service and the download caps are file-count based (as opposed to size, though I'd rather have no caps) and still above the size of a CD... why complain? You get the music in a "Secure" (*AHEM*) file format [and, especially if you're not a US citizen, if it's not "secure" yet
Perhaps a better model would be $10/mo for a given (say 50 file) cap, and $.50 for every file above that? This way you can still get music and if you just have to have a lot of music one month... can do, sure thing. Still cheaper than a CD.
Hey, I might even go for this. Especially if the
That last part is what's preventing me from singing up for a for-pay service. Yes, using things like LimeWire is stealing. But so is paying the RIAA - it's just been relocated.
Somebody HELP ME, here.... I like music, I like MP3, and I love controlling my own files. How do we best reorganize copyright law? Or do we delete it alltogether? (And, while we're on it... can we delete/severly reorganize the government?)
--Knots.
This has been around a long while. I recall (sorry, no reference, somebody help me out here!) reading this about a long while ago in Science/Nature/SciAm.
Still, the technology's fascinating. Though I'm a little shocked that the latest articles still have no other examples (in detail, that bit about HAL doesn't count) than the two-tone recognition.
More detail (if memory serves): the FPGA outputs a logic LOW on a 100-Hz wave and a logic HIGH on a 1000-Hz wave. It is programmed by an evolved bit-sequence fed from a host PC computer. IIRC they started with random noise to wire the gates, so that's cool.
--Knots
Nag nag nag.
That's the "inverse" not the "contrapositive."
Statement: P implies Q
Inverse: ~P implies ~Q
Converse: Q imples P
Contrapositive: ~Q implies ~P
Statement is logically equal to its contrapositive (both true or both false), and ditto for inverse and converse.