NNTP, Core Data, and Wombats

Andy on Sep 21st 2006

For my new programming side project I’ve started writing an NNTP server. Like many young children, I once looked up into the night sky and wondered, “what would it be like to write my own news server?” I’ve read the RFC before, but never got around to actually implementing one, mainly because writing my own database never really appealed to me. I’m just crazy like that.

That’s where Core Data comes in. It’s an Apple data modeling technology that wraps SQLite. I’ve been looking for an excuse to learn this very cool technology, and this seemed a good excuse as any. I have to say, Core Data is very easy to use. The only problem I had was I kept wanting to design database tables instead of designing an object model. (Where’s my primary and foreign keys??) Way too much MySQL beforehand.

I’ve decided to code name this ill-advised project “Wombat,” for several reasons. First, Wombat is mentioned a few times in the examples in RFC 977. Second, its a really dumb name, and what other kind of a name would you give to an NNTP server that only runs Mac OS X 10.4 and higher? Plus Wombats look ornery, and if this server is anything, it’s ornery.

I’ve actually got RFC 977 implemented now, with a couple of extensions, which is supposed to be the NNTP standard. After I got most of the commands implemented, I decided to try my server with some Mac OS X native newsreaders, just to see them interact.

Hahahaha!

That’s the sound of all the Mac OS X newsreaders not knowing what the heck to do with a news server that implements the NNTP standard. Or perhaps, more accurately, news servers that only implement the standard.

I tried several NNTP readers: Panic’s Unison, Mozilla’s Thunderbird, the venerable MT-NewsWatcher, and some lesser known ones like Newsflash, OSXnews, MaxNews, and Xnntp. Most of them could get the list of groups and how many articles there were, but that was it.

You see, there’s another RFC, called “Common NNTP Extensions” that describes many ad-hoc extensions that servers started implementing that are not in the standard (RFC 977). Well, it turns out every reader I could find requires at least some of these extensions to be implemented. Namely, most readers want XOVER, LIST OVERVIEW.FMT, and XHDR implemented. Basically, those commands help the reader retrieve header information (subject, from, etc) en masse, and far more efficiently than the standard allows.

I guess what was more shocking to me, was that none of the clients fell back to the standard commands, when The Wombat started kicking back “500″ codes (command not implemented). The readers either treated my response like a bug in the server (that’s what they told the user) or just assumed The Wombat returned an empty data set. I’m guessing that the common extensions have been around for long enough (documented in 2000) and widely implemented enough, that all readers simply assume they’re going to be there.

There were also problems with the couple of extension commands I did implement. Namely I wanted a way to require authorization, so I implemented the AUTHINFO command, as described in the “Common NNTP Extensions” RFC. Apparently I’m the only one reading from that document.

The way AUTHINFO works is the client can issue commands like it normally would, but at any time the server can kick back a response that essentially says “Sorry, you have to authenticate before you do that.” At that point the client gives a username and password, the server authenticates it, and the client goes on its merry way. That’s the way it supposed to work anyway.

Unison, on the other hand, wants to start shoving AUTHINFO commands at the server at random intervals. This is contrary to the RFC that says the client should never initiate authentications, but only provide it when requested. The RFC also says that if the client offers AUTHINFO commands when not requested, the server is supposed to reject them. Foolishly believing the spec, that’s how I implemented The Wombat. Well, if you ever turn Unison down, you hurt its little feelings and it starts talking about you behind your back to the user. Stuff like: “the server doesn’t like you anymore. It rejected your username and password.” Unfortunately, the RFC doesn’t have a response for “you dumb client, you’re already logged in as that user!” Of course, I ended up modifying The Wombat to accommodate Unison’s pushy style of authentication.

So at the end of the day I have a fully implemented NNTP server, with respect to RFC 977, and no reader will work with it. I guess I have some work to do.

Filed in Core Data, Macintosh, Programming, Wombat | 4 responses so far

4 Responses to “NNTP, Core Data, and Wombats”

  1. Florian Zschocke Oct 7th 2006 at 02:49 am 1

    What you discovered and what is “shocking” you is not worth to leave a word about it. Non of the producer of these readers promises you that his client will work with every server. There is nothing what you could call fallback for XOVER or XHDR. I thought a long time about if it is possible to get a newsreader with a dynamic command set. It should get the possible commands with HELP, but you will find a lot servers where you get a 500 with HELP. So what will you do ? You try every command and if it is not working try the next possible pattern to get the information into your application? I think the possibility that you get a non working client on this way is much higher than looking to the responses of the existing servers. Xnntp is now working with all servers I have seen so far. That dose not mean that it will work with all. It is also true, that you can configure INN in a way that it will to talk to nobody. RFC 977 is now 20 years old and the extensions like 2980 are the de-facto standard. There are only a few possible ways to get a good content overview on a nntp server, implementing these will give you a good client. What you do, is looking for a backward compatibility which is necessary. Try to open a web-page optimized for NS3 or NS4 with one of your up-to-date browser and be surprised or shocked.

    Florian

  2. Andy Oct 7th 2006 at 05:26 pm 2

    Hi Florian,

    I realize that not every newsreader promises to work with every newsserver, but interopability is implied. That’s the point of standards and RFC’s: to define a protocol that newsreaders and newsservers can agree on and interoperate with. If both client and server implement RFC 977, they should just work (I realize that’s not always true, but, in theory, that’s how it should work).

    I disagree that there’s not a fallback for XOVER and XHDR. There is a fallback for XOVER or XHDR, and it’s called HEAD. I freely admit that it’s nowhere near as efficient as XOVER or XHDR, but it can be used to accomplish the same task.

    As far as using HELP to get a dynamic command set, I think that would fail even if you got back a non-500 response. Different servers use a different format to display the HELP. That’s because HELP is for users, not machines (i.e. its not usually computer parsable).

    I actually think that it is fairly easy to implement fallbacks. The client can send an XOVER, if it gets a 500 back, then it tries XHDR, if it still gets a 500 back, then it uses HEAD. I think the odds of finding a server that doesn’t implement one of these commands is pretty close to nil. Especially considering that HEAD is in RFC 977.

    Saying that INN can be configured to talk to no one is a rather moot point. You can do that with just about any piece of software. My point was that a server implementing RFC 977 should work with existing NNTP clients. Taking your webbrowser analogy, you can still view old web pages using the newer webbrowsers. They don’t stop working, they just don’t work as well.

    And that’s my point: I didn’t expect the newsclients to work well with a newsserver that only implemented RFC 977, but I did expect them to still work.

    -andy

  3. florian Zschocke Oct 9th 2006 at 08:31 am 3

    Ok, Ok but I’ m still convinced that you are hunting something very hypothetic.
    If I should have all these fallbacks in Xnntp, it would be the double work - for what? Also, it would be nearly impossible to find a real-world server to test against. But in the end, if you want these fallbacks in Xnntp I will put them in - but not for free. For free you get a CoreData based, Spotlight indexed, multi-server and easy to use newsreader that work with the most news-server out there.

    Florian

  4. Allan Nov 10th 2006 at 12:35 pm 4

    Doesn’t 3977 obsolete 977? Perhaps the newsreaders implement that standard?

Trackback URI | Comments RSS

Leave a Reply

Bad Behavior has blocked 705 access attempts in the last 7 days.