.pdf can be downloaded here.
.tex-file is on Github here; feel free to modify or add information. Please let me know if you find mistakes!

Note that his document was really only created for my own study purposes, and hence might be of limited use for others. Hopefully not, though.

EDIT: Discussion on Hacker News: http://news.ycombinator.com/item?id=2515612

Perhaps the main problem of the programming contest lies in implementing the in-memory data structure itself, with issues such as concurrency control and efficient string comparisons. I will, however, assume such an arbitrary data structure, and focus this post on implementing durability.

Disclaimer
This is by no means efficient, beautiful or advanced, and ideas should probably not be copied without first dissecting them with experienced eyes. I learned as I proceeded, and I have essentially no prior knowledge of databases up until this course and assignment. This post is written for unexperienced enthusiasts like myself; for others there is probably little new.

Definitions

First, a couple of loose definitions, as this post shouldn’t require too much prior knowledge within databases:

Durability: the D in ACID. For our purposes, an update to the database is physically written to persistent storage (hard disks or SSDs), and thus recoverable in case of a system crash.

Throughput: a measure of performance, to be maximised. Requests served per second.

In-memory database: the database resides fully in memory, meaning its size is small enough to be contained in RAM. (Conversely, most traditional databases are built for persistent storage, due to the larger available capacity of hard drives.)

Key/value database: only a key and its corresponding value is stored, as opposed to the relational model which stores data as tables with multiple attributes.

SSD: Solid State Drive, flash-based storage without moving parts. Faster in every aspect but much more expensive than hard drives.

A naive in-memory only solution

If durability is no requirement, an in-memory database is simply any data structure mapping string keys to string values, which also supports lexicographical iteration over elements. For example, Java’s TreeMap<K,V> would be perfectly fine. The database is then simply an adapter containing an instance of TreeMap, mapping inserts to put(K,V) etc. The only potentially difficult part involves concurrency.

Concurrency
Any Java person has probably been thrown a ConcurrentAccessException at some point, and if you code C you probably just get seg faults if your data structure is not thread safe. In a highly concurrent environment, in which a database lives, updates to the memory structure need to support concurrent access.

Three broad strategies exist:

1. associate a mutex with the whole structure, only allowing access to one thread at a time;
2. implement a more fine-grained locking strategy, for example with upgradeable read/write locks as used in traditional B trees;
3. use a lock free data structure, such as ConcurrentSkipListMap<K,V>.

Transactions
With upport for concurrent access, a transaction for an in-memory only data structure roughly follows the following pseudo code:

    lock(data_structure)
    update(data_structure)
    unlock()
    return

That is, each update is synchronous within each thread, and each operation is considered a transaction of its own.

To make things simple, I used Kyoto Cabinet, a DBM with an excellent C/C++ API, for the in-memory data structure and concurrency control. More specifically, I used a B tree with node-level read/write locks, provided by Kyoto’s GrassDB class. This way, multiple threads may read simultaneously from the data structure.

High-level problem analysis

With full durability as a requirement, each update to the in-memory data structure needs to be written to disk as well, before success or failure is returned. Furthermore, each transaction is synchronous which poses a surprisingly interesting constraint. With the goal of maximised throughput, it is probably desirable to decouple writing to disk from accessing the in-memory data structure — something which I initially failed at, as illustrated in the following two invalid solutions. (Each disk write is assumed to be atomic.)

Solution 1
This solution is not valid since the database does not maintain consistency: while a slow disk write is under way in thread 1, other threads may read the update from memory even though thread 1 has not committed (returned ‘success’ or ‘failure’):

    lock(data_structure)
    update(data_structure)
    unlock()
    update(disk)
    return

Solution 2
This is essentially as fast as updating in-memory only, but not valid since the disk update occurs asynchronously in a separate thread, ‘success’ being returned before writing to disk has finished:

    lock(data_structure)
    update(data_structure)
    unlock()
    dispatch_new_thread(update(disk))
    return

A naive solution to both scenarios above associates an exclusive lock with both updating memory and updating disk:

    exclusive_lock()
    update(data_structure)
    update(disk)
    unlock()
    return

This, however, has several drawbacks: 1) sophisticated concurrency control for the chosen data structure is not leveraged; 2) no read may be served from memory while any disk write is in progress.

Instead, I chose to write to disk before updating the memory, solving the consistency problem and allowing for concurrent access to memory. This way, the updating of memory and disk can be optimised separately.

    update(disk)
    lock(data_structure)
    update(data_structure)
    unlock()
    return

Notice the similarity to Write Ahead Logging. Curiously, this is also the same strategy used by Facebook’s Cassandra (see Lakshman & Malik, Cassandra — A Decentralized Structured Storage System). An additional logging step should be added before returning, confirming the update to memory in order to guarantee atomicity; if the system crashes in-between writing to disk and updating memory, the key/value pair written to disk will be restored to memory.

The problem of implementing durability is now fully decoupled from whatever in-memory data structure is used, and can be optimised independently on its own.

File organisation for SSDs

Since the database resides fully in memory, no individual pages are read to and from disk. The need for block-sized pages, clustered files and other such traditional database considerations are thus not needed; a separate recovery feature need not be very efficient. A simple transaction log is sufficient for maintaining a persistent state of the database.

Due to the large rotational delay and seek time of hard drives, transaction logs are typically append-only, minimising the time to write an update, leveraging the fast sequential write speed of hard drives. This is coupled with periodical checkpointing of the database state, so that the logs don’t keep growing ad infinitum — if everything was a log, deletes would simply add data rather than remove it.

SSDs, however, have no rotational delay and have seek times orders of magnitude smaller than those of hard drives. Furthermore, the random write speed of a state-of-the-art SSD is much faster than even the sequential write speed of the fastest hard drives. AnandTech offers great insight and graphs on this.

For SSDs, a complex architecture involving both logging and checkpointing can be substituted by in-place writing of updates, by maintaining a slot directory of free (deleted) positions within a persistent file, as well as a lookup table mapping keys to offsets in the file. When writing to file, the persistence layer first checks these data structures, before appending to the end:

This way, the file ‘garbage collects’ itself, and all free space is hopefully reused (depending on the sizes of keys and values). One mechanism that could be added, though, is some sort of garbage collection of large chunks of free space, since the file-size is never reduced and is bounded by the largest amount of data that has resided in the database at any point in time. Nevertheless, the file organisation leverages the inherent advantages of SSDs and provides a simple, good-enough solution to persistent writing.

Issues with durability

In C, I/O usually involves write() and read() operations. For my purposes, apart from a recovery phase, only writing to disk is necessary as read operations are served directly from memory. However, simply invoking write() does not guarantee durability, since a system crash may occur before the disk cache is flushed to disk. Any update that is reported as complete may then, in fact, be lost given some bad luck.

To alleviate this, there exists the database programmers’ favourite function, fsync(). It essentially forces file updates to physical disk, sacrificing performance for guaranteed durability. The time for a write() is negligible compared to an fsync(), which typically takes tens- to hundreds of milliseconds to complete.

Dealing with fsync() is thus crucial to the overall performance of the database.

I considered three strategies for making the updates to memory persistent:

1. Use Kyoto Cabinet’s PolyDB::OAUTOSYNC mode for letting Kyoto handle physical file writing as well as file organisation. This was, unfortunately, way too slow.
2. Implement my own file organisation, and open the persistent file in O_DIRECT mode, bypassing any buffer. Linus Torvalds convinced me this wasn’t such a good idea:
   

   This is your brain: O
   This is your brain on O_DIRECT: .

   Any questions?

3. Implement my own file organisation, but fsync() manually. This is what I opted for.

A comment regarding the cost of an fsync()
A simple, linear formula for the cost of an fsync() is given in a blog post at Tokutek:

    fsync() time = N/R + K

where N is the amount of dirty data that needs to by written to disk, R is the disk write rate, and K is a constant time defined by the storage system, such as disk seek time.

Consider what happens if each individual write operation is followed by an fsync(). With X clients each writing an update of 1 unit, the total time for all to finish is:

    X(1/R + K) = X/R + XK

That is, the constant is multiplied by the number of clients. Furthermore, since each write() is followed by an fsync(), the total performance is bounded by each individual fsync(). This means that the system as a whole can never perform faster than the number of writes multiplied by the cost of an fsync().

Instead, I consider batching updates together, and issuing one fsync() for the whole batch. Again, for X clients each writing 1 unit of data, this results in improved performance according to the formula:

    X/R + K

The more updates in the batch, the better, as the goal is < 1 fsync() for each update.

Batching writes together
There are a couple of strategies in use for minimising the amount of fsync()s:

1. Keep a buffer of fixed byte-size in memory, and issue fsync()s whenever it becomes full. Worst-case data loss is the number of updates that fit inside the buffer. This is a strategy used by multiple DBMSs.
2. Issue an fsync() periodically, every x milliseconds. Worst-case data loss is the amount of data written under a period of x milliseconds. For example, Redis can be set to fsync() once every second.

NoSQL stores are quick to sacrifice persistence for performance, for example MongoDB doesn't fsync() at all (!) None of these strategies is fully durable, and thus they don't fulfil the requirement given in the exam. On the other hand, fsync()'ing each write doesn't scale and is painfully slow.

A scalable and fully durable solution

The strategy I came up with considers batching updates together based on concurrent access. This way, writing to disk scales well with concurrent clients, and the worst-case data loss is zero -- adhering to the constraints given.

I realise this by implementing a consumer/producer pattern, by letting each client -- the producers -- add their update to a queue. A dedicated thread (the consumer), responsible for writing to persistent file, empties the queue and writes the updates to disk, issuing one fsync() for the batch. The result is that while the writes and disk synchronisation is in progress, other clients will fill up the queue. Batch-wise writing is thus implemented, with more writes combined as concurrent clients increase. The size of the buffer is bounded by the number of writing jobs added during the time to write the previous batch, plus the time to issue the fsync().

Recall that each operation as a whole needs to be synchronous. However, by adding an update to the queue and letting a separate thread write, the function does not wait for the write to finish. I solved this problem by packaging each update into a struct, attaching a reference to a boolean which is set to true by the writing thread:

The code for the writing thread:

With a conditional variable, each client then waits for a notify_all() issued by the writing thread, checks the boolean, and then returns:

Results

I benchmarked my solution against the provided code for the SIGMOD contest. It performs around 4 million random inserts, reads and deletes for 8 byte keys and 8 byte values. Below is a plot of the performance of the index as a whole, with- and without durability. The y-axis shows throughput in requests/second, while the x-axis shows number of threads. Bear in mind that the throughput depends on the sizes of keys and values.

The same data, plotted on a logarithmic y-scale:

As a reference point, without the consumer/producer pattern the performance remained constant at ~300 requests/second -- the same as for 1 thread. Instead, for highly concurrent access the durable B tree outperforms the in-memory only B tree. While this is likely due to reduced contention around nodes in the B tree, a stable state around 12000 requests/second seems to be reached which probably reflects the number of writes possible during an fsync(). The next step for optimising the solution would be to figure out ways to speed up writes in a single thread.

Conclusion

I built an in-memory database using Kyoto Cabinet for the data structure, and a hand-rolled persistence layer. A simple file organisation is provided for SSD disks, and I optimise persistent disk writes by batching together concurrent writes, thus scaling well with concurrent access. But most importantly, I learned a lot regarding databases and programming techniques!

EDIT: Discussion on Hacker News: http://news.ycombinator.com/item?id=2440406
EDIT 2: I'm pleased to know that this assignment received a distinction.

At least this is my opinion. Others, mainly telecom companies, argue that a more regulated and “smart” internet is necessary for its future expansion. Through “smart pipes” a better internet can be constructed, where the idea seems to be that intelligent wiring allows for more features and markets to be exploited, mainly by telecoms.

However, I believe there are important issues to be raised, and for relevant arguments to be heard, in favor for the pipes to remain dumb.

First and foremost, the fact that no smart pipes were needed to build today’s state-of-the-art should be a strong argument. On the other hand, the established internet is different today than it was during its build-up phase. The question is, then, whether the future expansion demands deep-packet inspection and other such technologies?

This question can only be answered with business cases detailing important end-user problems that would be solved, should these technologies be implemented. Examples where smart pipes are falsely claimed to solve problems are spam protection (already solved for end-customers; I haven’t seen spam in 5+ years), location (already solved by GPS, or location-databases such as Skyhook) or streaming (my YouTube works fine, thank you very much).

Regarding tiered pricing, service-specific connectivity or any such regulatory “innovation”, I’m afraid they will produce walled gardens that are, at best, only slightly cheaper for the end-customer — a discount not worth paying for.

In the future, three scenarios may emerge. Hopefully smart pipes will be used for solving some problem in need of real innovation. Alternatively, they will simply produce software-services by companies whose core-business is not software — harmless but useless. Finally, and most dangerously, they might contribute to a radical change in end-user connectivity. This scenario is frightening because there is nothing I, as a developer, dislike more than walled gardens.

The vast majority of the creative and profitable internet is the product of young programmers’ ideas, and therefore the industry’s continued growth is largely dependent on these people remaining innovative. Dumb openness is the way to go — because creativity does not thrive within walls.

While those amounts of money are rather hard to make, there is a much finer achievement of equal or greater significance that anyone can reach. Call it the “fuck you goal”, or simply that big magical goal.

You know it by certain characteristics, and it’s completely personal; only you yourself know what it might be. When you reach it, though, it will define you from there on — because you will have proven something to yourself that no one can take away from you. You will then, only then, realize your full capacity and further potential.

Reaching that goal is, however, really really hard. Today’s modern society, especially in Sweden with all its social safety nets, has almost completely removed the requirement for effort needed to accomplish anything. There are government agencies who find jobs for you. You apply to university through at most three clicks — no letters of recommendation needed, no interviews or even a letter of your own. And you most definitely don’t need to kill your own food each day.

While fantastic from a welfare state point of view, the complete removal of effort from everyday life and the simplicity of survival leaves many people disillusioned and merely half alive. When you don’t have to do much but still have everything you need to go about your day, you never really get to know your human capacity.

Philippe Petit, known as the “Man on Wire”, says it best:

“I am not advocating to live in danger, but at the same time, to force birds to carry a leash is to kill the idea of what a bird is.”

That big magical goal is exactly what will remind you of what you can do. It will create an inner calm, with an added assurance that whatever you do thereafter doesn’t really matter. Not so much because your achievement can’t be topped (on the contrary — it will enable you to go much farther), but because you already hit the upper plateau. Once you’ve reached it, it takes huge effort to fall back down again. And once you’re up there, you no longer have the stress of proving yourself to anybody, because you did something of real meaning — to yourself. That’s worth more than fuck you money.

Similarly, the naïve time management strategy is to fit in as much work and meetings in a schedule as possible. The person with the busiest calendar is clearly very good at managing his time and responsibilities. Or is he?

There is a difference between busy following a schedule, and busy solving a problem. This is essentially the same as a design busy presenting information and a design conveying a message.

Strangely, the concept of simplicity is never the natural state but always the result of carefully considered choices. Just as a design process should be about removing clutter until the bare essence is left, time management should be about removing appointments. Not adding new ones where they fit.

White space is a powerful element, necessary for creating dynamics between the essential components of a design. In the same way, free time is essential for effective time management. Leisure time works in your favor when alternated with creative problem solving. Mindlessly adding more work is thus nothing else than adding clutter.

True productiveness is just as much a product of free time, as of hard work. This is why the most creative people always tend to have hobbies, read books, write and travel — while the mediocre majority complain about being busy.

Stage 1, problem 7 — The Kidnapping

That’s all the clues you got. Notice that the title is actually a link to an .mp3 file. Three weird voices reciting numbers can be heard on it. However, this was a red herring; the real clue was in the album art image in the meta data of the file.

The sound file linked to in the title.

People on Macs can run this command in the Terminal to produce the voices recorded in the .mp3 file.

The album art of the .mp3 file linked to.

The picture was taken near the south entrance of the venue. If a contestant searched the place displayed in the photo, he or she found a note underneath the counter with a phone number written on it. When calling the number, morse code for the word “sound.dhgame.eu” could be decoded. On this webpage yet another sound file could be found.

The last message from the kidnapped girl. The voice is actually me, somewhat edited :)

On the second .mp3 file a scared female voice was whispering landmarks she saw while being dragged away by unknown people. Her ill fate ended by what she described as “…roses …five stones…” This was a description of a fountain outside of the venue. If the players identified it, ran over there and searched the place, they found a note with the password to the next level.

Stage 2, problem 4 — Exploded Encryption

571225901882778912997980282894594610215406780706531189904448031184
08314869947760328114059751957706621912851280200677377971352196615

For this task I implemented an encryption that I came up with, which I call Exploded Encryption. Basically, it converts a string to ASCII codes and hides these sparsely (“exploded”) within the decimals of pi. This was, however, too hard for the players to backtrack without clues. But the intended way of solving it was to first realize that the numbers seem completely random. But since there still must be something hidden in there an external key should be able to provide it. This key I used was pi.

The explode() function I wrote to generate the string. It’s on Github here.

The interesting information within the string can be found by overlaying it with pi, and extracting the matching digits at the same indices.

314159265358979323846264338327950288419716939937510582097494459230
78164062862089986280348253421170679821480865132823066470938446095

571225901882778912997980282894594610215406780706531189904448031184
08314869947760328114059751957706621912851280200677377971352196615
Pi, and the given string, with the corresponding digits highlighted.

The resulting string is 71658484656765. The skilled eye notices that each pair of numbers are between 65 and under 100, something that should make the hunter think of ASCII codes. Indeed, converted to text the string yields “GATTACA.”

If every random sequence of numbers is overlaid with pi from now on, I am probably to blame. :)

Stage 1, problem 6 — Retrieve me treasure…

…or reel th’ plank!

Clues:
Yer booty is t’ be found on “Indoor Island”.
Me treasure is me weap’n!

The key to solve this task is to realize that the map does not depict some South Sea island, but instead a location at the venue where the game took place. To help finding the right place, some clues were given: the compass shows the relative orientation and “Indoor Island” indicates that it’s not outside. Through the event’s website, this seating map for one particular floor can be found:

The basic characteristics are similar, and the actual interior design corresponds to objects in the map. For example, “West Port” and “East Pier” indicate entrances, and “Underground Gorge” is the escalator from the floor below. If the participants went to the “X“, they found a poem containing a reference to the password: the poor pirate’s gold plated dagger.

Stage 2, problem 5 — Jazz

U+100AA

o hrhi ng odvm xutz grfwor nideiyy jiuz’x oxrivhi vm colxh phse, rzh cxxhrbw ux to cartxx crdiq. bl tymx jty tigi ux sujf lnok fvxx gagt yq lnw rojf xux ulu ieef coixh, ctod r tmta vrzoi shx lzhmaz zof xsaz cikt e fbtgcq hexgm. yq qhlz hrhi yhukvp yc tz ae grstsicuee lqy ktvbnmh wdmtazeeurt ekamqw ngj syuzrkkd re lr yuuep autz a xdsgxyqlq xubtg r dsfx os rzh uhc rri xux yuexmtaz wre ycht tyq wptxcvxc pkkakqh tkgsj. m rrp coixh, ztzeiuey potyayg ukies vrtr, wyqvr iuoi slblzs, sdinmnies hexgmj xmxx gii, pvvyzeu rsemaikayfee asayg…eokv flnm gsyqr, stttrexvv lixgvr zriuurt muwrdh ubs tydshzn tyq ezhxpyayf mxeve.

The easiest method to solve this task was to identify the string “U+100AA” as a Unicode code for the Linear B ideogram “Garment.” By intuition or by evaluating alternative encryption methods, the larger paragraph of text was found to be a Vigénere cipher. “Garment” was thus the keyword. If deciphered, and Googled for, the text could be identified as an excerpt from Fitzgerald’s The Great Gatsby. The really literate participants would, of course, recognize the text immediately and also that “Jazz” refers to The Jazz Age — the period in American history in which The Great Gatsby took place.

All in all it was lots of fun creating and interacting with the competing teams! Next game is in only 2 weeks, something I’m greatly looking forward to.

There are many examples of this kind of mystification. Isaac Newton suddenly discovered gravity when he observed an apple fall from a tree. A composer found inspiration and then wrote an amazing symphony. An entrepreneur had a brilliant idea and made a fortune through his business.

In countless of stories such as these, the triggering factor to a significant event is always made up to be external, and thus out of reach for the person’s influence.

But this is not reality: authors write nine to five regardless of any “inspiration”, they rewrite the same passage countless of times and they most often produce their best work when they are old. Newton didn’t discover gravity due to some falling apple; he had studied physics, mathematics and astronomy more than most people ever did.

I dare say that the real factor to success is always, and has always been, damn hard work and many failed attempts.

This is, however, a dangerous idea. People go to extreme lengths to deny it. For example the woman playing the lottery, believing it is the only way for her to become rich. Or the failed author blaming his empty pages on not having found the right inspiration — “yet.”

There is really no excuse for not having the capacity to achieve one’s own success. No talent? Talent is not nearly as important as the time you spend with a task, as described by Malcolm Gladwell in his Outliers (in which he also describes the importance of opportunity). No money? University is free, study loans are accessible for anyone and it doesn’t cost anything to start a company. Not “ready”? Get over it.

Why is the idea that anyone can become anything through one’s own ambition not embraced, but instead denied? Because it means complete responsibility for oneself, and the unlimited possibilities are easier shrugged off than capitalized. By some reason people are much more likely to confine themselves to a state where they believe they can’t affect their own destiny, rather than to embrace freedom. But still everyone knows that they could do anything, if they only tried. The guilt reminds them of this.

This is why successful people are mystified. By admitting that the causes for success were indeed equally accessible for everybody, the guilt is unbearable. So the choice is simple — deny the possibilities, stop thinking about it and blame everything on lucky circumstances.

With stuff I refer to anything productive and rewarding, such as a course at school, a qualified job or a project of your own. And with fun I refer to the feeling of satisfaction and purpose that is the result of doing meaningful things.

So, what can this model tell us?

• Do more, create something, engage in productiveness and a great feeling will follow.
• Eliminate wasted time to give room for more personal projects, sports or arts.
• Being overworked removes all the joy from what you’re doing.
• Make sure to find out your personal “maximum workload constant”, to know the feeling of when there’s simply too many things going on. You’ll never want to end up getting burned again.
• Remember where your limit is, and carefully balance your workload to stay just below the threshold.
• The “maximum workload constant” is not constant: it can be extended to allow for an increased capacity.
• Having too little to do is far better than being overworked.
• When you have “almost too much to do” it’s really just the right amount of work!
• If you’re engaged in stuff you like, and you are filling your time with it, you’ll hopefully experience flow.

Or as the Ruby hacker _why said:

when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

After all, it’s a thousand times more interesting to talk to someone that fills his time with interesting work and projects of his own, rather than someone completely defined by his music taste or belief. Experiences come through interaction with the real world, and they don’t create themselves — they need to be obtained through hard work. And a few leaps of faith.

The game is advertised as a “contest of intellect, lateral thinking and logical skill”. No special skills or knowledge are required, only the ability to figure out what to do and how to obtain necessary and relevant information. The tasks usually include elements of code breaking, alternate reality gaming, geocaching, deciphering, treasure hunting and various puzzles. Advanced Google skills are fundamental to solving the game, and so are endurance and thoroughness. Once a problem is solved, you move on to the next level. You usually compete in teams, but you can never know the current position of your competitors. This makes it a competition of intelligence cloaked in mystery and with a touch of psycological warfare.

There were a few tasks we made for this event that I’m a little extra proud of. I’ll explain them here, as they give a very good picture of what The Game is really about. But if the reader feels like giving the game – and these problems in particular – a try, then head over to the i-Hunt website (which will be up until November 09), and register to play. An answer sheet is also available if you get stuck and just want to try the next problem.

Stage 1, problem 5 — The Shameful One

An outbound coast
Surrounds or embraces? The city
Hamilton’s (NZ) antipode.

There are two clues here – the haiku poem and the maze image. Both can give the answer on their own, but also in combination with another. The line that is traced through the maze when solved, can be identified by the hunter as the south coast of Spain, and part of Portugal. This is what is referred to in the poem as “An outbound coast”. Furthermore, the location of the square dot indicates “The city, Hamilton’s (NZ) antipode” – which is the city of Córdoba in Spain. An antipode is a complete opposite geographical location, a rare property that Córdoba and Hamilton in New Zealand share. Córdoba is thus the password.

Stage 2, problem 3 — Who’s coming to visit today?

Have you been paying attention to the local tv-station?

In this problem, the contestants had to realize that “the local tv-station” referred to the event-specific daily Youtube broadcasts, mainly the Saturday one found here. The careful watcher will notice the announcement of a new sponsor – Tentacle Technology. However, this company is not to be found on the internet, nor did they actually show up at the venue. Instead, if the URL http://tentacletechnology.com was thought of and followed, a really fancy website was found. The password “puppet” could be found if downloading the latest press release.

Smell something fishy here? That’s because me and Fredrik made it all up; in two hours we had set up the company website, got fake sponsorship deals, marketed ourselves, staged a 31 year old corporate history, stolen product descriptions from IBM and even put together a catchy mission statement. This kind of ARG-inspired problem is one of my favourites.

Stage 2, problem 5 — Think inside the box

In this last problem, the first realization to make is that the cards are actually not part of some unspecified card game. Instead it’s a sudoku, and when solved the numbers revealed in order are 174143214192. For a hunter, this is immediately identified as the IP address 174.143.214.192, and one of the first things to do with an IP is to HTTP it. When done so, a simple website containing the following image was found:

Again, the experienced contenstant would identified the erect and fallen cans as morse code. When deciphered, the final password was “wey“.

* * *

At Dreamhack we attract ~600 players, and at the i-Hunt we managed to get 200 registered players which should be considered good, since it was the first game in the UK for us. However, it looks like I’ll be going back there soon, as I’ll probably be arranging the i-Hunt three times a year in total – which feels great! I’m looking forward to get to know Britain more, as well as to work with creating and further evolving The Game.