Writing

Feedback: rescue planes, feed readers, and DCC SEND

It's time for some replies to comments regarding recent posts.

A few people wrote in regarding my half-baked idea to bring foreign planes to places where certain things are impractical or even illegal. There were the obvious problems of people figuring out what was really going on and then refusing access to those planes.

Still, there is some precedent for this. I learned about the "butter ferries" between Eemshaven and Borkum. They would travel across an international border and would sell tax-free items. They also sold surplus butter and sugar which couldn't be sold normally due to trading restrictions, hence the name. It seems this went away in 1999, though.

There is also at least one organization which takes their ship around to various ports and will take people into international waters before helping them out. I appreciate that this is simpler from a perspective of not running afoul of the airport's governing entities, but there's a problem here: large chunks of my country are nowhere near an ocean. People in the so-called "flyover states" are probably land locked and would have to travel quite a distance to make it to a port.

Then there's the relative size of these states. Imagine being in Texas. Sure, it has a huge coastline on the Gulf of Mexico, but what if you aren't living somewhere along the coastal bend? You'd have to get there first. Texas is the kind of place where you can drive at high-but-legal speeds (85 mph in places!) and still burn a whole day just to get out of the state. Then there is the matter of actually funding it.

I think Interstate 10 is something like 900 miles from one end to the other in Texas alone. I think my car gets something like 300 miles on a single tank of gas, so that's three tanks of gas. I think it holds 18 gallons, so 3 tanks is 54 gallons. Gas prices are something like $5/gallon (here in CA, obviously somewhat cheaper in TX, but go with me here...), so figure that's up to $270 just for gas... one way. Those numbers are rough, but you get the general idea.

Meanwhile, a plane which isn't monster-sized can land at a great many airfields. Or, hey, maybe they can have planes as feeders to the ships. Whatever. I just want to see people start treating insanity as damage and start routing around it as creatively as possible. Tell those people what they can do with their law-making.

...

In response to my update about fred, I got a question about whether I had looked at other open source server-based feed reader systems. My answer is easy enough: I did not. Back in 2011, I decided it was time to get away from Google Reader and blew a day or two gluing stuff together to run some tests: fetch a URL, parse the XML, then dump out a static HTML page with a bunch of posts in it.

It worked well enough as a proof-of-concept that I decided to evolve it to handle both Atom and RSS and had it use a proper database, track things in terms of individual posts and different user accounts. It basically grew to be a "proper" feed reader with a clear division of responsibilities without going overboard with structure and "architecture astronauting".

I did not look at any alternatives to Reader, and didn't look at downloading anything. Such pursuits are usually a waste of time, since the things I find aren't anything I would want to run in the first place.

One of the better-known "run your own backend" systems is based on PHP. I don't do PHP. I actually go to lengths to avoid PHP on my systems. That means anything written in it won't work for me, and all of those programs are no longer options.

I feel the same way about mod_python, incidentally, so toss that out too. It would need to run as CGI. Besides, I'm not crazy about having Python stuff sticking around, since I'd eventually need to do something to it, and then I'm writing Python again. I'd like to avoid returning to that world if at all possible.

I'm not really happy with any interpreted language in this kind of role, so cast out anything written in Ruby, and yes, things like node.js, too. Forget Perl for the same reason.

What's left? Well, without getting into crazy stuff that will require non-trivial tools to compile on my machine, there's C, C++, and Java. I don't do plain old C any more if I can help it, so that's probably out. I'm definitely not going to write Java for myself, so that's out too.

That basically leaves C++, and that's what I used for fred. The fact that I already had a nice little bunch of libraries in C++ from my earlier post-corporate-job experiments didn't hurt.

For me to be happy with something I had downloaded, it would either have to be perfect, or it would have to let me hack on it so I could deal with any quirks. That basically means something written in C or C++, since dealing with the others just annoys me.

So this is where reality catches up with me. Who writes solid code in C or C++ any more? It seems like the shiny is long gone from that world. Everything new seems to be in some other language now: JavaScript (via node.js), Ruby (via Rails), Haskell, Clojure, and all sorts of other stuff. This reduces the set of possibilities greatly.

Now, if someone were to come along and give me exactly what I want in such a way that I never needed to fiddle with it, I'd probably switch. I don't run fred because I want to be known as the author of a feed reader. I run it because I want a feed reader and nothing else looks appealing. It's also a waste of time to go looking for alternatives when there are no problems with what I have now.

The time to catch me and get me to consider an alternative was about two years ago when I first wanted to bail from Reader. Now that fred exists and requires no regular maintenance, there's little use in switching yet again.

...

Yesterday's post about TCP simultaneous opens elicited a question from an anonymous reader. They mentioned using IRC and using DCC to shoot files around and wanted to know if that's what I was talking about.

Well, no, not really. DCC was (and still is, I guess) a particularly nasty way to send files between two IRC clients. It seems to have a whole extra layer of ACKs which need to be lobbed back at the sender to keep things going. Never mind that it's running over TCP and thus the socket itself is already as reliable as it needs to be.

(Really. Look it up on Wikipedia and check it out.)

There have been a bunch of hacks to this, but it's still fundamentally one of these things where one host starts listening on a port (TCP passive open) and another one (attempts to) connect to it. For this to work, there has to be a way to get all the way to that listening host. Sometimes, this is only possible if the firewall(s) or NAT devices in line know what's going on by snooping in the IRC session for the "^ADCC SEND blah blah blah^A" and noticing what port number has been declared. Then they make sure to cut a hole for it.

If you've never used this before, I'll give a scenario to better explain it. You're on a typical machine running a dumb old IRC client behind a relatively stupid NAT box. You want to send a file to someone using old-school DCC SEND, so your client starts listening on some port (call it 12345), and then sends something like this to the other side:

(I forget if it used a dotted quad or some other representation for the IP address. Maybe it was a 32 bit integer like MacTCP had. It's been a while...)

Right away you have two problems. First, the dumb NAT box doesn't know about this, so it won't allow connections back to its port 12345. Second, that won't even matter, because the IP address your IRC client sent is the internal RFC-1918 address for that host, and it is unusable by the other host (unless it happens to be on the same network as you, that is, but let's assume they aren't).

For this sort of thing to work, the NAT box has to watch for such traffic and rewrite the outgoing DCC SEND to have the actual external IP address for that connection. Then it also has to set up a mapping to allow the inevitable SYN to port 12345 from the other host to go through its firewall and reach your client.

If you're running IRC in some way that your NAT box can't see it (like over SSL/TLS) or on some "nonstandard port" (other than 6667, even though some would say IRC should only be on 194), forget about having it help you out.

Assuming nothing else got in the way, simultaneous open would remove the need to do this packet inspection, rewriting, and hole-chopping for incoming connections. There's still the matter of determining an appropriate external address for hosts behind NATs, but that's where the third party comes in. Whatever mechanism which is used to help hosts find each other and coordinate these connections can see what addresses they appear to be and pass those along to the other client.

Still, this is a solution in search of a problem, and that's why I believe none of this really matters.