Phones that can access normal websites would be nice, but how useful would they be? My Palm IIIx has a web browser and native IP, but unless the sites have been reformatted for PDA use, they are basically unusable - too much horizontal+vertical scrolling. So in practice, reformatting/filtering gateways are essential.
UK WAP pricing is not too bad - 5 pence (= 7.5 US cents) per minute from Orange, and that's after you've exhausted the bundled minutes that month. However, it's very easy to end up with 10 minute calls, largely due to the crap text input via the keypad - I really want to see stylus input with Palm's Graffiti or something very similar.
In fact, the Palm format may win in the end - just use a Bluetooth-connected earpiece, and maybe voice-activated dialling, and you can use any PDA format you like, since you'll normally just use the earpiece, with your PDA/phone in your pocket or bag. This would address the large screen issue as well as text input - my Palm screen is much more usable for WAP browsing, and I can enter a URL much quicker than on my Nokia 7110 WAP phone.
I find many WAP sites don't work with the 7110, maybe 20 per cent or so - it's not a well defined/implemented standard at present.
Actually they are not just my pet theories:) Every maker of VoIP-capable routers will use something along the lines of DiffServ.
Searching on google.com for linux diffserv and ISSLOW provides reasonable links, btw - the actual links of interest are http://lrcwww.epfl.ch/linux-diffserv/, and for ISSLOW, http://www.ietf.org/rfc/rfc2688.txt and http://www.ietf.org/html.charters/issll-charter.ht ml.
The Carmack contribution is on slashdot.org, search for carmack and modem. Or see www.linmodems.org and http://directory.google.com/Top/Computers/Software /Operating_Systems/Linux/Hardware_Suppor t/Modems/
For general info on QoS and links to DiffServ info, see www.qosforum.com.
Actually fair queuing is only one DiffServ PHB (per hop behavior, i.e. queuing technique basically) - DiffServ is an architecture that specifies where and how traffic should be classified, marked, shaped, metered, shaped and queued/dropped. FQ is only one technique in the diffserv toolkit, and is currently not being standardised within DiffServ. Diffserv also standardises the format and meaning of the TOS byte, and defines some standard codepoints (e.g. EF for low latency, low loss).
FQ algorithms are quite nice, since you can reduce latency without just allocating extra bandwidth to a class/flow, but they are relatively costly to implement on routers, which may be why Cisco implements only a class-based form of FQ within its higher end routers. Although Juniper seems to do more granular stuff... I tend to focus on algorithms that have been implemented and turned on in widely deployed routers (since I work for a policy-based network management company, Orchestream), but there's a lot of research out there, as you point out. Implemented mechanisms tend to be quite simplistic, e.g. PQ-CBWFQ from Cisco is a bandwidth limited priority queue layered on top of a class-based weighted fair queuing setup (the PQ carries VoIP typically).
Linux's diffserv effort is really just a layer on top of the quite impressive set of queuing mechanisms built into the 2.2 kernel. Probably at least as complete as KAME, and able to support RSVP as well as DiffServ apps.
As for modems - you are right about the buffering problem, which is why Carmack et al are looking at how you write a mostly-software modem that can be loaded into the Linux kernel in order to (a) reduce overall latency vs hard modems and (b) allow priority or fair queuing perhaps.
Whatever mechanisms you introduce are protocol transparent typically - PQ, WFQ, WRED, HFSC, etc all simply re-order, delay or drop packets. They introduce extra complexity into the host and router IP stacks, but are normally at the interface queue level.
Apps don't necessarily have to be changed to support DiffServ - just use appropriate linux/BSD commands to classify the appropriate traffic. RSVP does provide more functionality but normally requires the app to be changed somewhat. I don't know specific linux apps that support RSVP, I would guess only the ones that were used when originally testing the RSVP stac (vic and vat??).
Nice idea, as long as local calls are free of charge - currently true in most of US, but certainly not in Europe (though some countries may have extra-cost packages for unmetered local calls).
I'd like to see such gateways for deaf people, calling out or in at 300 baud to/from textphones using old, cheap modems - the idea is to network deaf people (who use textphones a lot - think keyboard plus very old modem in one package) into the huge world of Internet instant messaging (and maybe WAP and SMS messaging for mobile phones).
As for VoIP - check out the Linux-DiffServ project, its EF (Expedited Forwarding) per-hop behaviour (jargon for a special packet queuing mechanism) is very good at doing VoIP, which needs very low latency and fairly low loss. In other words, your Linux router/firewall, or even desktop, should always send a VoIP (EF marked) packet first, even if other packets are also queued.
The other thing needed is link-level packet fragmentation - Cisco call this LFI, which is proprietary, while the IETF calls it ISSLOW - the idea is that your large (1500 byte) FTP packet should be 'preemptible', i.e. it is actually sent as many small layer 2 fragments (not IP fragments), so the VoIP packet (probably only one layer 2 fragment) can sneak in very quickly after the current short FTP fragment. Compressed RTP headers a la Cisco would be very useful - cuts down IP/UDP/RTP headers to about 2-3 bytes. These tricks are most relevant to low speed lines (modems now, mobile phones in the medium term) However, both of these tricks require your ISP to cooperate, so not so useful for Gnuphonella.
For one major possible latency improvement, see the John Carmack posting a while back about low-latency Linmodem drivers - these will also be important for VoIP without special hardware.
Currently ATM to the customer site has some advantages, but IP QoS and MPLS (for provisioning the equivalent of virtual circuits in the core) may well eat its lunch. But I'm probably biased...
Most large customers have a lot of IP traffic, and are migrating other protocols to IP, so it's increasingly important to be able to be able to manage IP application traffic.
Can you point me towards ISPs that do allow servers over BT ADSL service? I thought the ADSL modem was part of the BT ADSL service resold to ISPs - are you saying they can use their own kit?
Also - the ADSL service from BT has a network-based NAT (not a big surprise given the vast potential user base and the scarcity of IPv4 address space).
Although I really wish BT didn't have such annoying restrictions, it's possible that the lack of IPv4 address space is a solid technical reason for the use of NAT. Unless the whole world goes IPv6 it's hard to see any major provider deploying ADSL, cable or mobile Internet to millions of users without doing NAT.
CAIS Internet does ADSL-based services to hotels, and allocates a 10.x address to clients using DHCP - clearly there is a NAT there somewhere, but since it is static NAT (i.e. you get a whole IP address for your host, not just a few port numbers on a shared address space) it should be quite usable when combined with a dynamic DNS service such as TZO's (www.tzo.com, has clients for almost every OS and is quite reliable).
I think a static NAT based service is a reasonable way of providing a near transparent ADSL service - it economises on IPv4 address usage, but still allows active hosts to keep hold of their DHCP leases for long enough that their IPv4 addresses don't change too frequently.
I just want vanilla IP service as well - however I have little choice if I want something priced at approx 40 UKP/month. The business service is 100 UKP/month and has a non-waivable installation charge of 260 UKP (Q: does this include ownership of the router + ADSL modem, or just installation of the line + kit?).
So, until local loop unbundling in July next year, I will have to live with the annoying BT 'outgoing only' service model. It's a pain, but still a lot faster than dialup access, so I can probably manage for a year or so.
I wonder what would happen if an enterprising ISP or hosting provider set up some sort of tunnelling server - i.e. allowing servers at home to be accessible via tunnel endpoints located outside the BT firewall, using something like GRE or L2TP to tunnel from home to the tunnel server... Probably BT would get upset at this, but technically it would be quite straightforward - just make sure the home system 'calls out' to establish the tunnel, then from that point it's just ordinary traffic, with any TCP SYNs inbound to servers at home nicely hidden within the tunnel.
For extra geek points, this could use HTTP as the tunnel mechanism (as in the various 'bypass your firewall' tools), for increased undetectability, or even IPSec, for increased security against monitoring. Something UDP or raw IP based would be best for performance of non-TCP apps, though.
Yes, it's a pain not having servers, but with always-on and a *nix box, it's relatively easy to poll your ISP mailbox every minute or so, which is not bad. The money I save on phone bill costs (easily 100 - 200 pounds a quarter) will pay for an inexpensive hosting provider (probably US-based because they are very competitive there).
Not at all ideal, and I wish they'd lose the server restrictions.
The installation fee is waved if you go for the USB-based service and pre-order before the June launch.
My biggest problem is not having any Linux support for the USB+PPPoE+other stuff - I may have to revive a Windows box just for this and use it as a router or something, at least until the Linux community comes up with some solution.
Good question - USB is no more widely used here than in the US, if anything it is less used since PCs are still a bit more expensive here, so more people are using pre-USB models.
I think they went USB in order to prevent businesses from just using NAT (now very easy to get hold of, even on Windows) and connecting a number of PCs (or even a medium size site - many companies still use 128K leased lines, so ADSL would be better even with these rate limits...).
I bought a German free-Unix mag the other day (I think it's called Free-X) because it had a cover CD with OpenBSD 2.6, costing only a few dollars/Euros. I don't have a URL, maybe someone else can supply one?
A lot cheaper than shelling out for the full OpenBSD CD and a lot easier than finding a spare 650 MB on my laptop so I can download it at work. Unfortunately the CheapBytes OpenBSD CD can't be exported for some reason - probably not necessary, now that the US has relaxed its crypto export laws.
It's a shame that OpenBSD relies so much on CD sales to fund the project - I bought a 2.5 CD a while back but buying a new CD every few months seems a bit excessive considering I'm only using it at home.
There's a huge need for this sort of software, and I'd be happy to talk through design and requirements issues - I'm a bit short of time but could probably do some Perl prototyping.
I think there are a few requirements/design issues to be thought about:
- how to encode which mirror sites are available - XML encoding within a normal web page seems to be an obvious way to go, so that the same page can be human readable as well as making sense to the software.
- how automatic should this be? Sometimes highly automated systems are a pain (e.g. Perl's CPAN always used to redirect me to demon.co.uk, which was hugely overloaded - fortunately they provided a manual override).
- how can different types of client software or proxy software make use of this sort of 'mirror list' information? XML is probably the best common approach since modern browsers support this, making it possible perhaps to do it all in JavaScript, and there are many XML development tools available.
It would be great as a first step if the user could be shown a 'choose a mirror' page when going to a popular website such as samba.org, freebsd.org.
Then, the next step is to estimate closeness in some way (either statically, e.g. country TLD, or dynamically through measurements, e.g. ping times). The closer this is done to the client, the better, but moving this closer to the core of the network will avoid redundant measurement traffic.
Finally, the client (whether a browser, FTP client, or proxy cache) needs to use the closeness metric to automatically (or with confirmation if it's an interactive client) to choose a site and attempt to download the file.
Unfortunately the download will often fail (e.g. ftp site won't accept new logins, or the download takes too long). It's important that the system can notice this fact and switch to another mirror.
One interesting issue is working out which are the closest sites - should you use geography (same top-level country domain), topology (number of router hops or equivalent), latency (ping times), path bandwidth (using pchar/pathchar to work out slowest link), server load, or some combination?
There is some prior art in this area - distributed load balancing devices (e.g. Cisco's Distributed Director, and I think also RADware) do something quite similar. These types of tool use routing protocols and/or ping measurements to the local host (or whatever DNS server serves the client hostname) in order to work out the closest client to each server (using BGP in the Cisco product, which may not be very useful), or dynamic measurements in RADware (controversial because the client-local DNS server may view this as an intrusion attempt!).
There are also many client-side software tools that attempt to do this - e.g. GetRight for Windows, which pings a list of hosts and downloads from one of them.
Some proxy networks, e.g. Akamai, probably do something similar, though they are much more tightly integrated than this could be.
I think the best place to start would be defining a mirror-description language in XML, including optional 'closeness metric' attributes for future use; then develop a simple client in your tool of choice, maybe Perl or Python, for use in manually finding the best mirror to use (e.g. using country codes or similar); then try to integrate this into browsers and/or proxy caches.
I thought about this stuff a while back and sent an Ask Slashdot submission but it didn't get posted. Back then I was thinking in terms of using web proxy software plus some addon modules (maybe Apache + mod_rewrite + custom module, with web caching as an option for even faster downloads).
If the phone system is up to it, you can use ISP roaming - you get an account with iPass or GRIC, then you use their (Windows) dialler software to automatically use the closest ISP on their roaming programme.
They do cover Nepal, Thailand and India, though phone line quality may be enough of a problem that an Internet cafe is a better option. Details at http://www.ipass.com/accesspoints/ and http://www.gric.com/zone/isplocator/. The downside is that you pay by the hour typically on top of phone charges, but it's cheaper than an international call.
There are some payphone-like Internet terminals in the UK, from BT - unfortunately they are touch screen only so basically useless except for clicking through a selection of sites... Sad but true.
I use the Logitech Cordless Mouseman Wheel mouse, which is very nice, and can be used in left or right hand. I set it up as Intellimouse-Serial under XFree86. It's very nice to have one less wire trailing around.
The VPN book by O'Reilly, http://www.amazon.com/exec/obidos/ASIN/1565925297/ , is really quite mediocre - while some of the conceptual discussion is OK, it fails to cover IPSec properly (which is now the industry standard for crypto based VPNs) and is not a patch on Dan Harkin's IPSec book.
I do generally like O'Reilly books, but this is full of errors and fails to address the most important issues.
I agree about cheaper looking bags - I try to carry laptops in a non-standard laptop back (e.g. a backpack with no logos, and sometimes one that looks quite beaten up. I also put power supplies etc in my main bag, which also looks quite old and valueless and is never locked.
This helps with customs agents and with baggage theft at the airport - if your checked baggage looks like it belongs to a student, it's unlikely to get stolen from. (The only time I had things stolen from a bag was in a hotel in China.)
Online backups of your laptop data are a great idea - consider NetStore and similar if you use Windows, or an ftp site plus pgp if you don't. Makes a big difference to how quickly you can get going again.
A GSM phone is probably a good overall solution to check email; I use a double band (900 and 1800, works in most countries except US and Japan) Ericsson SH888 - sent email from my Palm III in a Hamburg cafe this weekend for extra geek points:)
I also sometimes carry an acoustic coupler - these go up to 28,800 bps now and are good when you have a hotel phone wired into the wall, quite common outside the US. Also, take some telephone socket doublers (US models) as sometimes you can use these to get a connection from the phone end of the wire. Check www.teleadapt.com for lots of road warrior kit, but buy it somewhere else as they are very expensive.
If you have to plug into wired phone sockets, you'll need a panoply of different phone adapters - though some hotels just use US plugs, the cheaper/older ones probably won't. Teleadapt shows you what you'll need.
ISP roaming is a big hassle - if you use GSM this is not an issue as you just call home (go GSM if you can afford it, or go wired if you need more online time). GRIC and iPass do roaming services that are probably well worth the hassle avoidance - you use a single Windows dialler that knows how to talk to all ISPs on the scheme. If you want a single ISP, try IBM Global Network (now bought by AT&T, www.ibm.net), who are good quality and have good coverage - I use them for work travel, but I'm not sure about non-Windows support.
http://www.whatis.com/modem.htm disagrees with you - DSL modems are sometimes called by an obscure TLA, but since they take digital in on one side (i.e. ethernet or USB) and put analogue out on the other side (taking care not to disturb the analogue voice channel), it seems to me that 'DSL modem' is a fair term. Nortel' Shasta division make DSLAMs and agree too.
The whole modem / non-modem distinction is somewhat arbitrary - after all, ultimately every digital networking device has to put signals on a wire or fibre, and those signals are ultimately analogue. The only difference is whether there is a simple encoding or a complex encoding, and whether there is an analogue-only mode for that channel, or if the link is expected to always interpret these analogue signals as digital.
Let's just agree that small devices that connect you to phone-like wires are called modems (unless they're called ISDN TAs : )
Win2000 already broke IrDA usage - the IrCOMM protocol (basically telnet-equivalent over IrDA) doesn't work at all, allegedly because of difficulties with serial port locking. Strange that Unix has managed to do serial port locking for 30 or so years.
IrCOMM is used by anyone wanting to talk to their GSM mobile phone's built-in modem, e.g. if you want your nice new Win2000 laptop to talk to the Internet.
Actually Windows CE is (and always has been) 'new rope' - the only thing it shares with Windows on PCs is the Win32 API, and in fact it uses a subset of the full API.
WinCE is not going to get much embedded market share IMO until it gets more reliable.
Palm does need to get its act together on extras - most of the Pocket PC bundled features are available as addons (e.g. the TRG Pro is a Palm clone that has a CompactFlash slot, so it can support the IBM Microdrive I guess), but adding them all is a pain for someone who wants a simple tool.
I think there is a market for high-end work+leisure PDAs - i.e. including MP3 player, good colour graphics for photos grabbed from digital cameras, good reader software, etc (by the way, see http://www.grc.com/ for details on the lack of innovation in Microsoft's ClearType technology for clearer text on colour LCDs - used in Apple II if not earlier).
I'd like to see a better OS: perhaps the mobile phone manufacturers, who are all going for Psion's (now Symbian's) EPOC OS, may do this. EPOC is 32 bit, threaded, and so on, and may be a good way of hosting the PalmOS (Nokia is likely to do this according to a story last year) - so you can run the thousands of PalmOS applications and still have the oomph to process voice calls, Internet data exchange, MP3 playing, and maybe even video.
A slight difference is that the PDA has your entire life on it - appointments, contact numbers, and so on - so it's hardly practical to lend it to someone for a week or two while they read the book...
I've had reasonably good results with the Netscape 6 preview release - it has a View | Translate command that sends the URL to www.teletranslator.com and then translates it for you.
Very convenient - you can even navigate the links in the resulting page, and the service will translate the pages automatically.
Have you actually tried looking for IPv6 apps? For example, searching freebsd.org for ipv6 produces http://www.freebsd.org/ports/ipv6.html, which lists Apache, Zebra, and numerous IRC, email and news clients, not to mention GNU Emacs.
Most of these should port easily to Linux, but there's also a Linux IPv6 apps list at http://www.bieringer.de/linux/IPv6/status/IPv6+Lin ux-status-apps.html - elsewhere on that site there are pointers to Polish and Japanese distributions that integrate IPv6 support. Debian and Red Hat have also started IPv6 support work.
I think you've mis-remembered what Vint Cerf said - IPv4 was designed in the mid-70s; before that point, ARPANET was based on the NCP, a sort of combination of TCP and IP in one protocol (e.g. it did reliability at the router level).
The ARPANET grew well beyond 9 nodes even while still running NCP - it had 15 nodes by 1971, according to http://www.rci.rutgers.edu/~jea/papers/2Nets.html - and I'm sure the IPv4 ARPANET had many more than that.
Slashdot Mirror
Phones that can access normal websites would be nice, but how useful would they be? My Palm IIIx has a web browser and native IP, but unless the sites have been reformatted for PDA use, they are basically unusable - too much horizontal+vertical scrolling. So in practice, reformatting/filtering gateways are essential.
UK WAP pricing is not too bad - 5 pence (= 7.5 US cents) per minute from Orange, and that's after you've exhausted the bundled minutes that month. However, it's very easy to end up with 10 minute calls, largely due to the crap text input via the keypad - I really want to see stylus input with Palm's Graffiti or something very similar.
In fact, the Palm format may win in the end - just use a Bluetooth-connected earpiece, and maybe voice-activated dialling, and you can use any PDA format you like, since you'll normally just use the earpiece, with your PDA/phone in your pocket or bag. This would address the large screen issue as well as text input - my Palm screen is much more usable for WAP browsing, and I can enter a URL much quicker than on my Nokia 7110 WAP phone.
I find many WAP sites don't work with the 7110, maybe 20 per cent or so - it's not a well defined/implemented standard at present.
Actually they are not just my pet theories :) Every maker of VoIP-capable routers will use something along the lines of DiffServ.
t ml.
e /Operating_Systems/Linux/Hardware_Suppor t/Modems/
Searching on google.com for linux diffserv and ISSLOW provides reasonable links, btw - the actual links of interest are http://lrcwww.epfl.ch/linux-diffserv/, and for ISSLOW, http://www.ietf.org/rfc/rfc2688.txt and http://www.ietf.org/html.charters/issll-charter.h
The Carmack contribution is on slashdot.org, search for carmack and modem. Or see www.linmodems.org and http://directory.google.com/Top/Computers/Softwar
For general info on QoS and links to DiffServ info, see www.qosforum.com.
Actually fair queuing is only one DiffServ PHB (per hop behavior, i.e. queuing technique basically) - DiffServ is an architecture that specifies where and how traffic should be classified, marked, shaped, metered, shaped and queued/dropped. FQ is only one technique in the diffserv toolkit, and is currently not being standardised within DiffServ. Diffserv also standardises the format and meaning of the TOS byte, and defines some standard codepoints (e.g. EF for low latency, low loss).
FQ algorithms are quite nice, since you can reduce latency without just allocating extra bandwidth to a class/flow, but they are relatively costly to implement on routers, which may be why Cisco implements only a class-based form of FQ within its higher end routers. Although Juniper seems to do more granular stuff... I tend to focus on algorithms that have been implemented and turned on in widely deployed routers (since I work for a policy-based network management company, Orchestream), but there's a lot of research out there, as you point out. Implemented mechanisms tend to be quite simplistic, e.g. PQ-CBWFQ from Cisco is a bandwidth limited priority queue layered on top of a class-based weighted fair queuing setup (the PQ carries VoIP typically).
Linux's diffserv effort is really just a layer on top of the quite impressive set of queuing mechanisms built into the 2.2 kernel. Probably at least as complete as KAME, and able to support RSVP as well as DiffServ apps.
As for modems - you are right about the buffering problem, which is why Carmack et al are looking at how you write a mostly-software modem that can be loaded into the Linux kernel in order to (a) reduce overall latency vs hard modems and (b) allow priority or fair queuing perhaps.
Whatever mechanisms you introduce are protocol transparent typically - PQ, WFQ, WRED, HFSC, etc all simply re-order, delay or drop packets. They introduce extra complexity into the host and router IP stacks, but are normally at the interface queue level.
Apps don't necessarily have to be changed to support DiffServ - just use appropriate linux/BSD commands to classify the appropriate traffic. RSVP does provide more functionality but normally requires the app to be changed somewhat. I don't know specific linux apps that support RSVP, I would guess only the ones that were used when originally testing the RSVP stac (vic and vat??).
Nice idea, as long as local calls are free of charge - currently true in most of US, but certainly not in Europe (though some countries may have extra-cost packages for unmetered local calls).
I'd like to see such gateways for deaf people, calling out or in at 300 baud to/from textphones using old, cheap modems - the idea is to network deaf people (who use textphones a lot - think keyboard plus very old modem in one package) into the huge world of Internet instant messaging (and maybe WAP and SMS messaging for mobile phones).
As for VoIP - check out the Linux-DiffServ project, its EF (Expedited Forwarding) per-hop behaviour (jargon for a special packet queuing mechanism) is very good at doing VoIP, which needs very low latency and fairly low loss. In other words, your Linux router/firewall, or even desktop, should always send a VoIP (EF marked) packet first, even if other packets are also queued.
The other thing needed is link-level packet fragmentation - Cisco call this LFI, which is proprietary, while the IETF calls it ISSLOW - the idea is that your large (1500 byte) FTP packet should be 'preemptible', i.e. it is actually sent as many small layer 2 fragments (not IP fragments), so the VoIP packet (probably only one layer 2 fragment) can sneak in very quickly after the current short FTP fragment. Compressed RTP headers a la Cisco would be very useful - cuts down IP/UDP/RTP headers to about 2-3 bytes. These tricks are most relevant to low speed lines (modems now, mobile phones in the medium term) However, both of these tricks require your ISP to cooperate, so not so useful for Gnuphonella.
For one major possible latency improvement, see the John Carmack posting a while back about low-latency Linmodem drivers - these will also be important for VoIP without special hardware.
Currently ATM to the customer site has some advantages, but IP QoS and MPLS (for provisioning the equivalent of virtual circuits in the core) may well eat its lunch. But I'm probably biased...
Most large customers have a lot of IP traffic, and are migrating other protocols to IP, so it's increasingly important to be able to be able to manage IP application traffic.
This is quite a complex problem and is about the kernel not LILO - 2.2.14 was supposed to fix this but doesn't seem to have done on my 34 GB drive.
See Andries Brower's excellent Large Drive HOWTO for full details of this and other problems with larger disks - http://www.linuxdoc.org/.
Can you point me towards ISPs that do allow servers over BT ADSL service? I thought the ADSL modem was part of the BT ADSL service resold to ISPs - are you saying they can use their own kit?
Also - the ADSL service from BT has a network-based NAT (not a big surprise given the vast potential user base and the scarcity of IPv4 address space).
Although I really wish BT didn't have such annoying restrictions, it's possible that the lack of IPv4 address space is a solid technical reason for the use of NAT. Unless the whole world goes IPv6 it's hard to see any major provider deploying ADSL, cable or mobile Internet to millions of users without doing NAT.
CAIS Internet does ADSL-based services to hotels, and allocates a 10.x address to clients using DHCP - clearly there is a NAT there somewhere, but since it is static NAT (i.e. you get a whole IP address for your host, not just a few port numbers on a shared address space) it should be quite usable when combined with a dynamic DNS service such as TZO's (www.tzo.com, has clients for almost every OS and is quite reliable).
I think a static NAT based service is a reasonable way of providing a near transparent ADSL service - it economises on IPv4 address usage, but still allows active hosts to keep hold of their DHCP leases for long enough that their IPv4 addresses don't change too frequently.
I just want vanilla IP service as well - however I have little choice if I want something priced at approx 40 UKP/month. The business service is 100 UKP/month and has a non-waivable installation charge of 260 UKP (Q: does this include ownership of the router + ADSL modem, or just installation of the line + kit?).
So, until local loop unbundling in July next year, I will have to live with the annoying BT 'outgoing only' service model. It's a pain, but still a lot faster than dialup access, so I can probably manage for a year or so.
I wonder what would happen if an enterprising ISP or hosting provider set up some sort of tunnelling server - i.e. allowing servers at home to be accessible via tunnel endpoints located outside the BT firewall, using something like GRE or L2TP to tunnel from home to the tunnel server... Probably BT would get upset at this, but technically it would be quite straightforward - just make sure the home system 'calls out' to establish the tunnel, then from that point it's just ordinary traffic, with any TCP SYNs inbound to servers at home nicely hidden within the tunnel.
For extra geek points, this could use HTTP as the tunnel mechanism (as in the various 'bypass your firewall' tools), for increased undetectability, or even IPSec, for increased security against monitoring. Something UDP or raw IP based would be best for performance of non-TCP apps, though.
Well, it still seems to be on Linux - see http://www.netcraft.com/whats/?host=www.btopenworl d.com
Yes, it's a pain not having servers, but with always-on and a *nix box, it's relatively easy to poll your ISP mailbox every minute or so, which is not bad. The money I save on phone bill costs (easily 100 - 200 pounds a quarter) will pay for an inexpensive hosting provider (probably US-based because they are very competitive there).
Not at all ideal, and I wish they'd lose the server restrictions.
The installation fee is waved if you go for the USB-based service and pre-order before the June launch.
My biggest problem is not having any Linux support for the USB+PPPoE+other stuff - I may have to revive a Windows box just for this and use it as a router or something, at least until the Linux community comes up with some solution.
Good question - USB is no more widely used here than in the US, if anything it is less used since PCs are still a bit more expensive here, so more people are using pre-USB models.
I think they went USB in order to prevent businesses from just using NAT (now very easy to get hold of, even on Windows) and connecting a number of PCs (or even a medium size site - many companies still use 128K leased lines, so ADSL would be better even with these rate limits...).
I bought a German free-Unix mag the other day (I think it's called Free-X) because it had a cover CD with OpenBSD 2.6, costing only a few dollars/Euros. I don't have a URL, maybe someone else can supply one?
A lot cheaper than shelling out for the full OpenBSD CD and a lot easier than finding a spare 650 MB on my laptop so I can download it at work. Unfortunately the CheapBytes OpenBSD CD can't be exported for some reason - probably not necessary, now that the US has relaxed its crypto export laws.
It's a shame that OpenBSD relies so much on CD sales to fund the project - I bought a 2.5 CD a while back but buying a new CD every few months seems a bit excessive considering I'm only using it at home.
There's a huge need for this sort of software, and I'd be happy to talk through design and requirements issues - I'm a bit short of time but could probably do some Perl prototyping.
I think there are a few requirements/design issues to be thought about:
- how to encode which mirror sites are available - XML encoding within a normal web page seems to be an obvious way to go, so that the same page can be human readable as well as making sense to the software.
- how automatic should this be? Sometimes highly automated systems are a pain (e.g. Perl's CPAN always used to redirect me to demon.co.uk, which was hugely overloaded - fortunately they provided a manual override).
- how can different types of client software or proxy software make use of this sort of 'mirror list' information? XML is probably the best common approach since modern browsers support this, making it possible perhaps to do it all in JavaScript, and there are many XML development tools available.
It would be great as a first step if the user could be shown a 'choose a mirror' page when going to a popular website such as samba.org, freebsd.org.
Then, the next step is to estimate closeness in some way (either statically, e.g. country TLD, or dynamically through measurements, e.g. ping times). The closer this is done to the client, the better, but moving this closer to the core of the network will avoid redundant measurement traffic.
Finally, the client (whether a browser, FTP client, or proxy cache) needs to use the closeness metric to automatically (or with confirmation if it's an interactive client) to choose a site and attempt to download the file.
Unfortunately the download will often fail (e.g. ftp site won't accept new logins, or the download takes too long). It's important that the system can notice this fact and switch to another mirror.
One interesting issue is working out which are the closest sites - should you use geography (same top-level country domain), topology (number of router hops or equivalent), latency (ping times), path bandwidth (using pchar/pathchar to work out slowest link), server load, or some combination?
There is some prior art in this area - distributed load balancing devices (e.g. Cisco's Distributed Director, and I think also RADware) do something quite similar. These types of tool use routing protocols and/or ping measurements to the local host (or whatever DNS server serves the client hostname) in order to work out the closest client to each server (using BGP in the Cisco product, which may not be very useful), or dynamic measurements in RADware (controversial because the client-local DNS server may view this as an intrusion attempt!).
There are also many client-side software tools that attempt to do this - e.g. GetRight for Windows, which pings a list of hosts and downloads from one of them.
Some proxy networks, e.g. Akamai, probably do something similar, though they are much more tightly integrated than this could be.
I think the best place to start would be defining a mirror-description language in XML, including optional 'closeness metric' attributes for future use; then develop a simple client in your tool of choice, maybe Perl or Python, for use in manually finding the best mirror to use (e.g. using country codes or similar); then try to integrate this into browsers and/or proxy caches.
I thought about this stuff a while back and sent an Ask Slashdot submission but it didn't get posted. Back then I was thinking in terms of using web proxy software plus some addon modules (maybe Apache + mod_rewrite + custom module, with web caching as an option for even faster downloads).
If the phone system is up to it, you can use ISP roaming - you get an account with iPass or GRIC, then you use their (Windows) dialler software to automatically use the closest ISP on their roaming programme.
They do cover Nepal, Thailand and India, though phone line quality may be enough of a problem that an Internet cafe is a better option. Details at http://www.ipass.com/accesspoints/ and http://www.gric.com/zone/isplocator/. The downside is that you pay by the hour typically on top of phone charges, but it's cheaper than an international call.
There are some payphone-like Internet terminals in the UK, from BT - unfortunately they are touch screen only so basically useless except for clicking through a selection of sites... Sad but true.
I use the Logitech Cordless Mouseman Wheel mouse, which is very nice, and can be used in left or right hand. I set it up as Intellimouse-Serial under XFree86. It's very nice to have one less wire trailing around.
The VPN book by O'Reilly, http://www.amazon.com/exec/obidos/ASIN/1565925297/ , is really quite mediocre - while some of the conceptual discussion is OK, it fails to cover IPSec properly (which is now the industry standard for crypto based VPNs) and is not a patch on Dan Harkin's IPSec book.
I do generally like O'Reilly books, but this is full of errors and fails to address the most important issues.
I agree about cheaper looking bags - I try to carry laptops in a non-standard laptop back (e.g. a backpack with no logos, and sometimes one that looks quite beaten up. I also put power supplies etc in my main bag, which also looks quite old and valueless and is never locked.
:)
This helps with customs agents and with baggage theft at the airport - if your checked baggage looks like it belongs to a student, it's unlikely to get stolen from. (The only time I had things stolen from a bag was in a hotel in China.)
Online backups of your laptop data are a great idea - consider NetStore and similar if you use Windows, or an ftp site plus pgp if you don't. Makes a big difference to how quickly you can get going again.
A GSM phone is probably a good overall solution to check email; I use a double band (900 and 1800, works in most countries except US and Japan) Ericsson SH888 - sent email from my Palm III in a Hamburg cafe this weekend for extra geek points
I also sometimes carry an acoustic coupler - these go up to 28,800 bps now and are good when you have a hotel phone wired into the wall, quite common outside the US. Also, take some telephone socket doublers (US models) as sometimes you can use these to get a connection from the phone end of the wire. Check www.teleadapt.com for lots of road warrior kit, but buy it somewhere else as they are very expensive.
If you have to plug into wired phone sockets, you'll need a panoply of different phone adapters - though some hotels just use US plugs, the cheaper/older ones probably won't. Teleadapt shows you what you'll need.
ISP roaming is a big hassle - if you use GSM this is not an issue as you just call home (go GSM if you can afford it, or go wired if you need more online time). GRIC and iPass do roaming services that are probably well worth the hassle avoidance - you use a single Windows dialler that knows how to talk to all ISPs on the scheme. If you want a single ISP, try IBM Global Network (now bought by AT&T, www.ibm.net), who are good quality and have good coverage - I use them for work travel, but I'm not sure about non-Windows support.
http://www.whatis.com/modem.htm disagrees with you - DSL modems are sometimes called by an obscure TLA, but since they take digital in on one side (i.e. ethernet or USB) and put analogue out on the other side (taking care not to disturb the analogue voice channel), it seems to me that 'DSL modem' is a fair term. Nortel' Shasta division make DSLAMs and agree too.
The whole modem / non-modem distinction is somewhat arbitrary - after all, ultimately every digital networking device has to put signals on a wire or fibre, and those signals are ultimately analogue. The only difference is whether there is a simple encoding or a complex encoding, and whether there is an analogue-only mode for that channel, or if the link is expected to always interpret these analogue signals as digital.
Let's just agree that small devices that connect you to phone-like wires are called modems (unless they're called ISDN TAs : )
Win2000 already broke IrDA usage - the IrCOMM protocol (basically telnet-equivalent over IrDA) doesn't work at all, allegedly because of difficulties with serial port locking. Strange that Unix has managed to do serial port locking for 30 or so years.
IrCOMM is used by anyone wanting to talk to their GSM mobile phone's built-in modem, e.g. if you want your nice new Win2000 laptop to talk to the Internet.
Actually Windows CE is (and always has been) 'new rope' - the only thing it shares with Windows on PCs is the Win32 API, and in fact it uses a subset of the full API.
WinCE is not going to get much embedded market share IMO until it gets more reliable.
Palm does need to get its act together on extras - most of the Pocket PC bundled features are available as addons (e.g. the TRG Pro is a Palm clone that has a CompactFlash slot, so it can support the IBM Microdrive I guess), but adding them all is a pain for someone who wants a simple tool.
I think there is a market for high-end work+leisure PDAs - i.e. including MP3 player, good colour graphics for photos grabbed from digital cameras, good reader software, etc (by the way, see http://www.grc.com/ for details on the lack of innovation in Microsoft's ClearType technology for clearer text on colour LCDs - used in Apple II if not earlier).
I'd like to see a better OS: perhaps the mobile phone manufacturers, who are all going for Psion's (now Symbian's) EPOC OS, may do this. EPOC is 32 bit, threaded, and so on, and may be a good way of hosting the PalmOS (Nokia is likely to do this according to a story last year) - so you can run the thousands of PalmOS applications and still have the oomph to process voice calls, Internet data exchange, MP3 playing, and maybe even video.
A slight difference is that the PDA has your entire life on it - appointments, contact numbers, and so on - so it's hardly practical to lend it to someone for a week or two while they read the book...
I've had reasonably good results with the Netscape 6 preview release - it has a View | Translate command that sends the URL to www.teletranslator.com and then translates it for you.
Very convenient - you can even navigate the links in the resulting page, and the service will translate the pages automatically.
Have you actually tried looking for IPv6 apps? For example, searching freebsd.org for ipv6 produces http://www.freebsd.org/ports/ipv6.html, which lists Apache, Zebra, and numerous IRC, email and news clients, not to mention GNU Emacs.
n ux-status-apps.html - elsewhere on that site there are pointers to Polish and Japanese distributions that integrate IPv6 support. Debian and Red Hat have also started IPv6 support work.
Most of these should port easily to Linux, but there's also a Linux IPv6 apps list at http://www.bieringer.de/linux/IPv6/status/IPv6+Li
Hint: do a web search before posting next time...
I think you've mis-remembered what Vint Cerf said - IPv4 was designed in the mid-70s; before that point, ARPANET was based on the NCP, a sort of combination of TCP and IP in one protocol (e.g. it did reliability at the router level).
The ARPANET grew well beyond 9 nodes even while still running NCP - it had 15 nodes by 1971, according to http://www.rci.rutgers.edu/~jea/papers/2Nets.html - and I'm sure the IPv4 ARPANET had many more than that.