Elenesski Object Database  EODB and NEODB
The Memento Pattern Database for Unity
30 Network - Architecture

IMPORTANT: NEODB is currently undergoing detailed beta testing is not currently available. It will be released shortly.

Overview

NEODB is an add-on for the Elenesski Object Database (EODB). It uses the same data format as EODB but instead of storing data locally, it stores data in a mySQL database on a HTTP connected PHP Server. NEODB supports:

  • A central database for capabilities such as user profiles, top scores, game lobbies, etc.
  • Near real time communication between clients, where clients can be updated every once every two seconds or so. Such turn-based games, synchronized games (connected single player games), etc.

NEODB incorporates several practices related to it's architecture and security, however here are limits to the level of security any solution can offer. These are the things you need to keep in mind if you decide to store your data remotely:

Latency (network, database, processing) is a huge application killer if the time between a client request and data served is long. We dedicate a very large portion of the documentation to this issue to help you understand this area, so that you can avoid typical searching pitfalls and transform long queries into shorter ones. NEODB offers class searching plus 11 core search methods and each method offer 12 combinations each for a total of 133 ways to search. One of these 133 ways to search should be adequate to find all the data you need for your app's search needs, without requiring multiple round-trips. If it doesn't one of these search methods plus Intelligent Indexes can fill in the gap. See "32 Network - Understanding Latency" (in the main menu) for more information; there is an example near the bottom that identifies how to use Indexes in intelligent ways to implement a top 100 list.

SQL Injection occurs when SQL statements are generated prior to being executed. It occurs when user data is appended to the SQL statement that is generated. For example, "'; show tables;". Carefully crafted statements can be used to explore your database. While NEODB generates SQL statements, any data provided by a app user is linked to the SQL statement via parameters. So a 3rd party injection attempt results in no data being found rather than a way for a 3rd party to inject SQL into your system.

Hijacking occurs by a 3rd party using the same parameters as the app to communicate with your server. To prevent a "man-in-the-middle" attack who has a network sniffer, you need to implement an SSL certificate on your HTTPS server. It's the only way to guarantee that they cannot intercept the communication. NEODB has some basic features to deter hijacking, but without HTTPS/SSL there is no way to prevent it.

Hijacking Note: It's common for sniffers to exist on public wifi networks. So remember to protect yourself and only use HTTPS to connect to sites when you are entering your security or financial information.

Impersonation occurs when a hacker has decompiled the app and figures out the logic for communicating between the app and server, and then creates an alternate program to mimic the communication. Important, NEODB does NOT provide any protection for Impersonation. In fact, every app is distributed to 3rd parties is subject to impersonation. The best defence against this kind of attack is to not store private, important, confidential, sensitive or secret information in your database or anything else that would make your environment a target for hackers and to back up your environment frequently.

Problems with Asynchronous Coding

Unity 5.2 (or earlier) does not support "await", therefore, you cannot code a method that mimics a synchronous method call. To call NEODB you need to code asynchronous calls. This means a message is sent to the server in the background without affecting the main thread. Then it returns a message to you. On the surface, asynchronous coding doesn't seem like all that big of a deal or problem.

If you

While NEODB supports multiple calls, at the expense of memory and CPU (see next), a problem occurs with logic sequencing. If you make three calls to NEODB, A, B and C, there is no guarantee that the order you call them in is the same sequence that returns or that a given step will return at all. This makes it difficult to sequence logic.

While NEODBChain allows for logic to be sequenced with condition, but it becomes a challenge because you have to define the sequence and the logic conditions, before you can start the logic unlike regular C# calls, where you make a call and wait for a return.

This subtle difference makes asynchronous programming a challenge.

NEODB Multiple Call Support (and pitfalls)

NEODB supports multiple calls, at the expense of memory and CPU. It each call works by creating a coroutine that makes a call to the server via a WWWForm. When the form is called, the logic is stalled until the server responds or the coroutine times out.

Each call you make uses up system resources which are held until the thread completes. It's better to use NEODBChain to sequence multiple steps than to run them in parallel, but only you can decide which is better for you in terms of execution.

Since NEODB uses coroutines, CPU is used to manage the coroutine. For every frame, Unity tests to see if a coroutine has completed. While this logic is largely very fast, having several active coroutines will eat into your CPU availability.

If parallel logic is not required, consider using the NEODBChain to sequence your logic to be more memory and CPU efficient.

High Level Communication

The following sequence provides a high level overview of the interaction between your APP and NEODB for getting a session, saving some data and searching for some data. It shows the how your APP interacts with NEODB and how NEODB interacts with EODB and the PHP Server.

NEODBArchitecture.png
NEODB, Networked Object Database Overview