Saturday, August 28, 2010

Two pieces of code someone really ought to write

Gripe mode on:

If you think about it, sockets are the elephant in the unix living room. Everything in unix is supposed to be a file. "Real" files are, of course, files. Remote files are files. Devices are "files". And with the /proc filesystem, even parts of the kernel are files. Everything is a file.

Except sockets.

Sockets aren't files, but they really should be, and it mystifies me that someone hasn't written a FUSE file system that presents sockets as files. It seems like a no-brainer. Instead of having to call socket() and bind() and connect() and fill in sock_addr structures, I should just be able to call open("/fuse/sockets/", "r+") and get a descriptor for a TCP socket to port 80. It should be straightforward to implement this on top of FUSE.

Item the second:

Apache's mod_proxy allows Apache to act as a forwarding proxy to other machines, or even the same machine via a TCP connection, but NOT to a local unix-domain socket.

So suppose that I want to have Apache as my front-end to handle security and serve static content, and I want it to proxy interactive pages to a custom standalone server app. No problem you say, just pick a non-publically-accessible TCP port for the custom app and point mod_proxy to that port for the relevant URLs.

But now suppose that I have a single machine with a single IP address hosting multiple virtual servers, and I want to replicate this setup for each virtual server, i.e. I want each virtual server to have its own instantiation of the custom server application. Now I have to *manually* assign *each* instantiation of the app to a separate TCP port number. If I have hundreds or thousands of virtual servers on the same machine (Oh? You think that's not reasonable? Can you say "multi-core architecture"?) that can become a serious administrative (to say nothing of security) nightmare.

Wouldn't it be better if instead of assigning the custom server app to a TCP port number I could instead assign each one to a unix domain socket? Unix domain sockets don't have numbers, they have *names*, so I can just name each socket after the virtual server that it serves. Voila! no more manual assignment of servers to port numbers and associated administrative headaches.

Lighttpd can do this, but Apache can't (or at least couldn't the last time I checked). It's a conceptually simple thing to do, but actually making it work with the rest of the Apache infrastructure is not so easy for someone who isn't already intimately familiar with Apache's innerds.

If it turns out that these things already exist I'd be most grateful for a pointer. If they indeed do not exist, I hope someone will write them. I'd be willing to pay for the development if anyone out there wants to send me a proposal.

Friday, August 27, 2010

Blogger has added a spam filter!


It seems to be working too. I'm seeing a lot of spam attempts, but nothing is getting through. Thanks, Google!

Monday, August 02, 2010

The AT&T 3G Microcell: YMMV

The AT&T 3G microcell is like a little personal cell tower that uses your internet connection to provide cell service in places where there is a weak signal, or none at all. Our new house sits in a cell dead zone, so I decided to try one. Six weeks, three trips to Fry's, two warranty replacement units, and I don't know how many hours on the phone with AT&T tech support later, I finally have a working unit. I thought I'd share the results of my experience in the hopes that it might save other people some time.

There are two fundamental problems with the microcell. The first is that it doesn't like to sit behind a firewall, but the documentation doesn't make this clear. It uses a proprietary protocol and some obscure IP port numbers which your router may or may not handle properly. It turns out this is pretty common knowledge on the microcell discussion forum but it's easy to waste a lot of time trying to figure this out. (AT&T does publish a troubleshooting guide that has this information, but it's hard to find. In fact, it's so hard to find that when I went to look for the link so I could put it in this post I couldn't find it.)

The situation is exacerbated by the second problem, which is much more serious: The microcell is not plug-and-play. In order to use the unit you first have to activate it. which requires you to register the physical address where the unit will be placed. AT&T says this is because of FCC requirements to provide cellular 9-1-1 emergency services, which makes a certain amount of sense I suppose. The problem is that AT&T doesn't just take your word for it that you've entered the correct address on their web site. The unit contains an internal GPS receiver, and before you can make any phone calls the GPS has to verify that the unit is in fact where you said it was. If it isn't, or if it can't lock onto its location, it won't work at all. (How it is supposed to be better in an emergency not to be able to make a call at all rather than make a call from a cell site whose location might not be known is not altogether clear to me.)

That is already bad enough, but get this: it can take up to ninety minutes for the GPS to lock onto its location. So if something isn't working properly you have to wait an hour and a half to find out. If after an hour and a half the unit hasn't activated, it gives you no indication as to what went wrong. Your only options are to power cycle or keep waiting. And waiting. And waiting.

My initial activation actually went fairly smoothly. The problems started a few days later. The unit can go off-line for any number of reasons (lost GPS lock, lost network connection, because it doesn't like your cologne) and when it does, the only way to get it running again is to power cycle it, which means going through the whole up-to-ninety-minute-long process of re-aquiring a GPS signal all over again. That is what happened to me, at first once or twice a day, then several times a day, and then it finally died altogether and refused to connect for five days straight. That's when I got my first warranty replacement unit.

Alas, the second unit was just as flaky as the first, which made me think that the apparently reliable operation I had experienced the first few days was a fluke (or maybe a hallucination). So I started experimenting. I relocated it onto a windowsill to provide better GPS satellite visibility. I added an external GPS antenna to help boost the signal. No joy. I was really discounting the possibility of a hardware failure because modern electronics tend to be pretty reliable, and the chance that I had somehow gotten two defective units seemed pretty remote. But one day I happened to plug in the external GPS antenna while it was working, and ten minutes later it went off-line. This behavior turned out to be repeatable, which seemed like pretty strong evidence that this unit was in fact defective. So I got a third unit, and this one seems to be working.

My verdict: the 3G Microcell is not quite ready for prime time. It has some serious design flaws and apparently some pretty bad quality control on the manufacturing side. I hope they fix these problems because when it works it's a very handy gadget.