GPS satellites do not determine your position. They basically just broadcast a very accurate time signal. The receiver looks to see how far out of phase the time signal from several satellites is to determine your position. At no point do the satellites ever even know that your receiver exists, much less know where it is.
DARPA does do some interesting stuff. A lot of it has ended up with pretty wide utility. Take, for example, the Internet. That's right. If you didn't know already, DARPA is the organization that funded the development of TCP/IP and the earliest versions of the Internet. So, in a lot of ways, this is right up DARPA's ally. I wouldn't be suprised if there is still DARPA-funded code floating around in things like telnetd, sendmail, bind, etc.
Actually, you don't need computers to make the blueprints for a microprocessor. Sure, you wouldn't want to design a PIII by hand. But, how do you think they designed early microprocessors? It was done by literally drawing the design on big ass sheets of clear plastic. Different colors for each layer. Drawn by hand in marker. These sheets then got photographically reduced to make the masks for the actual manufacturing process.
It's actually the same process today, just with better tools. The layers still get (at least partially) drawn by hand in a CAD program. Sure, the CAD program has nice things like cut and past to make the job easier, but it's still the same basic process. Quality simulators make it easier to verify that your design will probably work as intended when you manufacture it, but they are not any more necessary than a spelling checker in your word processor. At least not for simpler designs. It's probably true that something like a PIII with it's RISC/CISC hybrid structure would be almost impossible by hand. But, I bet you could design a reasonable RISC 32-bit processor by hand without automated tools. You might want to ditch the floating point portion. There is probably a reason that hardware floating point came along fairly late in the development of microprocessors.
Actually, this is a very poor analogy. If you like bikes, here is a better one.
In Amsterdamn, they had a system of white bicycles. There weren't owned by anybody. The idea was that if you needed to go somewhere, you would just hop on the nearest white bike, ride it to your destination, and leave it for the next person. Your analogy should be:
Suppose you had a bike, painted it white, and left it outside in a bike rack unlocked with a bunch of other white bikes. Could you then bitch when someone "steals" your white bike? That's what people are doing when they say you can't access open shares. Open shares are not like "[leaving] his bike out on the driveway unlocked". It is actually marking the bike in such a way that anybody who comes along a looks at it (via scanning) will see that the bike is marked as being free to use. By your analogy, every access to a publicly available web or FTP server is like stealing some poor kids bike off of their driveway.
I don't see how you can say that Party C never wanted to be at the party. In order to have an open share, C had to explicity turn that feature on. Now, maybe they didn't understand what they were doing. But, in the absence of evidence to the contrary, it seems safe to assume that when somebody has taken positive action to run a filesharing service available to the world they meant for the public to be able to access it.
Should it be illegal to access an anonymous FTP server? Do I have to get written permission to access an HTTP server? No. The mere fact that someone is running a publicly available server which offers a service to the world without any authentication implies that I can use that service.
If ShareSniffer was some tool for stealing passwords, or hacking into Windows shares by trying to crack the passwords, that would clearly be a tool for assisting hackers. But this isn't the case. Some of the people with open shares may have done it by mistake. But, a lot of them are doing it on purpose. It is a simple way to share files, and it's just as legitimate as running an FTP or HTTP server.
Granted, it might be a good idea for ShareSniffer to put some simple sanity checks in place before reporting shares. For example, it can see if the user has shared their entire hard drive. If they have, it might be a reasonable assumption that that's a mistake which should not be advertised. On the other hand, if only certain folders are being shared, that's probably a legitimate share.
Think about it. The GPL is what gives you permission to re-distribute the code in the first place. If a large company decides to "fight" the GPL, what would they be doing? They would be fighting against the very thing that allows them to use to software! Does this make any sense? No. Why would you go to court when in if you won, your "victory" would consist of losing all rights to the code? If you don't want to use GPL'd code, just don't use it. You don't have to pay a lawyer to go to court and get a judgement which prohibits you from using the code.
In order for a compay to get unfettered rights to a piece of code, it would have to attack the very copyright on the software. This is something that, even if some crazy company decided to attack copyright law, is a separte issue from the GPL. I could try to get Linus's copyright on the kernel challenged in court. I could also try to get M$'s copyright on the Windows source. In both cases, I would have a hard time finding a lawyer. Most importantly, neither case has anything to do with the GPL.
It's hard to say how big of a pipe you would need to run a server. It really depends on a lot of factors if you want to get any kind of estimate. How many servers are in the network? How many clients? How many server-server links? How many clients on the server? Are the servers caching responses (essentially trading local disk and memory usage for network usage)? How efficient is the server-server network? Do servers forward queries they can answer on to other servers? If no, you may miss relevant hits. If yes, the queries consume a lot more bandwidth. There are a lot of design choices to be made, and don't know what the right answers are (if any answers can even be said to be "right")
That said, there are a lot of college students with T3 quality connections. A lot of cable modem's might be suitable also.
The hard part is designing the server-server protocol so that you don't waste any bandwidth with redundant copies of the same query. When a server sends out a query, it should get sent to every other server exactly once. This is a tricky problem. Fortunately, there is a solution. I hesitate to mention it for fear that some coder who isn't half as "l33t" as he thinks he is will screw things up.
The solution is: multicast. Most major universities are connected to I2 which provides native multicast. These same connections also tend to be very fast. This solution pushes all the complexity of getting the queries broadcast out to all the servers onto the network where it belongs. The problem that needs to be solved is a multicast problem. I.e., a single host sends a single packet to a subset of hosts on the network which want to receive that packet. All the servers need to do is join a given multicast group address. When they want to issue a query, they put it into a UDP packet and send it to the group address. The network automagically sends a copy to all the other servers listening to that group address. Any server who has an answer replies back to the issuing server directly. This functionality could probably be dropped into OpenNAP with about 100 lines of code.
Right now, most folks on the Internet don't have multicast connectivity. But, if you have a tiered network, only the servers need to be on the fast multicast connections. The clients just need to connect to one of the available servers via unicast. It's so simple I'm really amazed no one has done it already. Of course, now the scalability issue has been pushed into the network's multicast implementation. I'm guessing that you could build a network with a dozen servers without I2 even noticing. They probably wouldn't complain if you cranked it up to a hundred servers. When your network reached a thousand servers, you will start to get hate mail from the network administrators. But, would there be any need for a thousand servers? Probably not until you had over a million users. BTW, I'm guestimating the number of servers you can have based on the experience of the ramen worm, which had a bug that created tables in the routers similar to a multi-thousand server network.
If I'm following this, then the user who can handle 200 connections only performs his search on the 200 people they are directly connected to. Queries are not forwarded from client to client like in Gnutella, correct? So doesn't this just mean that instead of a single global search space, the users are divided up into lots of little islands depending on the quality of their link? While this approach might very well lead to a practical application, it doesn't seem to be addressing the scalability problems encountered by Gnutella. Rather, it seems that it's just a method for making sure that the users get partitioned into lots of separate networks whose size is small enough that the scaling problems don't crop up.
I have a guess I know what your answer is going to be from later posts, so let me see if I can guess. The answer is that clients will do the search, and if it fails then they will begin dropping the "lame" connections and opening new ones. The problem with this approach is that it will probably generate the same scaling issues that Gnutella faces. The overhead of the clients constantly closing and opening connections might begin to consume significant amounts of bandwidth. Clients who are "full" can still have their bandwidth eaten up by other clients asking them to open new connections. Not to mention the problem of discovering clients to connect to in the first place. The addresses of clients needs to be flooded thru the network somehow. Nobody is going to type in 200 IP address into their config! How well is this part of the protocol going to scale?
The problem isn't how many queries you send out. It's how many you get. If people can query everybody in the network, it isn't going to scale. People with high-bandwidth connections will send out tons of queries because they can, and kill the clients on low-bandwidth connections. You can claim that eventually the folks on low-bandwidth queries will stop getting hits, but in the mean time they are DOA. And if new clients are coming up all the time and searching them, they'll probably never have a usable connection.
Not to mention the problem of having the searcher send out an individual query to every client it want to search. If I understand this correctly, if I want to search 3,000 hosts I have to send out 3,000 otherwise identical packets. This is not what is known as a scalable protocol. In fact, from a network point of view, it's a worst-case scenario.
This is absolutely correct. I talked about this in the Gnutella scalability thread yesterday. Even if you ignore the overhead of your "backbone", the process of even trying to send every query to every client is fundamentally broken. If you want to support people on less than 100bT dorm networks, this is not going to scale.
Just figure out how big a query is, then figure out how many queries per second have to be in the network before all of the client's bandwidth is consumed. If you estimate a query packet to be 1000 bits, your modem users max out at 56 queries per second on the network. And that's an absolute best case which will never ever be acheived in practice.
Until this problem is addressed, these networks will never scale. You have to have some hierarchy of high-bandwidth servers which get the queries and low-bandwidth clients which don't. This can still be a truly distributed network, but you have to distinguish between the machines that have the resources to handle lots and lots of queries and those that don't.
Imagine a two-level network where you have a Gnutella-style network of OpenNap servers which the napster-style clients connect to. The servers distribute the queries amongst themselves to perform the searches. Each server knows what files it's clients are sharing Napster-style, and can answer for them. With this architechture, the well-connected hosts on cable networks and dorm subnets do the heavy lifting of the searches while the dial-up clients get good performance because they aren't being clogged with a bunch of queries. The network scales better because you aren't trying to do lots of work on really slow links. Your network is also more stable because you don't have the clients (which come and go quickly) changing the topology of your "backbone".
Most FUD is not an outright lie. It is quite possible to spread FUD by stating the truth in an unfavorable light. When Microsoft critizes Linux for having dozens of distro's which are not 100% compatable, that's FUD even though they are technically correct. In your case, your argument is basically that a system with millions of users will generate billions of bytes of traffic. This fact, while true, does not mean that a system is not scalable. In fact, it only means that the million users are generating modem-levels of traffic. 6GBps spread over a million users is ~48Kbps. Modem speeds. If your definition of un-scalable is any protocol which allows the users to run their modems at 85% capacity, then I think you need to include lots of things including FTP and Napster.
That's why I think your paper is FUD. It throws around big scary numbers which are technically correct, but which are in fact very modest levels of bandwidth when averaged over the userbase.
Actually, such schemes have not been rejected here. In fact, such a "tax" already exists on audio cassettes, DAT's, MD's, and Audio CD-R blanks (which are legally different from data CD-R blanks.) True, the tax doesn't apply to "data" media. But, if you think you are living in some capitalist heaven which doesn't have huge amounts of centralist regulation whose sole purpose is to tilt the market in favor of certain large and powerful organizations, you need to get out more.
Yes there is. He looks at aggregate traffic numbers, rather than per-client or per-search numbers. Saying that a search creates 6 GBytes of traffic sounds scary and un-scalable (Table labeled Bandwidth Generated in Bytes (S=83, R=94)). Holly cow, that's a lot of data. Now, table "Reachable Users" reveals that that 6GB of data is searching 7.6 million clients. If we do the math, we find that our traffic level is a little over 800 bytes / client searched (including responses.) Is 800 bytes of traffic for a search unreasonable? I don't think so.
All the author really does is take an example of a mathmatical formula which grows exponentially and show how quickly he gets "scary" numbers. No effort is made to show whether or not the efficiency of Gnutella breaks down as the network increases in size. No effort is made show how much work is done per search or per result. He just makes assumptions about the gnutella network which results in exponential growth in the number of users, and then shows how the aggregate traffic also grows exponentially. Duh. What did you expect? By this logic, nothing scales.
Don't get me wrong, I don't think Gnutella scales either. But you don't need to wave around all the FUDdy math that this guy does to prove it. The argument why it doesn't scale is simple:
The reason is doesn't scale is that every search request (optimally) gets delivered to every client. We don't even have to look at how those searched get delivered. We'll completely ignore the amount of traffic in the backbone, and only count the traffic that has to exist on the last hop to each client. Let's assume that the requests are 100 bytes a piece, or about 1000 bits once we have all the overhead of UDP/IP/ethernet/PPP/ATM/whatever on top. If each search is 1000 bits, and the average client has a 56K modem, the whole thing falls apart when the search rate is 56 searches / second. If we assume 1 million users, each one can only perform a search about once every 5 hours on average before the modem links are 100% full.
The problem here is the broadcast of every search to every client. Any distributed search network needs to either assume very high bandwidth connections for all the clients (because they are all servers to the whole network) or have some hierarchy of caches / servers. The amount of bandwith being used at each client increases as more clients connect. If the number of users goes up by 1000%, the traffic on my local link goes up 1000%. This is why it doesn't scale. It has nothing to do with how many GB of traffic the network as a whole has to handle. It's the simple fact that the traffic at every client increases as more clients connect. This is the problem that has to be corrected, and Jordan's paper never even mentions this fact, relying instead on big scary numbers. His claim at the end that gnutella generates 2.4GBps of traffic for 1 million users is the ultimate FUD. How much traffic does Napster generate when it has 1 million people connected? He probably doesn't know because their servers go down first.
If you want to have some fun, you should write to Coke and Pepsi and tell them about the bars that are serving Pepsi when you order Coke. When a waitress asks you "Is Pepsi OK?", that's coming down from the soft drink manufacturers. They are all about brand, and hate the thought that their products might be considered interchangable. This probably won't get the bars to stock Coke, but it might make them ask "Would a Jack and Pepsi be OK?"
Cool. I had wondered what created that effect. I've noticed that quite a few materials have that "static" look to them when you light them with the laser. I think the best are cheap plastic toy balls. The ones two are three inches in diameter made out of translucent plastic work really well.
Rambus says your claim is wrong. You say that they "provdied key technology". Bullshit.
---- quote from the C|Net article ----
What did it do while a member of JEDEC? Nothing. Rambus didn't try to persuade JEDEC memory committees to vote on proposals that would affect its patents and didn't vote on any, Rambus has mantained. Some companies had also already licensed Rambus' technology.
"We attended meetings, but we never proposed a standard," said Kanadjian. "We've been very
consistent that lot of inventions we have brought to the market pre-date any issues brought up
at JEDEC."
---/quote ---
In fact, Rambus's whole defense to the FTC probe is that they never pushed or recommended their technology to JEDEC members, making their non-disclosure a non-issue (although still a violation of the rules). If your claim is true, then it just makes Rambus's violation of JEDEC rules all the more egregious.
Well, no one can accuse Rambus of trying to shut out competitors. After all, they don't actually make anything. Their whole game is to get somebody else to actually take all the risk and make the investment needed to actually manufacture memory. They just sit back, skim the cream off and get fat.
In theory, at some point, RAMBUS did actually at least have some technical people working for them. After all, lawyers don't write memory patents by themselves. However, it wouldn't suprise me if by now RAMBUS has fired all the engineer's and is now 100% lawyers.
No, they are sniffing the wireless. The traffic is encrypted (maybe), but if you are a legit user you have the keys. So, just run tcpdump / ethereal / etc. when the card is up and running. Voila, full packet dump. That's one reason why the WEP isn't providing much in the way of security. It just tries to make the wireless equivalent to a shared ethernet. Just like everybody connected to the same hub as you can sniff your traffic, everybody on the same wireless LAN can sniff your traffic.
Have you read this paper? It's whole thrust is that your point #2 is false. Moreover, it only mentions DNS once in passing as an example of a type of packet an attacker might want to modify. At no point does it state or imply that WEP in any way involves DNS.
Number one is correct. This is the hardest part of getting WEP to work, and also the biggest vulnerability (social engineering of the WEP keys)
On two, you should read the referenced article. All of the weaknesses they discovered are independant of the size of the encryption key. They are just as valid for 1024 bit keys as 8 bit keys. The main problems are the too small (24-bit) IV which results in a high rate of reuse of keying material, and the poor choice of a checksum method which allows an eavesdropper to change arbitrary bits in a packet and update the CRC without knowing they WEP key. Had the vendors doing 128-bit WEP gone to a 64/64 split between key and IV it would have been a big improvement. Instead, they split it 104/24 providing no increase in security over the 40/24 split for many attacks.
I'm not sure what you are talking about in three. 802.11 specifies two authentication algorithms. One is a crude "open" method which allows any client to "authenticate". The other is "shared key" which is based on a simple challenge-response using WEP key #1. At no point is DNS involved. In fact, 802.11b has no dependance on any portion of the TCP/IP protocols. It may be that your vendor has included their own authentication on top of 802.11, but if so it has nothing to do with WEP.
You are missing the whole point here. 802.11b uses spread spectrum technologies, and I suspect that if you started from scratch trying to put together hardware to eavesdrop on 802.11b it would be a tough project. But, you are not starting from scratch. You are starting with a working receiver. You would have a hard time listening in on the military using consumer hardware, but if you were starting with a working military receiver it would be much much easier.
Actually, as much fun as this game is, I think it is a zero sum game. There are only so many groups in play at a time, and when I gain control of one, it is removed from the control of somebody else. Or it becomes much harder for the other players to take control of. Either way, I'm better off and everyone else is worse off.
Re:No different from going out in public anyway
on
The Unblinking Eye
·
· Score: 2
This is absolutly what it is. This type of system is not equivalent to police officers looking around and seeing if they notice anyone whose poster is up at the post office. Rather, it is akin to stopping 100% of the people entering the stadium, asking for identification, and then checking to see if they have any outstanding warrents.
Such a blanket, warrentless, and unprovoked intrusion would not stand up to judicial scrutiny if it was conducted the old fasioned way. I don't see how it suddenly becomes okay just because it can be done without the subjects knowledge. By this logic, it's OK search everybodies house as long as you don't waste any of the victim's time in doing so.
This type of automated surveillance system creates both quantitative and qualitative differences from the mere presence of police officers. On the quantitative side, it makes it feasable to place surveillance in literally all public spaces. This is something which is just not going to happen by hiring police officers. There is a difference between knowing that occasionally you might pass a policeman on the street who sees you and knowing that your every public move is being watched.
This type of system also allows qualitative differences in the types of video surveillance it allows. Sure, right now it is billed as a system which only looks for felons. However, it is a trivial extension to have it watch everybody all the time. Every time you go out in public, the "eyes" will watch your every move. Imagine the benefit to a totalitarian government of having accurate lists of everyone who was within a certain radius of a demonstration or police shooting. Imagine the chilling effect on people knowing that there is no longer safty in numbers. Even if you have a large group of people, you will all be identified and dealt with individually later on.
Right now, it's pretty easy to act in an "acceptable" manner in public and reduce your chances of being hassled by a cop to almost zero (at least for white people(meaning that minorities are often "profiled" as criminals, not that minorities are incapable of behaving in public). Behaving in public is part of living in a society. However, with this type of surveillance your behavior won't be judged by your fellow citizens. It will be judged by an invisible and anonymous computer system. Your every move will be tracked and compared to statistical norms. Any deviation from normal behavior will flag you as someone worth investigating.
If you really think that such a system is impossible to abuse, I suggest that you think about it some more. If you really think blanket, invisible, omnipresent surveillance is LESS intimidating than the occasional officer on the beat, I have to wonder what you're smoking.
After all, a DVD is a program. The code that performs the operation of the menus and such is a program. Clearly, and with no doubt. The MPEG stream itself could also be considered a program: it's the object code for the virtual decoder machine. Actually, in the case of a DVD player, it is being fed to a hardware MPEG decoder which is nothing but a special purpose processor.
So, by the MPAA's own logic, it appears that DVD's do not in fact qualify for First Amendment protection. They are programs for DVD players. The fact that they may (or may not) have artistic content or communicate ideas is secondary to their functional aspect as a set of commands to run a DVD player.
Slashdot Mirror
GPS satellites do not determine your position. They basically just broadcast a very accurate time signal. The receiver looks to see how far out of phase the time signal from several satellites is to determine your position. At no point do the satellites ever even know that your receiver exists, much less know where it is.
DARPA does do some interesting stuff. A lot of it has ended up with pretty wide utility. Take, for example, the Internet. That's right. If you didn't know already, DARPA is the organization that funded the development of TCP/IP and the earliest versions of the Internet. So, in a lot of ways, this is right up DARPA's ally. I wouldn't be suprised if there is still DARPA-funded code floating around in things like telnetd, sendmail, bind, etc.
Actually, you don't need computers to make the blueprints for a microprocessor. Sure, you wouldn't want to design a PIII by hand. But, how do you think they designed early microprocessors? It was done by literally drawing the design on big ass sheets of clear plastic. Different colors for each layer. Drawn by hand in marker. These sheets then got photographically reduced to make the masks for the actual manufacturing process.
It's actually the same process today, just with better tools. The layers still get (at least partially) drawn by hand in a CAD program. Sure, the CAD program has nice things like cut and past to make the job easier, but it's still the same basic process. Quality simulators make it easier to verify that your design will probably work as intended when you manufacture it, but they are not any more necessary than a spelling checker in your word processor. At least not for simpler designs. It's probably true that something like a PIII with it's RISC/CISC hybrid structure would be almost impossible by hand. But, I bet you could design a reasonable RISC 32-bit processor by hand without automated tools. You might want to ditch the floating point portion. There is probably a reason that hardware floating point came along fairly late in the development of microprocessors.
Actually, this is a very poor analogy. If you like bikes, here is a better one.
In Amsterdamn, they had a system of white bicycles. There weren't owned by anybody. The idea was that if you needed to go somewhere, you would just hop on the nearest white bike, ride it to your destination, and leave it for the next person. Your analogy should be:
Suppose you had a bike, painted it white, and left it outside in a bike rack unlocked with a bunch of other white bikes. Could you then bitch when someone "steals" your white bike? That's what people are doing when they say you can't access open shares. Open shares are not like "[leaving] his bike out on the driveway unlocked". It is actually marking the bike in such a way that anybody who comes along a looks at it (via scanning) will see that the bike is marked as being free to use. By your analogy, every access to a publicly available web or FTP server is like stealing some poor kids bike off of their driveway.
I don't see how you can say that Party C never wanted to be at the party. In order to have an open share, C had to explicity turn that feature on. Now, maybe they didn't understand what they were doing. But, in the absence of evidence to the contrary, it seems safe to assume that when somebody has taken positive action to run a filesharing service available to the world they meant for the public to be able to access it.
Should it be illegal to access an anonymous FTP server? Do I have to get written permission to access an HTTP server? No. The mere fact that someone is running a publicly available server which offers a service to the world without any authentication implies that I can use that service.
If ShareSniffer was some tool for stealing passwords, or hacking into Windows shares by trying to crack the passwords, that would clearly be a tool for assisting hackers. But this isn't the case. Some of the people with open shares may have done it by mistake. But, a lot of them are doing it on purpose. It is a simple way to share files, and it's just as legitimate as running an FTP or HTTP server.
Granted, it might be a good idea for ShareSniffer to put some simple sanity checks in place before reporting shares. For example, it can see if the user has shared their entire hard drive. If they have, it might be a reasonable assumption that that's a mistake which should not be advertised. On the other hand, if only certain folders are being shared, that's probably a legitimate share.
Think about it. The GPL is what gives you permission to re-distribute the code in the first place. If a large company decides to "fight" the GPL, what would they be doing? They would be fighting against the very thing that allows them to use to software! Does this make any sense? No. Why would you go to court when in if you won, your "victory" would consist of losing all rights to the code? If you don't want to use GPL'd code, just don't use it. You don't have to pay a lawyer to go to court and get a judgement which prohibits you from using the code.
In order for a compay to get unfettered rights to a piece of code, it would have to attack the very copyright on the software. This is something that, even if some crazy company decided to attack copyright law, is a separte issue from the GPL. I could try to get Linus's copyright on the kernel challenged in court. I could also try to get M$'s copyright on the Windows source. In both cases, I would have a hard time finding a lawyer. Most importantly, neither case has anything to do with the GPL.
It's hard to say how big of a pipe you would need to run a server. It really depends on a lot of factors if you want to get any kind of estimate. How many servers are in the network? How many clients? How many server-server links? How many clients on the server? Are the servers caching responses (essentially trading local disk and memory usage for network usage)? How efficient is the server-server network? Do servers forward queries they can answer on to other servers? If no, you may miss relevant hits. If yes, the queries consume a lot more bandwidth. There are a lot of design choices to be made, and don't know what the right answers are (if any answers can even be said to be "right")
That said, there are a lot of college students with T3 quality connections. A lot of cable modem's might be suitable also.
The hard part is designing the server-server protocol so that you don't waste any bandwidth with redundant copies of the same query. When a server sends out a query, it should get sent to every other server exactly once. This is a tricky problem. Fortunately, there is a solution. I hesitate to mention it for fear that some coder who isn't half as "l33t" as he thinks he is will screw things up.
The solution is: multicast. Most major universities are connected to I2 which provides native multicast. These same connections also tend to be very fast. This solution pushes all the complexity of getting the queries broadcast out to all the servers onto the network where it belongs. The problem that needs to be solved is a multicast problem. I.e., a single host sends a single packet to a subset of hosts on the network which want to receive that packet. All the servers need to do is join a given multicast group address. When they want to issue a query, they put it into a UDP packet and send it to the group address. The network automagically sends a copy to all the other servers listening to that group address. Any server who has an answer replies back to the issuing server directly. This functionality could probably be dropped into OpenNAP with about 100 lines of code.
Right now, most folks on the Internet don't have multicast connectivity. But, if you have a tiered network, only the servers need to be on the fast multicast connections. The clients just need to connect to one of the available servers via unicast. It's so simple I'm really amazed no one has done it already. Of course, now the scalability issue has been pushed into the network's multicast implementation. I'm guessing that you could build a network with a dozen servers without I2 even noticing. They probably wouldn't complain if you cranked it up to a hundred servers. When your network reached a thousand servers, you will start to get hate mail from the network administrators. But, would there be any need for a thousand servers? Probably not until you had over a million users. BTW, I'm guestimating the number of servers you can have based on the experience of the ramen worm, which had a bug that created tables in the routers similar to a multi-thousand server network.
If I'm following this, then the user who can handle 200 connections only performs his search on the 200 people they are directly connected to. Queries are not forwarded from client to client like in Gnutella, correct? So doesn't this just mean that instead of a single global search space, the users are divided up into lots of little islands depending on the quality of their link? While this approach might very well lead to a practical application, it doesn't seem to be addressing the scalability problems encountered by Gnutella. Rather, it seems that it's just a method for making sure that the users get partitioned into lots of separate networks whose size is small enough that the scaling problems don't crop up.
I have a guess I know what your answer is going to be from later posts, so let me see if I can guess. The answer is that clients will do the search, and if it fails then they will begin dropping the "lame" connections and opening new ones. The problem with this approach is that it will probably generate the same scaling issues that Gnutella faces. The overhead of the clients constantly closing and opening connections might begin to consume significant amounts of bandwidth. Clients who are "full" can still have their bandwidth eaten up by other clients asking them to open new connections. Not to mention the problem of discovering clients to connect to in the first place. The addresses of clients needs to be flooded thru the network somehow. Nobody is going to type in 200 IP address into their config! How well is this part of the protocol going to scale?
The problem isn't how many queries you send out. It's how many you get. If people can query everybody in the network, it isn't going to scale. People with high-bandwidth connections will send out tons of queries because they can, and kill the clients on low-bandwidth connections. You can claim that eventually the folks on low-bandwidth queries will stop getting hits, but in the mean time they are DOA. And if new clients are coming up all the time and searching them, they'll probably never have a usable connection.
Not to mention the problem of having the searcher send out an individual query to every client it want to search. If I understand this correctly, if I want to search 3,000 hosts I have to send out 3,000 otherwise identical packets. This is not what is known as a scalable protocol. In fact, from a network point of view, it's a worst-case scenario.
This is absolutely correct. I talked about this in the Gnutella scalability thread yesterday. Even if you ignore the overhead of your "backbone", the process of even trying to send every query to every client is fundamentally broken. If you want to support people on less than 100bT dorm networks, this is not going to scale.
Just figure out how big a query is, then figure out how many queries per second have to be in the network before all of the client's bandwidth is consumed. If you estimate a query packet to be 1000 bits, your modem users max out at 56 queries per second on the network. And that's an absolute best case which will never ever be acheived in practice.
Until this problem is addressed, these networks will never scale. You have to have some hierarchy of high-bandwidth servers which get the queries and low-bandwidth clients which don't. This can still be a truly distributed network, but you have to distinguish between the machines that have the resources to handle lots and lots of queries and those that don't.
Imagine a two-level network where you have a Gnutella-style network of OpenNap servers which the napster-style clients connect to. The servers distribute the queries amongst themselves to perform the searches. Each server knows what files it's clients are sharing Napster-style, and can answer for them. With this architechture, the well-connected hosts on cable networks and dorm subnets do the heavy lifting of the searches while the dial-up clients get good performance because they aren't being clogged with a bunch of queries. The network scales better because you aren't trying to do lots of work on really slow links. Your network is also more stable because you don't have the clients (which come and go quickly) changing the topology of your "backbone".
Most FUD is not an outright lie. It is quite possible to spread FUD by stating the truth in an unfavorable light. When Microsoft critizes Linux for having dozens of distro's which are not 100% compatable, that's FUD even though they are technically correct. In your case, your argument is basically that a system with millions of users will generate billions of bytes of traffic. This fact, while true, does not mean that a system is not scalable. In fact, it only means that the million users are generating modem-levels of traffic. 6GBps spread over a million users is ~48Kbps. Modem speeds. If your definition of un-scalable is any protocol which allows the users to run their modems at 85% capacity, then I think you need to include lots of things including FTP and Napster.
That's why I think your paper is FUD. It throws around big scary numbers which are technically correct, but which are in fact very modest levels of bandwidth when averaged over the userbase.
Actually, such schemes have not been rejected here. In fact, such a "tax" already exists on audio cassettes, DAT's, MD's, and Audio CD-R blanks (which are legally different from data CD-R blanks.) True, the tax doesn't apply to "data" media. But, if you think you are living in some capitalist heaven which doesn't have huge amounts of centralist regulation whose sole purpose is to tilt the market in favor of certain large and powerful organizations, you need to get out more.
Yes there is. He looks at aggregate traffic numbers, rather than per-client or per-search numbers. Saying that a search creates 6 GBytes of traffic sounds scary and un-scalable (Table labeled Bandwidth Generated in Bytes (S=83, R=94)). Holly cow, that's a lot of data. Now, table "Reachable Users" reveals that that 6GB of data is searching 7.6 million clients. If we do the math, we find that our traffic level is a little over 800 bytes / client searched (including responses.) Is 800 bytes of traffic for a search unreasonable? I don't think so.
All the author really does is take an example of a mathmatical formula which grows exponentially and show how quickly he gets "scary" numbers. No effort is made to show whether or not the efficiency of Gnutella breaks down as the network increases in size. No effort is made show how much work is done per search or per result. He just makes assumptions about the gnutella network which results in exponential growth in the number of users, and then shows how the aggregate traffic also grows exponentially. Duh. What did you expect? By this logic, nothing scales.
Don't get me wrong, I don't think Gnutella scales either. But you don't need to wave around all the FUDdy math that this guy does to prove it. The argument why it doesn't scale is simple:
The reason is doesn't scale is that every search request (optimally) gets delivered to every client. We don't even have to look at how those searched get delivered. We'll completely ignore the amount of traffic in the backbone, and only count the traffic that has to exist on the last hop to each client. Let's assume that the requests are 100 bytes a piece, or about 1000 bits once we have all the overhead of UDP/IP/ethernet/PPP/ATM/whatever on top. If each search is 1000 bits, and the average client has a 56K modem, the whole thing falls apart when the search rate is 56 searches / second. If we assume 1 million users, each one can only perform a search about once every 5 hours on average before the modem links are 100% full.
The problem here is the broadcast of every search to every client. Any distributed search network needs to either assume very high bandwidth connections for all the clients (because they are all servers to the whole network) or have some hierarchy of caches / servers. The amount of bandwith being used at each client increases as more clients connect. If the number of users goes up by 1000%, the traffic on my local link goes up 1000%. This is why it doesn't scale. It has nothing to do with how many GB of traffic the network as a whole has to handle. It's the simple fact that the traffic at every client increases as more clients connect. This is the problem that has to be corrected, and Jordan's paper never even mentions this fact, relying instead on big scary numbers. His claim at the end that gnutella generates 2.4GBps of traffic for 1 million users is the ultimate FUD. How much traffic does Napster generate when it has 1 million people connected? He probably doesn't know because their servers go down first.
If you want to have some fun, you should write to Coke and Pepsi and tell them about the bars that are serving Pepsi when you order Coke. When a waitress asks you "Is Pepsi OK?", that's coming down from the soft drink manufacturers. They are all about brand, and hate the thought that their products might be considered interchangable. This probably won't get the bars to stock Coke, but it might make them ask "Would a Jack and Pepsi be OK?"
Cool. I had wondered what created that effect. I've noticed that quite a few materials have that "static" look to them when you light them with the laser. I think the best are cheap plastic toy balls. The ones two are three inches in diameter made out of translucent plastic work really well.
Rambus says your claim is wrong. You say that they "provdied key technology". Bullshit.
/quote ---
---- quote from the C|Net article ----
What did it do while a member of JEDEC? Nothing. Rambus didn't try to persuade JEDEC memory committees to vote on proposals that would affect its patents and didn't vote on any, Rambus has mantained. Some companies had also already licensed Rambus' technology.
"We attended meetings, but we never proposed a standard," said Kanadjian. "We've been very
consistent that lot of inventions we have brought to the market pre-date any issues brought up
at JEDEC."
---
In fact, Rambus's whole defense to the FTC probe is that they never pushed or recommended their technology to JEDEC members, making their non-disclosure a non-issue (although still a violation of the rules). If your claim is true, then it just makes Rambus's violation of JEDEC rules all the more egregious.
Well, no one can accuse Rambus of trying to shut out competitors. After all, they don't actually make anything. Their whole game is to get somebody else to actually take all the risk and make the investment needed to actually manufacture memory. They just sit back, skim the cream off and get fat.
In theory, at some point, RAMBUS did actually at least have some technical people working for them. After all, lawyers don't write memory patents by themselves. However, it wouldn't suprise me if by now RAMBUS has fired all the engineer's and is now 100% lawyers.
No, they are sniffing the wireless. The traffic is encrypted (maybe), but if you are a legit user you have the keys. So, just run tcpdump / ethereal / etc. when the card is up and running. Voila, full packet dump. That's one reason why the WEP isn't providing much in the way of security. It just tries to make the wireless equivalent to a shared ethernet. Just like everybody connected to the same hub as you can sniff your traffic, everybody on the same wireless LAN can sniff your traffic.
Have you read this paper? It's whole thrust is that your point #2 is false. Moreover, it only mentions DNS once in passing as an example of a type of packet an attacker might want to modify. At no point does it state or imply that WEP in any way involves DNS.
A few corrections.
Number one is correct. This is the hardest part of getting WEP to work, and also the biggest vulnerability (social engineering of the WEP keys)
On two, you should read the referenced article. All of the weaknesses they discovered are independant of the size of the encryption key. They are just as valid for 1024 bit keys as 8 bit keys. The main problems are the too small (24-bit) IV which results in a high rate of reuse of keying material, and the poor choice of a checksum method which allows an eavesdropper to change arbitrary bits in a packet and update the CRC without knowing they WEP key. Had the vendors doing 128-bit WEP gone to a 64/64 split between key and IV it would have been a big improvement. Instead, they split it 104/24 providing no increase in security over the 40/24 split for many attacks.
I'm not sure what you are talking about in three. 802.11 specifies two authentication algorithms. One is a crude "open" method which allows any client to "authenticate". The other is "shared key" which is based on a simple challenge-response using WEP key #1. At no point is DNS involved. In fact, 802.11b has no dependance on any portion of the TCP/IP protocols. It may be that your vendor has included their own authentication on top of 802.11, but if so it has nothing to do with WEP.
You are missing the whole point here. 802.11b uses spread spectrum technologies, and I suspect that if you started from scratch trying to put together hardware to eavesdrop on 802.11b it would be a tough project. But, you are not starting from scratch. You are starting with a working receiver. You would have a hard time listening in on the military using consumer hardware, but if you were starting with a working military receiver it would be much much easier.
Actually, as much fun as this game is, I think it is a zero sum game. There are only so many groups in play at a time, and when I gain control of one, it is removed from the control of somebody else. Or it becomes much harder for the other players to take control of. Either way, I'm better off and everyone else is worse off.
This is absolutly what it is. This type of system is not equivalent to police officers looking around and seeing if they notice anyone whose poster is up at the post office. Rather, it is akin to stopping 100% of the people entering the stadium, asking for identification, and then checking to see if they have any outstanding warrents.
Such a blanket, warrentless, and unprovoked intrusion would not stand up to judicial scrutiny if it was conducted the old fasioned way. I don't see how it suddenly becomes okay just because it can be done without the subjects knowledge. By this logic, it's OK search everybodies house as long as you don't waste any of the victim's time in doing so.
This type of automated surveillance system creates both quantitative and qualitative differences from the mere presence of police officers. On the quantitative side, it makes it feasable to place surveillance in literally all public spaces. This is something which is just not going to happen by hiring police officers. There is a difference between knowing that occasionally you might pass a policeman on the street who sees you and knowing that your every public move is being watched.
This type of system also allows qualitative differences in the types of video surveillance it allows. Sure, right now it is billed as a system which only looks for felons. However, it is a trivial extension to have it watch everybody all the time. Every time you go out in public, the "eyes" will watch your every move. Imagine the benefit to a totalitarian government of having accurate lists of everyone who was within a certain radius of a demonstration or police shooting. Imagine the chilling effect on people knowing that there is no longer safty in numbers. Even if you have a large group of people, you will all be identified and dealt with individually later on.
Right now, it's pretty easy to act in an "acceptable" manner in public and reduce your chances of being hassled by a cop to almost zero (at least for white people(meaning that minorities are often "profiled" as criminals, not that minorities are incapable of behaving in public). Behaving in public is part of living in a society. However, with this type of surveillance your behavior won't be judged by your fellow citizens. It will be judged by an invisible and anonymous computer system. Your every move will be tracked and compared to statistical norms. Any deviation from normal behavior will flag you as someone worth investigating.
If you really think that such a system is impossible to abuse, I suggest that you think about it some more. If you really think blanket, invisible, omnipresent surveillance is LESS intimidating than the occasional officer on the beat, I have to wonder what you're smoking.
After all, a DVD is a program. The code that performs the operation of the menus and such is a program. Clearly, and with no doubt. The MPEG stream itself could also be considered a program: it's the object code for the virtual decoder machine. Actually, in the case of a DVD player, it is being fed to a hardware MPEG decoder which is nothing but a special purpose processor.
So, by the MPAA's own logic, it appears that DVD's do not in fact qualify for First Amendment protection. They are programs for DVD players. The fact that they may (or may not) have artistic content or communicate ideas is secondary to their functional aspect as a set of commands to run a DVD player.