My goal with this blog

I write about relevant changes in the way that people use the web and how startups are built to provide services and products for this ever changing wonderful thing we still know as "the web." As a former entrepreneur turned early-stage investor, my greatest hope is for this to be useful to other folks that are like me in the hopes that they can avoid some of the mistakes I've made.

From:
Antonio Rodriguez

Lazy web telco

tech
by Antonio on

I love my 802.11g wireless card. Wifi has been one of those things that has just transformed the use profile of laptops all over the world. A connected computer is a productive computer plain and simple.

Every week I ride the Acela (Amtrak's northeast corridor high speed train). Sometimes, for kicks, I do the entire ride with MacStumbler open listening for open access points all the way between Boston and New York. I've picked up as many as 42 different access points in the 220 mile ride. Wouldn't it be neat if I could borrow little chunks of bandwidth all the way down and thus remain connected-- albeit in a very bursty way.

The problem is that when the Acela is doing it's job, my little wifi radio is a 70-100MPH moving target. So assuming that I am not just picking up stray beacon frames with MacStumbler and in fact I have a signal that is strong enough to connect to, I still don't have enough time to do the requisite DHCP negotiation (assuming most of these networks are running something like a Linksys router) and create and end-to-end TCP connection, nevermind having a full HTTP or SMTP dialog.

So here is my question/lazy web request: would it be possible to write an app that was sort of a MacStumbler/NetStumbler on steroids that would queue up network requests for when a strong enough signal is picked up for association between the client radio and the AP's radio. Then (and this is where the hand-waving starts due to my poor knowledge of 802.11 specifics as well as any non TCP IP-based stuff), the app could send any waiting TCP traffic as a burst of UDP packets to a specific server on the Internet. The server could reassemble the TCP dialog and make the connection to the actual endpoint. It would hold the conversation on behalf of the semi-connected client.

Now here is the part I haven't quite figured out: how do you send communication back to the bursty client? You can't presumably do the same UDP-to-TCP in reverse because the client is not addressable. Or can you? I haven't read up on it but this new NAT-traversal (or port-knocking) thing that all of the p2p apps do looks very promising as a way to do this. The question is: do you need an IP address on the client? Because if you do, I'd bet the negotiation between the client and the server (DHCP) would make the approach not work (though you'd have to work the numbers out).

If this could be made to work, I would be a very happy customer of the app-- even if the quality of the connection was flakey at best. Right now I pay out the teeth ($80/month) for a Verizon EvDO card that goes into my PCMCIA slot, radiates the hell out of my knee while sucking my battery down as though I had shorted it, and still doesn't really work that well. It claims to seamlessly switch between EvDO and 1xRTT which it does to some degree but it is nowhere near as reliable as my Bluetooth phone over its own antiquated 1xRTT connection.

So that is my lazy web request for today: an app that uses the software to make the people's infrastructure better than what the carriers can provide. After all, software can do everything, no?