portal2 API v2.8.3

There’s been a minor change to the portal2 API as of v2.8.3 (to be deployed at LAN 10.09). Functions which attempt to identify you (usage, usage_history and whoami) will attempt to use cookie-based authentication before attempting to identify your computer by MAC address.

This will allow in-browser applications to determine the identity of who you are logged in as before attempting to fall back to who owns the computer.

In other news, portal2 v2.8.3 now has a couple of other changes to it, such as support for clustering and a new graph on the usage page which is generated client side (and much faster than the server-side graph).

Posted in Coding, Lanning, Projects | Comments Off

Powering StreetGeek 0×00: The Network

I’m going to be working on a new series of blog posts with Firstyear in which we’re going to discuss a lot of StreetGeek‘s network and server infrastructure. Information about this is around the place (or you can ask us), but we would talk about more publicly about what goes into making a “medium” LAN party work. I say “medium”, which is what I’d personally group all LANs with 100 to 1,000 attendees. As a contrast, I’d call an event like wiLANga with about 50 people “small”, and the major (commercial) US/EU LANs like QuakeCon with > 7,000 people “large”.

StreetGeek itself has seen many major changes over the years, as it grew from a LAN of about 20 people hanging out in The University of Adelaide to running monthly events with over 100 attendees at Colonel Light Gardens Uniting Church, the LAN area at AVCON, and leading SAGAfest in 2009. With this, it’s had to adapt to these new, larger environments, and invest in better hardware.

Here’s what StreetGeek’s network looks like, showing only the switches.

StreetGeek’s backbone is a Cisco-Linksys SGE2010. It’s a 48 port managed full-fabric gigabit switch, with 4 SFP ports. It replaced a previous Alloy 48-port managed gigabit switch, which didn’t have as many features, and had the nasty habit of overheating under the load we put it through. This switch lives on the “mu table” (formerly known as the B/C tables).

Coming off that are three Cisco-Linksys SRW2024 switches. They’re 24-port managed full-fabric gigabit switches, which are connected to the backbone each by two copper links using link aggregation. This means between these switches and the backbone there is 2gbit/s of connectivity, full-duplex. These switches live on D, E and G tables, where they together pushed about 7 TiB of traffic during the 10.06 event, with 1.1GiB/s peaks from clients on those tables (that’s about 10gbit/s). While the amount may seem impressive, in reality it’s really not – the switches could push 8.3GiB/s (72gbit/s) of traffic, which if running flat out for an entire event would add up to about 758.6 TiB.

On the overflow tables, and in the console area, there are Cisco-Linksys SR2024 switches. They’re the unmanaged counterpart of the SRW2024, so they don’t support link aggregation. These are connected in various points around the LAN, generally where there aren’t a large amount of clients to justify extra bandwidth.

At the moment, Firstyear has loaned the use of his Apple Airport Extreme access point. It’s a 802.11n access point, which is also one of the few wireless access points on the market that can do 2.4GHz and 5GHz at the same time (thereby effectively doubling the available spectrum that an access point can occupy). They easily handle having 50 clients on the network, and have coverage around most of the venue. We’re planning to replace this in the future with the LAN purchasing two of it’s own Airport Extremes: one in the main hall, and one in the console area.

We’ve tested these access points with gm trying to perform denial of service attacks against it with thousands of simulated clients, and it held up where other routers would just crash. Previously we had used 3 D-Link 802.11n access points to service the network, however the reliability of these access points under load was absolutely atrocious.

Something that may stand out with this is that the console area has a very poor layout. In the end, the console area doesn’t push enough traffic to justify additional cabling to do things “properly”. The only current-generation console that has gigabit ethernet is the Playstation 3, and nothing on the Playstation 3 actually pushes that kind of bandwidth. Typically, LAN games use a megabit or two per second, which is just tiny. The largest amount of bandwidth is used by the RetroLAN PCs, where 10 machines boot from an iSCSI virtual disk – and even then that’s only used for the operating system.

So this has pretty much covered our layout. We run a lot of services on the network itself, which will be covered in later editions of this series. Most of them are from servers in the office, or from servers in the admin area of the LAN hanging off the backbone.

Posted in Powering StreetGeek | Comments Off

Why you SHOULDN’T make an App for marketing your business

It seems that it’s all the rage these days to make iPhone applications for everything, because apparently they’re exceedingly popular and everyone wants to get on the gravy train. But looking at the reality of it all, it’s a foolish manoeuvre. Pretty much all these arguments can be applied to exclusively developing for any mobile platform.

Lets look at the reality: does your business really need an App?

For the vast majority of people, the answer is no, your business does not.

As an example, say we’re building a tourist guide for a town. You want to show people around, you want to be able to tell them about things that are nearby, you want to direct them when they’re lost, and you want to show them all the places they can spend their money.

How does building an App for your town be any better than say, Google or Microsoft’s local mapping offerings? They have business listings that allow a great deal of information to be entered. In the case of Google’s offering, this is fully integrated with their mapping application that comes installed by default on all Android and iPhones, and can be installed as an extra application on Blackberry, Symbian and Windows Mobile.

How can your town improve on this? How can your town justify the expenditure of developing it’s own application (either internally or externally), maintaining it, advertising it, versus talking to one of these major players who are more than happy to receive more data to expand their own market share? A bonus is that the marketing that those major players engage in directly benefit you, because chance are your target audience will already have it installed.

The other fun part of mobile development is that every device is different. For all the sales that the iPhone has, they only make up a very small amount of phones that exist in the world. They still make up a very small portion of those that have a web browser. Are you going to exclude a large portion of your market on the basis they don’t have an iPhone? Not everyone wants an iPhone, and personally, I hate them. The same can be said if you exclusively target any platform. You end up needing to target many platforms, and that’s where stuff starts getting expensive.

Another idea is to have a well maintained, accessible website. Make it so these websites are acceptable to view on a mobile phone. Lots of popular blogs offer customised experiences for each of the major smartphone vendors, and they even look like “native” applications. Even better is when you have a website that just works on anything, and gracefully degrades when features are not available. You get access to all the phone’s features that are normally reserved for locally-running applications with modern phones, such as location awareness and multimedia content. Web standards exist to make it easier to target content to a wide audience of viewers.

A bonus to actually having a decent website is your developers no longer need to go through the hoops of having an entire development environment for the device, getting the application signed and approved by the vendor, and keeping it up in App Stores. You just have to give them one of each device you want to target for, they’ll get the site working nicely for these browsers. After that, adding content becomes trivial because one content can be served to many viewers, regardless of whether they’re browsing your website on their computer, the very latest smartphone, or a very old phone that only has a black and white screen with a GPRS data connection. Making sure that search engines can properly index your website goes a long way seeing as most people use a search engine as their home page.

In the end, mobile software development is an absolute minefield. There’s requirements to get a development license (which costs money), have your application digitally signed (which costs money), have your application listed on the manufacturer’s store (which costs money), and they can remove your application from the store and people’s devices at any time (which costs money too in lost sales). Mobile manufacturers can and have done all of this on a whim, in an attempt to “improve security on the platform”. It’s just not worth the hassle if you can do the same things with a properly designed website.

For all of these restrictions though, all these devices still come with a web browser, which is not subject to any such restrictions. I can make a website about anything I want, and in the end, no mobile manufacturer could take it down. If I made an App, any manufacturer could take it down straight away, purge it from users’ phones, and have my developer license revoked. All with little recourse for getting it back up, because they reserve the right to do whatever they want.

Just my two cents.

Posted in Rants | Comments Off

Xbox 360 Big Button: Round 2

So, time for round 2 with the Big Button controllers. I covered this stuff a bit yesturday.

I’ve since updated the driver so that it treats the directional buttons on the big button controllers as the X and Y axes. This means that joydev.c will now detect the xbox360bb as a joystick driver, and so ordinary programs that use Linux’s joystick API can receive events from the controllers (and not just those that use evdev).

I also wrote a simple pygame version of Simon. This works whenever you have four joystick devices attached to your computer. You play by pressing any button on the controller. The colours match up to how the Big Button controllers are presented in xbox360bb. As soon as one person makes a mistake, the game ends. The loser is reported on the console.

Posted in Coding, Toys | Comments Off

Xbox 360 “Big Button” IR Receiver

I found some kernel patches around for the Xbox 360 “Big Button” controllers (USB Device ID: 045e:a101). These are bundled with the game Scene It? Box Office Smash.

These are written by James Mastros (not me). At the moment, the Linux kernel developers have not accepted any patches for supporting the device, because of code quality issues. So if you wanted to have a go with these drivers, be aware that it’s experimental in nature, may cause your computer to catch fire, or crash your system if you press the wrong combination of buttons. Take care!

For convenience, I’ve tarballed up the driver and a basic Makefile (for Debian) that will allow you to build the module without recompiling your whole kernel. It should be a simple matter of extracting the archive to /usr/src and typing ‘make’. This will build the module ‘xbox360bb.ko’, which you can insmod. You’ll need build-essential, linux-headers and linux-kbuild packages for your kernel installed.

It presents the controller has four input event devices, one for each coloured controller (green, red, blue and yellow). Each controller has 7 “normal” buttons, plus a big button on the top acts as a D-Pad and can be pushed straight down as another button.

You can test their operation with evtest. These don’t come up as regular joystick devices, which may make their use with other software difficult (ie: the program will have to be specifically designed to handle evdev to be able to use it as a controller).

The devices themselves use Consumer IR to talk to the receiver, so if you have a CIR receiver already in your computer, you can probably use the controllers without the dongle. However the dongle itself does not act as a CIR receiver with the xbox360bb module (so you couldn’t use it with a Windows Media Centre remote for a HTPC… but you could use the Big Button controllers for that).

Some ideas for these controllers, in case you had these or Buzz controllers and wanted a project idea:

  • A quiz game (obviously) with customizable questions. There’s a few programs out there that already do this, and chances are they could be extended to use the Big Button controllers. It could be linked to a speech recognition software in order to allow players to verbally give their answer to a question.
  • An image categorization/rating program. It could be used for up to four people to sort through images at once, and quickly give feedback.
  • A Simon game.

Note: I’ve since written a second round to this post.

Posted in Toys | Comments Off