Home Development Blog Multi-tier...
Multi-tier... PDF Print E-mail
User Rating: / 0
Wednesday, 29 September 2010 09:33

From the initial concepts that I had formed, it became clear to me that I was looking at a multi-tier project - which is just as well, since one of the aims of the project was to provide a demonstration of exactly that...

Before going into my project planning I decided - as a feasibility check - to have a quick look at these tiers and some of the interfaces between them.

The tiers that I identified were:

  • A client tier;  web, and/or mobile apps.   The actual meat of the operation...
  • A Web/application tier providing the support for the clients. (e.g. Access to the puzles, static information, forums etc.)
  • A back end tier providing the puzzle, user and static content management.   i.e. a database.



The interface between the clients and the applicaton tier would be some form of remote procedure call and would support the following operations:


GetPuzzle(UserID), GetPuzzle(UserID,PuzzleID) returns PuzzleRequest

GetPartialSolution(UserID,PuzzleID) - returns a PuzzleRequest with a partially compelted solution saved from a previous attempt

data object PuzzleRequest contains:

  • UserID
  • PuzzleID
  • RequestID (Unique id, identifying one attempt to solve the puzzle)
  • Cipher text with spaces and punctuation
  • Cipher ID (some identification of the type of cipher used
  • Hint Checklist - list of hints available or used.
  • Cipher Alphabets - set of cipher alphabets created by user when trying to solve the puzzle.   May be emtpy for a new request.
  • Status (i.e. new, saved, solved)

SubmitSolution(UserID,PuzzleID,RequestID,SHA (over Solution Text),HintsUsed)

enum HintType, e.g. ShowWhitespace, FrequencyAnalysis, ShowLetterE, ShowNumber of Alphabets, etc.

CheckHintAvailability(PuzzleID) returns a set of HintTypes showing which hints ares available for a given puzzle.

GetHint(UserID,PuzzleID,RequestID,HintType) returns HintData and also remembers that the user asked for this hint for this puzzle.



The Database would have the following tables (I have not listed the individual fields since firstly, they have changed and secondly, I don't think that I want everyone to know that much about my database.):

Users - all those entitled to solve puzzles.

Admins - Those users entitled to submit puzzles and carry out other admin tasks.

Puzzles - all the relevant data about a puzzle.

Requests - one request would be an attempt by one user to solve one puzzle.   One created (by the first attempt to solve the puzzle), all subsequent attempts would continue to use the same request.   This is also where information about partial solutions can be saved by the user.

Hints - Useful information that a user can have view to make solving a puzzle easier.   Access to these will be recorded, so we can tell which clues a user actually used in solving a puzzle.  (Someone creating two users to allow one of them to cheat is problem we will have to solve later.)

Solutions - When the user submits a correct solution then this table is where it is recorded, together with information such as time taken, hints used, etc.



My conclusion was that there was nothing insupportably difficult and I decided to go ahead.   My next installment will describe my approach to planning the work involved in the project.

Copyright © 2019 Crypto League. All Rights Reserved.
Joomla! is Free Software released under the GNU/GPL License.