"The Crying of Lot 49" was good, and also short - it's a fast read. And you'll start to understand why occasional email systems are named "Trystero":-) Vineland is also pretty accessible. On the other hand, I made several attempts at reading "Gravity's Rainbow" and just never clicked with it.
Yup, definitely grittier. My basic summary of it is "lots of swords, not much sorcery", and in the (third?) book he credits so-and-so "who made me put in the dragons" which are involved with most of the sorcery side (and really end up more as an excuse to have a couple of characters who hang around locations and cultures that are different from most of the book, which is good for balance and variety.
Oh, even if you *loathe* fantasy, the Discworld books are a scream. (Actually, liking fantasy does help, because so much of it is takeoffs on the whole fantasy genre.) Terry keeps on cranking out more of them, and while some are better than others, they're all worth reading.
OK, so many of them matched the idiosyncracies of his geek friends, but some of them were *my* geek friends as well (though I haven't actually met Neal) so figuring out who was who and who was a composite and who was just a local archetype was part of the fun. For instance, all the "Enhancing Shareholder Value" bit is pure Menlo Park archetypal, and the litcrit girlfriend doing the "War as Text" conference and her snobbish leftie friends are also (or at least they're engineering-types' stereotyped perceptions of those people), though perhaps they were also influenced by specific individuals. On the other hand, the Secret Admirers were rather directly the Cypherpunks, and the little company in Los Altos was quite specific.
Also, reading it now is an opportunity to be nostalgic about that Internet Boom Thing that was so many quarters ago....
Manufacturing plants are mostly an appropriate use for 10.x space and NAT - there's a lot of stuff you want to keep separate. On the other hand, they did a lot of work on IPSEC, so it's possible they'd have enough stuff tunnelled together that it's not enough, with early enough implementations that they were really tunnelling rather than doing NAT or DMZs.
My usual way of dealing with Network 10, by the way, is to expect that there'll be some merger or network interface or other forcing it to combine with another Network 10, so I usually subnet it on Class C boundaries and pick a random number between 10.11.11.* and 10.250.254.* for the starting subnet, not using 10.100.*.*, so that collisions are unlikely.
BitTorrent doesn't have a centralized source for searches either. A given file often has a centralized source, and there are popular tracker sites, just as there are popular websites, but Google is as close to a centralized source as any.
AT&T and BBN are both ISPs (BBN as "Genuity"). In AT&T's case, the 12.0.0.0/8 network was originally for the Hyperchannel that connected the Murray Hill Cray to half a dozen other devices, back when Crays were big. (Hyperchannel was a fast LAN that could feed things like Crays and mainframes. Allegedly there was some reason that the 12.x couldn't be subnetted, though I'm not sure if that was because of the Cray or the Hyperchannel or the Cray's Hyperchannel drivers or something.) So anyway, this Class A address space was just sitting around basically unused when AT&T finally got enough of a clue to get into the ISP business, which was a fairly reasonable thing to use a Class A for.
But Manufacturers don't need Class A addresses. Yes, they roll a lot of boxes off the assembly lines. Then they sell them to customers, who plug them into their own networks (or their ISPs' networks), not into the manufacturers. IBM does need some space for managing machines for its managed-services customers, and if it only needs a million external Internet addresses for its ~300K employees, using a Class A's 16 million addresses is pretty wasteful. In reality, much of that ought to be behind firewalls, in which case it can be RFC1918 private space.
And then there's me - I've got a Class A all to myself, which is 127.*.*.*. Mine, mine, mine, all mine!:-)
Now that CIDR lets us do classless addressing, and NAT lets multiple users share an address, and security forces us to use firewalls anyway, there's really plenty of address space for business use - Class A space has about 2 billion addresses, which can provide one address for every worker in the world with only 4:1 sharing (whether the sharing is done by NAT or by dialup modems, which typically support about 10:1 user:modem ratios.) In practice you need a bit more Real IP access than that, because not everything's allocated efficiently, and because interesting applications might need real external servers, but a lot of sites share far higher ratios than that, and most of the 8 billion people on Earth don't have a desk job with their own dedicated computer.
The real problem is home access - as Hugh Daniel puts it, If you're a NAT on the Net, you're NOT on the Net." In particular, you're dependent on your ISP's firewalls for email, web, and general IP access to the real world, and greatly restricted in your ability to provide information services, especially anything your ISP isn't technically competent at, and you're subject to any filtering or censorship your ISP might do. The canonical example is the "Great Firewall Of China", which tries to prevent Chinese residents from seeing anything about Falun Gong or other forms of thoughtcrime.
It's true that Asia's APNIC got a lot less of the address space than the US did, and they may need some more before the Great IPv6 Renumbering happens. According to IANA's List of IPv4 Address Space Assignments, more than half the Class A space is unused (either never assigned or returned by public-spirited organizations that are using newer technology such as CIDR.) Class B is probably the tightest, though supernets of Class C space took off lots of the pressure. IANA is hoarding the Class A space, and maybe this will push us toward IPv6 a bit faster.
ICANN was actively discouraging IPv6 use a couple of years ago (I haven't checked up on their evil plans lately...) Their method was to declare that they were going to charge $2500 for a/48, which is the smallest generally-allocated block of IPv6 space available - so if you wanted to own your own space, it was going to cost you. I suspect part of the reason was because they wanted the money, of course, and part of it was because they didn't want to lose control over a major chokepoint of the net, but also there's the more legitimate issue that deciding the right way to restructure routing for the future shape of the internet is going to be pretty difficult, and they'd rather delay the existence of working code in order to get rough consensus first.
Wired's April edition had an article about "How Hydrogen Can Save America" by Peter Schwartz and Doug Randall of GBN. It did briefly mention nuclear power, but glossed over the fact that that was the real core of their proposal. Sure, hydrogen can store energy in ways that may be more or less useful compared to batteries, and that may let you move decentralize pollution or centralize it outside of core city areas, but that's not a fundamental change in energy sources. The article says "3. Convert the nation's fueling infrastructure to hydrogen." and "5. Mount a public campaign to sell the hydrogen economy."
The article's relentless insistence on how THE GOVERNMENT MUST MUST MUST IMMEDIATELY LAUNCH A Manhattan-project-like effort to develop a hydrogen economy and SAVE AMERICA reminded me of those Anime Otakudom lines about "The World Will Be Saved By Steam!", or like various other rants that people go on, usually political or anti-drug. Sure, there's good technical discussion in there about fuel cells and storage issues, but that's not really what it's about.
So Remember, Kids, Hydrogen isn't the answer! Professor Steamhead says ""Steam. Water plus heat equals steam. Always remember this. The world can be saved by steam." and he's got a giant steam-powered mecha robot to do the job with!
The first round of this was just random characters in subject lines and small amounts of randomness in text. The stuff I'm getting now is different - it's HTML mail with vast amounts of nonsense or English-like HTML comments breaking up words, especially spammish words. I can't show this in real HTML, because it's too likely that Slashcode will eat it, but it works like this.
Get your Via[COMMENT jwq;fj joihhh h ihgeiohg]gra here ch[COMMENT afdioghdsfhg]eap!
Ma[COMMENT open source linux]ke Mon[COMMENT slashdot stallman]ey fa[COMMENT can't sleep clowns will eat me]st![COMMENT these aren't the spams you're looking for]!!!
It looks like a really nasty attack on Bayesian filters, at least until the filters start recognizing HTML comments as a bad thing.
... but amateurs in small claims court can do well enough to slow down their spam rates and whack the jurisdictionally-vulnerable spammers. (And these days, since high-tech lawyers in Silicon Valley are also often out of work, they'll probably be pickign up a few bucks this way.) So for instance, that spammer in Nigeria who's using a Korean relay is probably out of reach, but the porn spammer who's hosted in one of the many overbuilt hosting centers in Silicon Valley could be in trouble even if his cameras are in Nevada or Kansas somewhere.
Small Claims Court limits vary by state, but they're usually at least $500. So yes, this means you can go to court without a lawyer, and be paid enough to make it worthwhile harassing spammers in your spare time, and as long as you can adequately demonstrate that you've identified the *right* spammer, it shouldn't be too hard to prove that they were bad boys and should be spanked.
It's harder to get the relay-abusers, but most of the people paying spammers to advertise their stuff are reachable, because that's usually necessary to actually get money from the system. And if the law lets you ding the people selling the products, without having to specifically track down the people doing the mailing, that'll sting most of them hard enough they'll at least use much more careful spammers and possibly stop, because they'r e in this to make money, and you can't make money if every successful $500 scamware sale also got two $500 small claims court charges biting you in the wallet.
Sun's NeWS Network Extensible Window System was more powerful and really cool, and as I've commented earlier in this thread, was an ancestor of Java. Both of them shared the Postscript property of getting printing to Just Work Correctly. Other people have commented that it had problems with the licensing being too proprietary, so it didn't catch on compared to X in spite of being better at some things and dangerously flaky at others and having one of the world's coolest debuggers. NexTStEp was somewhat limited by Sun's intellectual property, IIRC, but it's stuck around in various forms and its devotees really loved it.
Postscript is surprisingly closely connected to Java. Back in the 80s at Sun, James Gosling (known for his Emacs version) and David Rosenthal wrote the Network Extensible Windowing System, NeWS, in Postscript. Don Hopkins describes it as "It's a multithreaded PostScript interpreter with extensions to draw on the screen, handle input events, with an object oriented programming facility." It's a cool, elegant window system, though a bit resource-hungry for its day, preferring to be on machines with at least 6-8MB of RAM. Sun spent a while pushing it instead of X Windows, and John Gilmore's Grasshopper Group (and a few other people like Wedge) ported it to things like Macs and Sun3/60s. Some of the cool things about NeWS were
You could make intelligent decisions about what services ran in the client vs. the server, unlike X.
You could download programs to the server, unlike X. This meant that if your application was very mouse-interactive, it didn't need to put up with the communications lag of getting back to the client, but could happen all on your screen, so mouse tracking tended to be rocking fast.
The drawing model was Postscript, so what you saw REALLY WAS what you'd get when you printed it, not some bad font approximation. This meant that fonts scaled CORRECTLY, and printing just worked, and you'd get pleasant surprises like the PSterm terminal emulator, which iconified itself by shrinking down to a little window with 1-pixel characters, live, not just a GIF, so you could see that your application was or wasn't doing things even though you obviously couldn't read anything except banner(1) output.
Because the programs were Postscript, not C, they were hard to debug, and an utter nightmare to do security for, because they tended to let programs leave bits of themselves installed in places they shouldn't be because there wasn't much in the way of memory protection. While this may not be any surprise to Windows programmers, and the only reason it might surprise Palm programmers is that nobody's deliberately malicious on Palms, it was pretty annoying to people used to Unix and X, which *were* cleaner.
The security and debugging issues were a major design influence on one of Gosling's later projects, a language called OAK, which you might know of as Java. The "do the work where you want it, whether that's client or server" capability was another important thing that Gosling kept.
I did some Postscript programming back in the day, enough to print cool things on the printer and replace the NeWS splash screen with "Don't Panic" in nice friendly letters, and as other people have said, it's pretty much like Forth, a Reverse Polish sort of thing that lets you define functions that draw stuff. While Forth's inventors may have had an overblown estimate of his creation's validity (he basically reinvented the subroutine crudely and differently) it was a good language for very small environments, like toasters and embedded systems. It wasn't real clean, but it was very memory-efficient, and this made it tend to be pretty fast.
Chaos! Anarchy! Dogs and Cats Living Together! Crustaceans falling from the sky! The End of the Net as We Know It, MPEGs at 11! Basically, you don't worry about it, and you know that people who'd abuse it can just as well put anonymous letters in the Government-run Post Office Snail Mail or harass people with RFC1149 carrier pigeons.
People commit fraud all the time, and if free wireless in the park makes it easier for New Yorkers because they don't need to use AOL coasters with stolen credit cards, well, other people will have to get more realistic about the accuracy of what they read on the Internet, because after all, it isn't guaranteed to be Fair and Balanced like that Fox TV News or Rush Limbaugh or Public Radio.
Death Threats emailed to Politicians may be annoying to them, and the President has a bunch of Secret Service bodyguards whose job includes figuring out which ones are serious and which are just rants or fakes, and they tend to step all over ISPs to track down the senders, but if New York City bureaucrats are the ISP, they can give as good as they get, and it's not like it's death threats against some beloved figurehead monarch like Queen Elizabeth or Queen Beatrice or Madonna, which would be really really rude.
The President's just this guy doing a job, you know? This is America, where anybody can become President, and where every citizen or resident or foreign traveller's life is just as valuable as his. I don't think any of the people who've actually assassinated American presidents sent threatening letters first (certainly not threatening emails), and while it's a real shame when it's happened, the Constitution is set up to replace him or her, and email to whitehouse.gov is pretty much a bit bucket anyway.
Spam? Yeah, that's a problem, and if NYC is providing free wireless access, it'll pretty quickly end up on anti-spammer blackhole lists anyway. That means that if you want to read or send email, you'll probably want to do a VPN tunnel to your real email provider anyway, just for privacy.
Meanwhile, I got this really interesting business proposition from a corrupt New York City garbage collection licensing bureaucrat's widow, saying that her late husband accumulated $23 million in e-cash at www.don-corleone.org and she needs a way to transfer it to her Swiss bank account before the domain name registration expires...
They're not using it's ability to handle graphics - they're not running graphics on the thing.
What they're doing is using the vector processor parts of Emotion Engine, which is the graphics processor chip, as a number-cruncher, but not actually using it to drive the graphics functions. And they're using the CPU to do I/O and networking and feed stuff to the Emotion Engine.
I saw one of them at the Stanford Electric Car Show a couple of years ago, and they were for sale a couple of blocks from my office in San Francisco. Unless they really improved it, it was really a turkey. First of all, it was $12000, which is more than enough to buy a real car, or a good used car and an overpriced Segway:-) Second, it didn't have enough trunk-like space for a bag of groceries or an overstuffed laptop briefcase. That means it's not really useful for driving to work or the shopping, so it's just a toy (hence the afore-flamed Segway:-)
Depending on whether they're using H.323 or SIP or another standard, the VOIP tends to use a mix of transport protocols. The call setup signalling does tend to use TCP, because that part needs to be reliable and it's ok if it's delayed a couple hundred milliseconds as long as it all arrives and in order. The voice content itself tends to be RTP (Real Time Protocol) over UDP over IP.
I just got my first Nigeria-scam phone call this weekend - some of the scammers have discovered that the relay services for deaf people now have web interfaces as well as the old TDD interfaces. The scammer was calling on a Sunday evening before a US Monday holiday, and apparently wasn't thinking about the fact that just because it was working time in Nigeria, that didn't mean it was working time in the US west coast:-)
90kbps is 64kbps uncompressed audio with IP overhead. Sure, they can compress it to 6.5kbps and get cellphone-quality speech, but if they don't have to compress it for bandwidth reasons, it simplifies a lot of other things. I'd have expected the IP overhead to be a bit lower, but not a lot lower, and one of the problems with VOIP is that the IP overhead doesn't shrink just because the voice does, because the voice needs to send 100 or more samples per second to sound good, so they're all tinygrams.
There are two main components to the bandwidth of VOIP - the actual digitized and optionally compressed voice itself, and the overhead required to package that into IP. Raw telephone-quality voice is 64kbps - 8000 samples per second, each 8 bits (in non-linear mu-law or A-law companding, relatively equivalent to 12-bit-per-sample linear coding.) It may not sound like much to you audiophiles, but it's good enough for speech, giving you a 3-4KHz mono audio signal. There are lots of audio compression techniques, and the most popular ones tend to be 32kbps or 8kbps for wireline use, and 6.5kbps for cellphones, usually transmitted at around 100-200 packets per second. Silence Suppression lets you cut this in half, on average, because you don't need to transmit much in the direction that's not talking.
The problem is the overhead required to pack it into IP packets - you can easily get 40 bytes of header (IP, UDP, RTP) even without IPSEC or NAT traversal or ethernet or PPP, which obviously is a lot to add to a 10-byte data packet. There are Compressed RTP versions that let you reduce this, and in a Cisco VOIP router, 8kbps coding generally uses 11kbps if you can turn on all the compression, or 22kbps if you can't, which depends on lots of things. If they do Voice Over Frame or Voice Over ATM instead (packing it in link-layer frames without IP), it's closer to 8-11kbps, though some of the ATM options let you handle multiple voice and data streams in ways that can be more efficient.
Bandwidth is only part of the issue, though - scalability and signalling are also major drivers. For a couple of years, the fact that you only need ~1/6th as much bandwidth for voice-over-data as you did for compressed voice was really important, and it does reduce call costs, but the other simplicities are important. Traditional circuit-switched voice networks use a skinny signalling network to build 64kbps data paths, which are carried on switches that are very good at connecting together lots of pieces of 64kbps data, and dealing with the complexities of finding the best available route across the entire network. VOIP networks split up most of the problem into edge-based work (compressing the voice, and finding the right destination, and ringing the phones and such) vs. core work (just basic IP transport) so instead of having a core of very expensive very big telephone switches, which is hard to grow without spending lots of money, you have a core of big IP routers, which are a lot simpler, because they're handling a small number of fat pipes and some routing protocols. All the complex work happens at the edge, which scales well, and at the boundaries between the old phone network's SS7 signalling systems and the VOIP signalling systems - the reasons it's taken so long to do much of this have included protocol maturity, especially for the interfaces, as well as capital replacement costs for the edges.
It's much harder to set up a honeypot machine that looks like an interesting attractive nuisance but isn't usable to attack third parties than it is to set up one that's exploitable. (Especially if the holes you leave in to attract crackers let them become root...)
Some of the things you can do are to use a separate machine to monitor your network activity, and filter out some of the more dangerous things (or even filter out all outgoing telnet/ssh/etc...)
Honeypots for trapping spammers are much easier - they're not usually trying to log in and try lots of exploits out to other machines, they're just going for the open relay and open proxy, and if you do a good trap, their first couple of messages will get forwarded (they'll be test messages run by the spammer), and the rest can get/dev/nulled.
It's also a lot like Usenet
on
P2P Meets Push
·
· Score: 1
It's push media - somebody posts something to a newsgroup and you'll get it pretty soon.
It's decentralized - lots of servers handling each channel.
It's varied - there are thousands of newsgroups, and depending on what year it is, it may be easier or harder to create a new one, but it's usually pretty easy. The net that brought us alt.swedish.chef.bork.bork.bork can just as easily do alt.music.icelandic.bjork.bjork.bjork.
newsgroups can be moderated or unmoderated. Most are more like immoderate, but basically there's a choice about whether the content needs to be approved by some group owner before posting.
It's a bandwidth hog:-) A full Usenet feed is probably pretty far past a T3 line by now, though if you skip the binaries (or even just the multimedia) it's probably not.
Slashdot Mirror
"The Crying of Lot 49" was good, and also short - it's a fast read. And you'll start to understand why occasional email systems are named "Trystero" :-) Vineland is also pretty accessible. On the other hand, I made several attempts at reading "Gravity's Rainbow" and just never clicked with it.
Yup, definitely grittier. My basic summary of it is "lots of swords, not much sorcery", and in the (third?) book he credits so-and-so "who made me put in the dragons" which are involved with most of the sorcery side (and really end up more as an excuse to have a couple of characters who hang around locations and cultures that are different from most of the book, which is good for balance and variety.
We're 106 leagues from Ankh-Morpork....
Also, reading it now is an opportunity to be nostalgic about that Internet Boom Thing that was so many quarters ago....
My usual way of dealing with Network 10, by the way, is to expect that there'll be some merger or network interface or other forcing it to combine with another Network 10, so I usually subnet it on Class C boundaries and pick a random number between 10.11.11.* and 10.250.254.* for the starting subnet, not using 10.100.*.*, so that collisions are unlikely.
BitTorrent doesn't have a centralized source for searches either. A given file often has a centralized source, and there are popular tracker sites, just as there are popular websites, but Google is as close to a centralized source as any.
But Manufacturers don't need Class A addresses. Yes, they roll a lot of boxes off the assembly lines. Then they sell them to customers, who plug them into their own networks (or their ISPs' networks), not into the manufacturers. IBM does need some space for managing machines for its managed-services customers, and if it only needs a million external Internet addresses for its ~300K employees, using a Class A's 16 million addresses is pretty wasteful. In reality, much of that ought to be behind firewalls, in which case it can be RFC1918 private space.
And then there's me - I've got a Class A all to myself, which is 127.*.*.*. Mine, mine, mine, all mine! :-)
The real problem is home access - as Hugh Daniel puts it, If you're a NAT on the Net, you're NOT on the Net." In particular, you're dependent on your ISP's firewalls for email, web, and general IP access to the real world, and greatly restricted in your ability to provide information services, especially anything your ISP isn't technically competent at, and you're subject to any filtering or censorship your ISP might do. The canonical example is the "Great Firewall Of China", which
tries to prevent Chinese residents from seeing anything about Falun Gong or other forms of thoughtcrime.
It's true that Asia's APNIC got a lot less of the address space than the US did, and they may need some more before the Great IPv6 Renumbering happens. According to IANA's List of IPv4 Address Space Assignments, more than half the Class A space is unused (either never assigned or returned by public-spirited organizations that are using newer technology such as CIDR.) Class B is probably the tightest, though supernets of Class C space took off lots of the pressure. IANA is hoarding the Class A space, and maybe this will push us toward IPv6 a bit faster.
ICANN was actively discouraging IPv6 use a couple of years ago (I haven't checked up on their evil plans lately...) Their method was to declare that they were going to charge $2500 for a /48, which is the smallest generally-allocated block of IPv6 space available - so if you wanted to own your own space, it was going to cost you. I suspect part of the reason was because they wanted the money, of course, and part of it was because they didn't want to lose control over a major chokepoint of the net, but also there's the more legitimate issue that deciding the right way to restructure routing for the future shape of the internet is going to be pretty difficult, and they'd rather delay the existence of working code in order to get rough consensus first.
The article's relentless insistence on how THE GOVERNMENT MUST MUST MUST IMMEDIATELY LAUNCH A Manhattan-project-like effort to develop a hydrogen economy and SAVE AMERICA reminded me of those Anime Otakudom lines about "The World Will Be Saved By Steam!", or like various other rants that people go on, usually political or anti-drug. Sure, there's good technical discussion in there about fuel cells and storage issues, but that's not really what it's about.
So Remember, Kids, Hydrogen isn't the answer! Professor Steamhead says ""Steam. Water plus heat equals steam. Always remember this. The world can be saved by steam." and he's got a giant steam-powered mecha robot to do the job with!
How's gov.au's liquidity these days? :-)
It looks like a really nasty attack on Bayesian filters, at least until the filters start recognizing HTML comments as a bad thing.
And rejecting HTML mail from non-whitelisted sources is probably a good thing anyway
... but amateurs in small claims court can do well enough to slow down their spam rates and whack the jurisdictionally-vulnerable spammers. (And these days, since high-tech lawyers in Silicon Valley are also often out of work, they'll probably be pickign up a few bucks this way.) So for instance, that spammer in Nigeria who's using a Korean relay is probably out of reach, but the porn spammer who's hosted in one of the many overbuilt hosting centers in Silicon Valley could be in trouble even if his cameras are in Nevada or Kansas somewhere.
It's harder to get the relay-abusers, but most of the people paying spammers to advertise their stuff are reachable, because that's usually necessary to actually get money from the system. And if the law lets you ding the people selling the products, without having to specifically track down the people doing the mailing, that'll sting most of them hard enough they'll at least use much more careful spammers and possibly stop, because they'r e in this to make money, and you can't make money if every successful $500 scamware sale also got two $500 small claims court charges biting you in the wallet.
Sun's NeWS Network Extensible Window System was more powerful and really cool, and as I've commented earlier in this thread, was an ancestor of Java. Both of them shared the Postscript property of getting printing to Just Work Correctly. Other people have commented that it had problems with the licensing being too proprietary, so it didn't catch on compared to X in spite of being better at some things and dangerously flaky at others and having one of the world's coolest debuggers. NexTStEp was somewhat limited by Sun's intellectual property, IIRC, but it's stuck around in various forms and its devotees really loved it.
I did some Postscript programming back in the day, enough to print cool things on the printer and replace the NeWS splash screen with "Don't Panic" in nice friendly letters, and as other people have said, it's pretty much like Forth, a Reverse Polish sort of thing that lets you define functions that draw stuff. While Forth's inventors may have had an overblown estimate of his creation's validity (he basically reinvented the subroutine crudely and differently) it was a good language for very small environments, like toasters and embedded systems. It wasn't real clean, but it was very memory-efficient, and this made it tend to be pretty fast.
The President's just this guy doing a job, you know? This is America, where anybody can become President, and where every citizen or resident or foreign traveller's life is just as valuable as his. I don't think any of the people who've actually assassinated American presidents sent threatening letters first (certainly not threatening emails), and while it's a real shame when it's happened, the Constitution is set up to replace him or her, and email to whitehouse.gov is pretty much a bit bucket anyway.
Meanwhile, I got this really interesting business proposition from a corrupt New York City garbage collection licensing bureaucrat's widow, saying that her late husband accumulated $23 million in e-cash at www.don-corleone.org and she needs a way to transfer it to her Swiss bank account before the domain name registration expires...
What they're doing is using the vector processor parts of Emotion Engine, which is the graphics processor chip, as a number-cruncher, but not actually using it to drive the graphics functions. And they're using the CPU to do I/O and networking and feed stuff to the Emotion Engine.
I saw one of them at the Stanford Electric Car Show a couple of years ago, and they were for sale a couple of blocks from my office in San Francisco. Unless they really improved it, it was really a turkey. First of all, it was $12000, which is more than enough to buy a real car, or a good used car and an overpriced Segway :-) Second, it didn't have enough trunk-like space for a bag of groceries or an overstuffed laptop briefcase. That means it's not really useful for driving to work or the shopping, so it's just a toy (hence the afore-flamed Segway :-)
Depending on whether they're using H.323 or SIP or another standard, the VOIP tends to use a mix of transport protocols. The call setup signalling does tend to use TCP, because that part needs to be reliable and it's ok if it's delayed a couple hundred milliseconds as long as it all arrives and in order. The voice content itself tends to be RTP (Real Time Protocol) over UDP over IP.
I just got my first Nigeria-scam phone call this weekend - some of the scammers have discovered that the relay services for deaf people now have web interfaces as well as the old TDD interfaces. The scammer was calling on a Sunday evening before a US Monday holiday, and apparently wasn't thinking about the fact that just because it was working time in Nigeria, that didn't mean it was working time in the US west coast :-)
90kbps is 64kbps uncompressed audio with IP overhead. Sure, they can compress it to 6.5kbps and get cellphone-quality speech, but if they don't have to compress it for bandwidth reasons, it simplifies a lot of other things. I'd have expected the IP overhead to be a bit lower, but not a lot lower, and one of the problems with VOIP is that the IP overhead doesn't shrink just because the voice does, because the voice needs to send 100 or more samples per second to sound good, so they're all tinygrams.
The problem is the overhead required to pack it into IP packets - you can easily get 40 bytes of header (IP, UDP, RTP) even without IPSEC or NAT traversal or ethernet or PPP, which obviously is a lot to add to a 10-byte data packet. There are Compressed RTP versions that let you reduce this, and in a Cisco VOIP router, 8kbps coding generally uses 11kbps if you can turn on all the compression, or 22kbps if you can't, which depends on lots of things. If they do Voice Over Frame or Voice Over ATM instead (packing it in link-layer frames without IP), it's closer to 8-11kbps, though some of the ATM options let you handle multiple voice and data streams in ways that can be more efficient.
Bandwidth is only part of the issue, though - scalability and signalling are also major drivers. For a couple of years, the fact that you only need ~1/6th as much bandwidth for voice-over-data as you did for compressed voice was really important, and it does reduce call costs, but the other simplicities are important. Traditional circuit-switched voice networks use a skinny signalling network to build 64kbps data paths, which are carried on switches that are very good at connecting together lots of pieces of 64kbps data, and dealing with the complexities of finding the best available route across the entire network. VOIP networks split up most of the problem into edge-based work (compressing the voice, and finding the right destination, and ringing the phones and such) vs. core work (just basic IP transport) so instead of having a core of very expensive very big telephone switches, which is hard to grow without spending lots of money, you have a core of big IP routers, which are a lot simpler, because they're handling a small number of fat pipes and some routing protocols. All the complex work happens at the edge, which scales well, and at the boundaries between the old phone network's SS7 signalling systems and the VOIP signalling systems - the reasons it's taken so long to do much of this have included protocol maturity, especially for the interfaces, as well as capital replacement costs for the edges.
Some of the things you can do are to use a separate machine to monitor your network activity, and filter out some of the more dangerous things (or even filter out all outgoing telnet/ssh/etc...)
Honeypots for trapping spammers are much easier - they're not usually trying to log in and try lots of exploits out to other machines, they're just going for the open relay and open proxy, and if you do a good trap, their first couple of messages will get forwarded (they'll be test messages run by the spammer), and the rest can get