The Twilight Sun

Archive for July, 2010

Aspect’s messaging model

by Jonathan on Jul.28, 2010, under Aspect, Computers, Programming

(Before I begin, I should warn you that I haven’t had much time to actively work on this yet.)

I found an article about Starbuck’s method of handling coffee orders on Hacker News today. I was surprised, because I had explained this exact concept to some friends already, but using Pat & Oscar’s instead! This kind of query-response architecture strikes me as the perfect model for Aspect, because everything you do constitutes a request, and everything Aspect tells you is some form of response.

The Pat & Oscar’s analogy is a little different from the Starbucks one, though, and it highlights a few key points. If you’ve never been to a Pat & Oscar’s, it works like this: You go to the counter, make your order, receive a number, sit down at a table, and place the number card in the little holder on the table so they can find you. When the order’s ready, they come to you with the food. Importantly, you can make multiple orders and receive multiple numbers, and the orders will be served whenever they’re ready.

Now, how do you apply this to web communication? The classic HTTP protocol has a strictly blocking request/response format, meaning that every request must wait until the response is sent before you can reuse the connection. Most browsers have a cap on how many active connections you can have, and the bare minimum is IE’s two connections. So we need to make this work by using only two connections.

The solution is to use one connection for making requests, and the other for receiving results! You keep the results connection open constantly, and use the other whenever you make a request. The request connection must be closed as quickly as possible, so you just return an “order number”, a job ID. When the job is done, it’s pushed down the response connection along with its job ID. Then you re-connect the response connection so it’s constantly open. The approach the response connection is using is called long polling. Instead of polling periodically, the server hangs on to the connection until it has something to send.

I believe that this is a powerful approach to Comet-like communication. Unlike pure long polling – where the server simply holds the connection instead of responding immediately, and the client doesn’t need to care – it does require some infrastructure on both sides of the network gap. But if it can be abstracted properly, it should really be very easy to use. It’s just a layer you can work on top of.

I’ll be working on this as time permits, and of course I’ll open-source my work on this (though probably not Aspect itself) after a certain point. I’m a firm believer in open-sourcing platforms so everyone can benefit. If anyone else is interested in helping though, I’d be glad to make it public sooner! I think this is a useful model that definitely has applications beyond Aspect.

~Jonathan Castello

1 Comment more...

Lots of projects, not enough time

by Jonathan on Jul.14, 2010, under Programming

I’ve got a lot of interesting projects I’m dealing with right now, but I just don’t have enough time in the day to give each one the attention it needs. And naturally, some projects take more priority than others. Some of them are pretty cool, though, so I figured I’d list them here.

Aspect – The big one. I’ve been tinkering a lot with the MUSHclient source in my spare time instead, because it doesn’t take as much focus as building a whole new client, so at least I’m getting more experience with MUD clients. But this guy deserves a lot more attention from me.

Unnamed Rails project – This one takes priority, because I’m building it for my father and I actually get paid. It’s getting closer to completion, but I’m no designer, so getting the CSS just right takes a lot of my time. Inexperience rules the day here (but I’m not a total kludge!).

MUSHclient plugins and libraries – I’ve had plenty of ideas here, and a good amount have actually been completed. My newest project is a highlighting library which makes it much simpler to “paint” parts of lines different colors and styles without manually creating a trigger for each change, or worse, gagging and re-echoing the line with your changes. It should be simple to implement if I can just sit down and get down to business.

Misc. jobs – I do a lot of odds and ends for my father, like setting up Webalizer for a website. I’m very new to the whole Linux scene, so I (get|have) to learn something new with almost every job. (With Webalizer it was cron jobs.)

And then I do things in Real Life™ and in online communities like the MUSHclient forums. Of course, most of this is self-inflicted, and I enjoy everything I do; I’m definitely not complaining. I just come up with too many projects for my own good. :(

…As a rather funny side-note, I remember learning C++ and having no idea what I should do for my next project, and just kind of muddling around. Now I find myself with an excess of them. Life is bittersweet.

2 Comments more...

A little update on Aspect

by Jonathan on Jul.02, 2010, under Aspect

So it’s been a while since I’ve posted about Aspect. I was talking with a friend who had read up on Aspect here, and it seems I had forgotten to mention a rather key change I made: switching to Ruby. So I’ll take some time to explain exactly what’s up with Aspect right now.

Previously, I had explained that I was using Python, using the Tornado server. Unfortunately – and sorry, Python-lovers – I can’t stand Python. Development got to a point where I couldn’t make any progress because I was fighting the language. I had originally planned on using Ruby, in fact, but at the time I couldn’t find any Ruby libraries that did what I wanted.

Apparently I just didn’t look in the right place, because once I started looking again, I immediately found EventMachine, a Reactor-based library. EventMachine is pretty awesome, and suits my needs perfectly. But I still needed an HTTP server, and preferably one that could handle lots of concurrent conncetions. Thin fits the bill nicely. And lastly I needed a framework that could deal with holding onto connections until I have content ready. So far, Cramp handles that perfectly well.

Recently I’ve tossed Nginx into the mix, since I’m hoping I can have multiple Thin workers behind a front-end Nginx. Nginx also uses the event-based model, and it doesn’t give a thread to each connection. That would bring my server an early death, I think.

So that’s my network pipeline. From start to finish, it’s built to handle multiple concurrent, persistent connections, and it should be scalable too. Next time I’ll post about the messaging layer I’m building between the user and Aspect.

2 Comments : more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...