By all means get pedantic, but get accurate as well:)
* S/390 = System/390 = the hardware architecture for current mainframes
* LPAR = hardware partitioning for S/390, can run multiple OSs within these partitions rather as with VM/390.
* OS/390 = Operating System/390 = the OS formerly known as MVS, runs most mainframe sites. Interestingly, it has a complete Unix API built in (not a separate mode), albeit in EBCDIC not ASCII.
* VM/390 = Virtual Machine/390 = the virtual machine hypervisor that can run many different OSs at once, including OS/390, CMS (single user OS, runs in a whole VM dedicated to one user, quite nice to use), and of coures Linux.
OK, that's enough pedantry... I'm not a real mainframe person, I just used to run Unix on an Amdahl mainframe once.
You mean SCO 'owns a controlling interest' in The Open Group? I'd be astonished if this were true - the Open Group is an industry consortium, and no single vendor would be allowed to 'own' it, let alone dominate it.
The Open Group owns the Unix brandname, i.e. if you pass its conformance tests you get to call your product Unix.
This is exactly right - my employer uses it to port an expensive low-volume piece of software to Solaris and maybe Linux in the future. Though we use our own portability layer for other bits of software that are deployed on more than 5 or so hosts per customer...
Paul Thurrott et al need to learn to RTFW - it's obvious from Mainsoft's site that it is largely a product company, and the version number of MainWin is 3.x, so it's been around for a while, long before this rumour. In fact the Linux version of MainWin is relatively recent.
Mainsoft's MainWin is not dissimilar to Wine, except that it is very comprehensive since it is based on Windows NT source code. Mainsoft is using MainWin to port IE and WMP, of course - the same tool was already used for the IE ports to Solaris etc.
That doesn't mean it will be a great looking port, but it will work without having to re-write or extend Wine.
There's an article in IEEE Computer magazine this month, about PicoRadio, a project that's intended to build pervasive ad hoc networks from small wireless nodes.
These 'PicoNodes' are less than 1 cubic centimetre, weigh less than 100 grams (less than most cell phones), consume less than 100 microwatts (vs. 100 milliwatts for Bluetooth). They should even be able to scavenge energy from the environment, including vibrations from people walking by...
This project relies on reconfigurable hardware, amongst other techniques, for very low power consumption. More info, including the article, is available online at the project's home page, http://bwrc.eecs.berkeley.edu/Research/Pico_Radio/
BSD is not 'derived from System V' - it forked off from Unix earlier, maybe version 7 Unix.
Also, Solaris 2.x is based on SVR4 (System V Release 4) - SVR4 is quite upward compatible with SVR3.x.
And Solaris is not spelt with a 'u'...
Linux was not 'built on Posix' (not a meaningful term, Posix is an API spec) but I believe Linus tried quite hard to conform to the 1003.1 specs, and the bash people have tried to conform to the POSIX shell specs.
This is known as reverse path filtering - Linux 2.2 and Cisco IOS with CEF (Cisco Express Forwarding) have this. On suitable Cisco routers the overhead of RPF is minimal, due to the way CEF works. However, it doesn't work with multi-homed customers, amongst other cases.
I'm a QoS specialist at a vendor of policy-based QoS management software - trust me, nobody is going to migrate to IPv6 for QoS purposes.
IPv6 has precisely one extra feature for QoS beyond IPv4 - the flow label, which helps reduce classification load in core routers in RSVP networks. This is a rather unlikely scenario, for details see the RSVP over DiffServ drafts at http://www.ietf.org, in the issll group.
Apart from this one feature, all standard QOS features such as DiffServ, RSVP, COPS, COPS-PR, etc, will work identically in IPv4 and IPv6. The sole speed advantage of IPv6 is its more regular header structure; its disadvantage is that more memory references will be needed for each forwarding and classification decision, so there'll need to be good ASIC or network processor support (as in Intel's IXA architecture) before IPv6 can really take off. However, I expect IPv6 to happen within 2-5 years.
IMO people will migrate to IPv6 to support mobile IP efficiently (its routing header lets you efficiently route to mobile nodes without risking source address spoofing), huge user populations (think millions of mobile phones, tablets, cable modem/ADSL users, etc), and for ease of re-addressing (think companies that are merging or divesting business units).
802.11b is a completely different technology to Bluetooth, with much greater range, about 10 times the bandwidth, and greater power consumption. Not at all comparable to Bluetooth.
One big reason for multicast not catching on is the ability for a single multicast sender to cause congestion at many different points of a network, along with the problems of multicast network management. Until multicast becomes manageable its adoption will be quite slow. A useful paper on this is at http://www.winsock2.com/multicast/whitepapers/ma naging.htm
There's some interesting work on fixing this, though - I forget the details but a recent IEEE Networking magazine had a special issue on multicast including info on why it's not been deployed yet.
Also, for small groups, there is a new protocol called SGM that runs over unicast UDP and unicast routing - the idea is that if you want to multicast to a group of 5-10 or so people, and there's a large number of such groups, you're better off forgetting about IGMP and multicast routing, and just including the list of recipients in the packet. Very neat, though it still requires router support. Some URLs on this:
Do you have references on the reliable unicast protocols being worked on for IPv6 and Linux?
There are many reliable multicast protocols around, some of which at least should work for reliable unicast as well, e.g. RAMP ( http://www.metavr.com/rampDIS.html). See http://www.faqs.org/rfcs/rfc2357.html for criteria for reliable multicast protocols, has some good references.
There is also T/TCP, a variant of TCP which is intended for request/reply transactions - it lets you send data with the initial SYN request and get data back with the ACK, so it's not much less efficient than UDP-based protocols. It would be ideal for HTTP/1.0 but has not really been deployed much.
RADIUS uses its own reliable unicast approach over UDP, and is widely deployed, but it's not a separate re-usable protocol. See www.faqs.org for details.
Some problems with reliable unicast are:
- congestion control - there's no congestion window so it's very easy to overload router buffers and/or receiving host buffers, leading to excessive packet loss for the sender and for other network users
- spoofing - it's even easier to spoof these protocols than with TCP (I think this is why T/TCP never took off)
As for BXXP - I agree about difficulty of understanding what's going on. QoS-aware networks and firewalls all prefer one application mapping to one (static) port.
Firewalls are there for a reason - if you tunnel other protocols over HTTP, you are bypassing the firewall and had better have a very good reason for doing so. Lots of vendors do this, including Microsoft with DCOM and many CORBA vendors as well, but that's not much of an excuse.
Firewall-hostile is a better term for protocols that carry many different types of data.
As a QoS weenie (see http://www.qosforum.com/) I also don't like the way that HTTP can carry many different types of data requiring different QoS (performance) levels, e.g.:
- DCOM over HTTP: needs fairly low latency - CGI transactions: ditto - RealAudio over HTTP: needs low loss, consistent bandwidth - static pages and images: no particular QoS needed
The only way to handle this is to classify every type of HTTP interaction separately, using URLs to map packets into Gold, Silver, and Bronze QoS levels. This is feasible but fragile - as soon as the web-based app or website is updated, you may have to re-write these rules.
Even worse, HTTP/1.1 puts all interactions with a given host into a single TCP session (a good idea in many ways), which makes it a waste of time to prioritise some packets ahead of others - the receiving TCP implementation simply waits until the out of order packets arrive, sending a duplicate ACK in the meantime. Severe packet re-ordering may even lead to slow start in the sending TCP (three duplicate ACKs means slow start from a single packet window size).
Similar issues apply to security - you might want to encrypt only the transaction data and not bother encrypting images, for example, or route some data via a more secure network. SSL does solve some of these problems but requires application support.
Oh well, enough ranting - HTTP is a great protocol in many ways, but there are costs as well as benefits to abusing it to do things it was never meant to do...
Thanks for the pointer, but Intermute is not open source, and it's also a bit dodgy in that it appears to send extra info to the vendor's Internet site on occasion (allegedly).
If you are using IE4 or IE5, you can set per-zone security attributes, e.g. allow Javascript for certain sites that you know are OK, but disallow for other sites.
What would be useful is if someone did a Junkbuster clone or enhancement (see http://www.junkbuster.com, it's a proxy server that just filters ads currently) that could also edit out selected Javascript (e.g. the on-close event).
Ideally this could be done based on whether a site was trusted - e.g. nicesite.com could be allowed to do cleanup stuff in its on-close event, but an unknown & untrusted site would simply not get that event in the Javascript it actually ran.
Does anyone know of an open source tool that does this?
The Word feature to turn off is Fast Saves - this means that when you save a new version on top of the file (e.g. having deleted agents' names), Word simply adds the changed data to the end, to speed things up, rather than rewriting the whole file. So if you ever send a Fast Saved file to someone else electronically, you can be fairly sure to leak some information.
Even though I'm a Palm user, I don't much like the idea of inputting URLs, name & address, or credit card details through a stylus.
The simplest solution is voice input, though that would probably consume far too much power, and may not be ideal in a living room shared with other people. More complex solutions might work, e.g. the TV has an 802.11b or Bluetooth link, or even IrDA, and beams URLs of current programmes and adverts to all and sundry. Of course, there are some security issues - if you are watching the porn channel, Bluetooth would beam the hot URLs everywhere, including outside your house... Encryption might be a good idea here, which 802.11b has, though it's far too expensive for a mass market TV.
The TV industry is looking at broadcasting URLs and small amounts of data alongside the video signal, so that is taken care of, though I don't know the details.
Having redundant links into the Net is certainly one way of handling DDoS, and is in fact already practiced (more for general resilience and performance, but it works well against DDoS) - see http://www.dn.net/technology/network.html for an example of how DigitalNation, a dedicated server hosting company, has tens of links to various ISPs.
This will only work against DDoS if the new routes (i.e. via un-DDOSed links) are advertised out quickly enough - first of all, the IDS needs to detect the DDoS, then it needs to mark the links under attack as down, so that the routing protocol (which has to be BGP as you are interfacing to multiple ISPs), can advertise the new routes.
These routes then have to propagate out throughout the Net, across multiple ISPs, via BGP, until they reach the ISPs of (non-attackers) who are trying to reach your site - these ISPs' routers will then start sending packets via the new routes. The tough part is making sure the route advertisements don't reach the DDoSing hosts - if they do, you have just moved the DDoS attacks onto a new link!
The IDS actually has to analyse the origin of the DDoS attacks (which may mean cooperating with upstream ISPs, since the source addresses will be forged if the attackers have any sense), working out which ISP is hosting the attacking hosts, and then make sure that the route advertisements don't get sent to that ISP. While BGP is very powerful, I'm not sure if it can do this - ask a BGP guru... In any case, if the DDoS attackers are smart enough to subvert hosts in tens of major ISPs, there is no way you can use this 'change route' approach to combat them, without cutting off many legitimate users of your site who are also getting on the Net via those ISPs.
Before DDoS, this approach would have worked, i.e. where there was a single host attacking you - but it's now not sophisticated enough. It may still help in some DDoS attacks, it just depends on luck and the skill of the attackers.
Combatting DDoS is a fundamentally hard problem. The best single mechanism to reduce DDoSes and make them easier to track is RFC 2267 (see www.faqs.org for a copy), which prevents people from injecting packets with forged source addresses (actually they can forge their host address but can't claim to be from a different network). This makes it much easier to directly contact the ISP whose customer or web hosts have been compromised and get them to put in filters blocking the attack.
Without source address spoofing prevention, you have to have a laborious process of going from network operations centre (NOC) to NOC for each ISP back up the chain, getting them to put on traffic analysis tools to see where the traffic is coming from.
Whoops... I've never used a cable to connect my Palm to a mobile phone, so I'm anti-cable I suppose. Maybe IrDA is not common in Japanese handsets.
As soon as you have more than two devices, cabling becomes a nightmare - I have a laptop, Palm device and mobile phone, so adding a mobile Playstation would mean as many as four cables.
GPRS and other mobile phone standards would work with a cable, since they go from the mobile to the base station - typically you would run IP over the cable protocol, then the phone routes this out the other side on top of GPRS or whatever. Yes, your mobile phone is now a real IP router:)
It's not just a matter of deregulation - in the UK, there has been competition in the mobile phone market since it started (Cellnet and Vodafone, then after a few years, one2one and Orange), yet we use a single international standard (GSM) operating on 2 frequencies.
The result is that I can take my dual-band phone to almost any country in the world (except Japan, US, Canada, Mexico and some South American countries) and have it work seamlessly. I can even do short messages (similar to text paging) and data calls (e.g. sending email from my Palm device) from abroad.
I'm not sure why this didn't happen in the US - perhaps the vendors thought the market was big enough for them to go with proprietary standards (e.g. D-AMPS, CDMA) as well as GSM. In the US, GSM is available from Omnipoint and some others, operates on a 3rd frequency, 1900 MHz, but you can get tri-band phones that work on all 3 global GSM frequencies).
Just as with most technologies, standards are a Good Thing...
Looks like an interesting gizmo, particularly if it supports mobile phones with Bluetooth (gives you a few Mbps to the phone) and GPRS (always-on packet-switched connection, designed for IP and not charged by the minute). Even though GPRS will only go at 25-56 Kbps typically, it should be enough for interaction between games on two or more consoles.
Perhaps the initial connection will be via IrDA, which typically goes up to 115 Kbps but can be faster - not sure if any phones implement the fast version.
GPRS (Generalised Packet Radio Service) is based on TDMA (time division multiple access) mobile phone standards such as GSM (whole world and some parts of North America) and the North American digital one whose name I forget (IS-136?). It's just a software upgrade to most base stations and expected by end of this year in Europe (although BT has just announced a business only service starting this month in the UK).
For more info on GPRS, see http://www.mobilegprs.com/ - sibling sites also have good info on EDGE, 3G/UMTS, WAP, and other horrible mobile phone acronyms...
Search dejanews.com for 'cisco lab' or similar, in news:comp.dcom.sys.cisco - this is a frequent question.
You can rent time on Internet-accessible router labs - not cheap, but may be OK in the short term. Alternatively, maybe you could club together with some other people learning about Cisco and buy a basic lab for use over the Internet by club members?
A few second hand 2500s between 10 people would not be too bad, as long as the hosting club member had always-on Internet access and a Linux box (from which to telnet into routers and run other tools). Comp.dcom.sys.cisco has quite a few of these for sale - just make sure they have enough RAM and flash to run interesting versions of IOS 12.0. You can cut the cost by buying low-RAM versions and buying commodity (or even Kingston) memory to upgrade them.
This would probably be quite efficient - it's really the same as 'optimistic concurrency control', in which you read a last-changed timestamp for every object/record just before you do the update, and flag a concurrency issue to the user if this timestamp changed since you read that object/record.
The overhead is an extra piece of state for each article - but since the score for each article is already in the web page, the only real impact is on the CGI script that does the update.
Typing URLs is a pain, true, but being able to create bookmarks to arbitrary sites is essential - particularly if you can beam them from a Palm (I can already beam address book entries between the Nokia and the Palm, why not bookmarks?).
Google's service for WAP is very impressive - combined search engine and HTML to WML gateway.
It may be a dead end, but I find it useful for limited things that I have already bookmarked - e.g. I got the weather forecast for London today as I was walking in to work, and the whole call lasted 18 seconds including connect time, i.e. cost of approx 7 cents US.
Slashdot Mirror
By all means get pedantic, but get accurate as well :)
* S/390 = System/390 = the hardware architecture for current mainframes
* LPAR = hardware partitioning for S/390, can run multiple OSs within these partitions rather as with VM/390.
* OS/390 = Operating System/390 = the OS formerly known as MVS, runs most mainframe sites. Interestingly, it has a complete Unix API built in (not a separate mode), albeit in EBCDIC not ASCII.
* VM/390 = Virtual Machine/390 = the virtual machine hypervisor that can run many different OSs at once, including OS/390, CMS (single user OS, runs in a whole VM dedicated to one user, quite nice to use), and of coures Linux.
OK, that's enough pedantry... I'm not a real mainframe person, I just used to run Unix on an Amdahl mainframe once.
You mean SCO 'owns a controlling interest' in The Open Group? I'd be astonished if this were true - the Open Group is an industry consortium, and no single vendor would be allowed to 'own' it, let alone dominate it.
The Open Group owns the Unix brandname, i.e. if you pass its conformance tests you get to call your product Unix.
This is exactly right - my employer uses it to port an expensive low-volume piece of software to Solaris and maybe Linux in the future. Though we use our own portability layer for other bits of software that are deployed on more than 5 or so hosts per customer...
Paul Thurrott et al need to learn to RTFW - it's obvious from Mainsoft's site that it is largely a product company, and the version number of MainWin is 3.x, so it's been around for a while, long before this rumour. In fact the Linux version of MainWin is relatively recent.
Note that 'less than 100 grams' could mean '1 gram', but I admit their stats are a bit weird...
Mainsoft's MainWin is not dissimilar to Wine, except that it is very comprehensive since it is based on Windows NT source code. Mainsoft is using MainWin to port IE and WMP, of course - the same tool was already used for the IE ports to Solaris etc.
That doesn't mean it will be a great looking port, but it will work without having to re-write or extend Wine.
There's an article in IEEE Computer magazine this month, about PicoRadio, a project that's intended to build pervasive ad hoc networks from small wireless nodes.
/
These 'PicoNodes' are less than 1 cubic centimetre, weigh less than 100 grams (less than most cell phones), consume less than 100 microwatts (vs. 100 milliwatts for Bluetooth). They should even be able to scavenge energy from the environment, including vibrations from people walking by...
This project relies on reconfigurable hardware, amongst other techniques, for very low power consumption. More info, including the article, is available online at the project's home page, http://bwrc.eecs.berkeley.edu/Research/Pico_Radio
BSD is not 'derived from System V' - it forked off from Unix earlier, maybe version 7 Unix.
Also, Solaris 2.x is based on SVR4 (System V Release 4) - SVR4 is quite upward compatible with SVR3.x.
And Solaris is not spelt with a 'u'...
Linux was not 'built on Posix' (not a meaningful term, Posix is an API spec) but I believe Linus tried quite hard to conform to the 1003.1 specs, and the bash people have tried to conform to the POSIX shell specs.
This is known as reverse path filtering - Linux 2.2 and Cisco IOS with CEF (Cisco Express Forwarding) have this. On suitable Cisco routers the overhead of RPF is minimal, due to the way CEF works. However, it doesn't work with multi-homed customers, amongst other cases.
I'm a QoS specialist at a vendor of policy-based QoS management software - trust me, nobody is going to migrate to IPv6 for QoS purposes.
IPv6 has precisely one extra feature for QoS beyond IPv4 - the flow label, which helps reduce classification load in core routers in RSVP networks. This is a rather unlikely scenario, for details see the RSVP over DiffServ drafts at http://www.ietf.org, in the issll group.
Apart from this one feature, all standard QOS features such as DiffServ, RSVP, COPS, COPS-PR, etc, will work identically in IPv4 and IPv6. The sole speed advantage of IPv6 is its more regular header structure; its disadvantage is that more memory references will be needed for each forwarding and classification decision, so there'll need to be good ASIC or network processor support (as in Intel's IXA architecture) before IPv6 can really take off. However, I expect IPv6 to happen within 2-5 years.
IMO people will migrate to IPv6 to support mobile IP efficiently (its routing header lets you efficiently route to mobile nodes without risking source address spoofing), huge user populations (think millions of mobile phones, tablets, cable modem/ADSL users, etc), and for ease of re-addressing (think companies that are merging or divesting business units).
802.11b is a completely different technology to Bluetooth, with much greater range, about 10 times the bandwidth, and greater power consumption. Not at all comparable to Bluetooth.
One big reason for multicast not catching on is the ability for a single multicast sender to cause congestion at many different points of a network, along with the problems of multicast network management. Until multicast becomes manageable its adoption will be quite slow. A useful paper on this is ata naging.htm
b .htm
e -sgm-00.txt
http://www.winsock2.com/multicast/whitepapers/m
There's some interesting work on fixing this, though - I forget the details but a recent IEEE Networking magazine had a special issue on multicast including info on why it's not been deployed yet.
Also, for small groups, there is a new protocol called SGM that runs over unicast UDP and unicast routing - the idea is that if you want to multicast to a group of 5-10 or so people, and there's a large number of such groups, you're better off forgetting about IGMP and multicast routing, and just including the list of recipients in the packet. Very neat, though it still requires router support. Some URLs on this:
http://www.computer.org/internet/v4n3/w3onwire-
http://www.ietf.org/internet-drafts/draft-boivi
http://icairsvr.nwu.icair.org/sgm/
Do you have references on the reliable unicast protocols being worked on for IPv6 and Linux?
There are many reliable multicast protocols around, some of which at least should work for reliable unicast as well, e.g. RAMP (
http://www.metavr.com/rampDIS.html). See http://www.faqs.org/rfcs/rfc2357.html for criteria for reliable multicast protocols, has some good references.
There is also T/TCP, a variant of TCP which is intended for request/reply transactions - it lets you send data with the initial SYN request and get data back with the ACK, so it's not much less efficient than UDP-based protocols. It would be ideal for HTTP/1.0 but has not really been deployed much.
RADIUS uses its own reliable unicast approach over UDP, and is widely deployed, but it's not a separate re-usable protocol. See www.faqs.org for details.
Some problems with reliable unicast are:
- congestion control - there's no congestion window so it's very easy to overload router buffers and/or receiving host buffers, leading to excessive packet loss for the sender and for other network users
- spoofing - it's even easier to spoof these protocols than with TCP (I think this is why T/TCP never took off)
As for BXXP - I agree about difficulty of understanding what's going on. QoS-aware networks and firewalls all prefer one application mapping to one (static) port.
Firewalls are there for a reason - if you tunnel other protocols over HTTP, you are bypassing the firewall and had better have a very good reason for doing so. Lots of vendors do this, including Microsoft with DCOM and many CORBA vendors as well, but that's not much of an excuse.
Firewall-hostile is a better term for protocols that carry many different types of data.
As a QoS weenie (see http://www.qosforum.com/) I also don't like the way that HTTP can carry many different types of data requiring different QoS (performance) levels, e.g.:
- DCOM over HTTP: needs fairly low latency
- CGI transactions: ditto
- RealAudio over HTTP: needs low loss, consistent bandwidth
- static pages and images: no particular QoS needed
The only way to handle this is to classify every type of HTTP interaction separately, using URLs to map packets into Gold, Silver, and Bronze QoS levels. This is feasible but fragile - as soon as the web-based app or website is updated, you may have to re-write these rules.
Even worse, HTTP/1.1 puts all interactions with a given host into a single TCP session (a good idea in many ways), which makes it a waste of time to prioritise some packets ahead of others - the receiving TCP implementation simply waits until the out of order packets arrive, sending a duplicate ACK in the meantime. Severe packet re-ordering may even lead to slow start in the sending TCP (three duplicate ACKs means slow start from a single packet window size).
Similar issues apply to security - you might want to encrypt only the transaction data and not bother encrypting images, for example, or route some data via a more secure network. SSL does solve some of these problems but requires application support.
Oh well, enough ranting - HTTP is a great protocol in many ways, but there are costs as well as benefits to abusing it to do things it was never meant to do...
Thanks for the pointer, but Intermute is not open source, and it's also a bit dodgy in that it appears to send extra info to the vendor's Internet site on occasion (allegedly).
If you are using IE4 or IE5, you can set per-zone security attributes, e.g. allow Javascript for certain sites that you know are OK, but disallow for other sites.
What would be useful is if someone did a Junkbuster clone or enhancement (see http://www.junkbuster.com, it's a proxy server that just filters ads currently) that could also edit out selected Javascript (e.g. the on-close event).
Ideally this could be done based on whether a site was trusted - e.g. nicesite.com could be allowed to do cleanup stuff in its on-close event, but an unknown & untrusted site would simply not get that event in the Javascript it actually ran.
Does anyone know of an open source tool that does this?
The Word feature to turn off is Fast Saves - this means that when you save a new version on top of the file (e.g. having deleted agents' names), Word simply adds the changed data to the end, to speed things up, rather than rewriting the whole file. So if you ever send a Fast Saved file to someone else electronically, you can be fairly sure to leak some information.
Even though I'm a Palm user, I don't much like the idea of inputting URLs, name & address, or credit card details through a stylus.
The simplest solution is voice input, though that would probably consume far too much power, and may not be ideal in a living room shared with other people. More complex solutions might work, e.g. the TV has an 802.11b or Bluetooth link, or even IrDA, and beams URLs of current programmes and adverts to all and sundry. Of course, there are some security issues - if you are watching the porn channel, Bluetooth would beam the hot URLs everywhere, including outside your house... Encryption might be a good idea here, which 802.11b has, though it's far too expensive for a mass market TV.
The TV industry is looking at broadcasting URLs and small amounts of data alongside the video signal, so that is taken care of, though I don't know the details.
Having redundant links into the Net is certainly one way of handling DDoS, and is in fact already practiced (more for general resilience and performance, but it works well against DDoS) - see http://www.dn.net/technology/network.html for an example of how DigitalNation, a dedicated server hosting company, has tens of links to various ISPs.
This will only work against DDoS if the new routes (i.e. via un-DDOSed links) are advertised out quickly enough - first of all, the IDS needs to detect the DDoS, then it needs to mark the links under attack as down, so that the routing protocol (which has to be BGP as you are interfacing to multiple ISPs), can advertise the new routes.
These routes then have to propagate out throughout the Net, across multiple ISPs, via BGP, until they reach the ISPs of (non-attackers) who are trying to reach your site - these ISPs' routers will then start sending packets via the new routes. The tough part is making sure the route advertisements don't reach the DDoSing hosts - if they do, you have just moved the DDoS attacks onto a new link!
The IDS actually has to analyse the origin of the DDoS attacks (which may mean cooperating with upstream ISPs, since the source addresses will be forged if the attackers have any sense), working out which ISP is hosting the attacking hosts, and then make sure that the route advertisements don't get sent to that ISP. While BGP is very powerful, I'm not sure if it can do this - ask a BGP guru... In any case, if the DDoS attackers are smart enough to subvert hosts in tens of major ISPs, there is no way you can use this 'change route' approach to combat them, without cutting off many legitimate users of your site who are also getting on the Net via those ISPs.
Before DDoS, this approach would have worked, i.e. where there was a single host attacking you - but it's now not sophisticated enough. It may still help in some DDoS attacks, it just depends on luck and the skill of the attackers.
Combatting DDoS is a fundamentally hard problem. The best single mechanism to reduce DDoSes and make them easier to track is RFC 2267 (see www.faqs.org for a copy), which prevents people from injecting packets with forged source addresses (actually they can forge their host address but can't claim to be from a different network). This makes it much easier to directly contact the ISP whose customer or web hosts have been compromised and get them to put in filters blocking the attack.
Without source address spoofing prevention, you have to have a laborious process of going from network operations centre (NOC) to NOC for each ISP back up the chain, getting them to put on traffic analysis tools to see where the traffic is coming from.
Whoops... I've never used a cable to connect my Palm to a mobile phone, so I'm anti-cable I suppose. Maybe IrDA is not common in Japanese handsets.
:)
As soon as you have more than two devices, cabling becomes a nightmare - I have a laptop, Palm device and mobile phone, so adding a mobile Playstation would mean as many as four cables.
GPRS and other mobile phone standards would work with a cable, since they go from the mobile to the base station - typically you would run IP over the cable protocol, then the phone routes this out the other side on top of GPRS or whatever. Yes, your mobile phone is now a real IP router
It's not just a matter of deregulation - in the UK, there has been competition in the mobile phone market since it started (Cellnet and Vodafone, then after a few years, one2one and Orange), yet we use a single international standard (GSM) operating on 2 frequencies.
The result is that I can take my dual-band phone to almost any country in the world (except Japan, US, Canada, Mexico and some South American countries) and have it work seamlessly. I can even do short messages (similar to text paging) and data calls (e.g. sending email from my Palm device) from abroad.
I'm not sure why this didn't happen in the US - perhaps the vendors thought the market was big enough for them to go with proprietary standards (e.g. D-AMPS, CDMA) as well as GSM. In the US, GSM is available from Omnipoint and some others, operates on a 3rd frequency, 1900 MHz, but you can get tri-band phones that work on all 3 global GSM frequencies).
Just as with most technologies, standards are a Good Thing...
Looks like an interesting gizmo, particularly if it supports mobile phones with Bluetooth (gives you a few Mbps to the phone) and GPRS (always-on packet-switched connection, designed for IP and not charged by the minute). Even though GPRS will only go at 25-56 Kbps typically, it should be enough for interaction between games on two or more consoles.
Perhaps the initial connection will be via IrDA, which typically goes up to 115 Kbps but can be faster - not sure if any phones implement the fast version.
GPRS (Generalised Packet Radio Service) is based on TDMA (time division multiple access) mobile phone standards such as GSM (whole world and some parts of North America) and the North American digital one whose name I forget (IS-136?). It's just a software upgrade to most base stations and expected by end of this year in Europe (although BT has just announced a business only service starting this month in the UK).
For more info on GPRS, see http://www.mobilegprs.com/ - sibling sites also have good info on EDGE, 3G/UMTS, WAP, and other horrible mobile phone acronyms...
Search dejanews.com for 'cisco lab' or similar, in news:comp.dcom.sys.cisco - this is a frequent question.
You can rent time on Internet-accessible router labs - not cheap, but may be OK in the short term. Alternatively, maybe you could club together with some other people learning about Cisco and buy a basic lab for use over the Internet by club members?
A few second hand 2500s between 10 people would not be too bad, as long as the hosting club member had always-on Internet access and a Linux box (from which to telnet into routers and run other tools). Comp.dcom.sys.cisco has quite a few of these for sale - just make sure they have enough RAM and flash to run interesting versions of IOS 12.0. You can cut the cost by buying low-RAM versions and buying commodity (or even Kingston) memory to upgrade them.
This would probably be quite efficient - it's really the same as 'optimistic concurrency control', in which you read a last-changed timestamp for every object/record just before you do the update, and flag a concurrency issue to the user if this timestamp changed since you read that object/record.
The overhead is an extra piece of state for each article - but since the score for each article is already in the web page, the only real impact is on the CGI script that does the update.
Typing URLs is a pain, true, but being able to create bookmarks to arbitrary sites is essential - particularly if you can beam them from a Palm (I can already beam address book entries between the Nokia and the Palm, why not bookmarks?).
Google's service for WAP is very impressive - combined search engine and HTML to WML gateway.
It may be a dead end, but I find it useful for limited things that I have already bookmarked - e.g. I got the weather forecast for London today as I was walking in to work, and the whole call lasted 18 seconds including connect time, i.e. cost of approx 7 cents US.