Falcetto
Rapid Prototyping of Computer Simulations
Introduction
History
Modeling
Simulation
Server Side
Visualization
GUI
Community

Server Side – How remote servers are leveraged

 

Server Side Functionality

                The JS and HTML application will run Client Side, and be free for anyone to use, but Server Side functionality will be available for subscribers.  The Server Side features will allow the User to perform processing intense tasks on a Server rather than their own Device, and also to perform some tasks that will not be available on the JS/HTML version.

                The User will need an internet connection while sending commands to the Server, and for when they retrieve the results from the Server.  In between sending the command and retrieving the results, the User does not need an internet connection, nor do they even need to keep Falcetto running.   This means a User could start a Simulation from their phone as they leave home for school/work, then retrieve the results later in the day, all the while their phone is not burning up power running Falcetto.

Benefits of Server Side processing:

1)      Does not use power on the User’s Device.  Power consumption is especially important if the User’s Device is running on a battery, such as a smartphone while at school.

2)      After sending a command to the Server, Falcetto can be shutdown, or used offline.  The results can be retrieved later, at the User’s convenience.

3)      The potential for speed.  The Server can use multiple cores to do parallel processing, which is something that JS does not allow yet.  Also, each core on the Server could be more powerful than the processor on Devices such as smartphones.

4)      Multiple commands can be sent to the Server.  This allows the User to use Falcetto to run multiple Simulations at the same time, rather than one at a time like they would on their own Device.

Features unique to Server Side processing:

1)      Rendering an animation of the Simulation.  Normally, the user can play a Simulation through the Falcetto software on their Device.  Using the Server Side rendering, they would be able to have a video that they can email, or post on YouTube, allowing people to see the Simulation without needing a copy of Falcetto themselves.

 

Subscriptions

                The Falcetto application is free for anyone to use, but a subscription is required for access to Server Side features.  Server commands are queued for execution, and will experience some level of delay before being processed.  Different tiers of subscriptions provide different levels of responsiveness and queue prioritization by the servers.  Just like shared hosting services, the greater the subscription, the greater portion of the server(s) the User is paying for, and thus the greater their priority for access.  This allows a typical User to have inexpensive access to Server Side features, while a professional User can have the responsiveness they need for their daily work.

                Subscription rates are based on expected utilization.  Usage charts will be available in the User’s account information site.  If a basic subscription holder has abnormally high usage, they want to consider upgrading to a higher subscription.  Similarly, if a professional subscription holder is not using their account much, they may want to consider downgrading.  Each tier will experience different priorities in queuing, or be run on different hardware.

Basic Subscriptions

                The basic subscription is a low cost way to access the Server Side functionality.  The primary purpose of holding this type of subscription would be to have access to the features not available in the free application.  Performing tasks like Server Side processing may not take less time than running it on the User’s own Device, but at the very least won’t use up the User’s Device’s battery, and can be performed while the User is on commute.  On occasion, a more powerful server may pick up a task for a basic subscriber, resulting in faster processing.

Business-Class Subscriptions

                These exist in between the basic and professional subscription plans.  This is mostly for basic subscribers that use Falcetto enough to want a better subscription, or for professional subscribers that don’t use Falcetto quite enough to justify the top subscription.  It will experience prioritization in between basic and professional, and/or be run on hardware that is in between basic and professional.

Professional Subscriptions

                These are for Users that have complicated Models they need processed, and they need them processed “now.”  These Users are likely sitting at their computer awaiting the results, so the server responsiveness directly affects their personal job performance.  Tasks for these subscribers will have higher queue priority, and/or be run on more powerful hardware.

Teacher Subscriptions

                During a class in school, it may be useful for students to have Server Side subscriptions.  Requiring all students in a class to purchase Server Side subscriptions is unrealistic, but a Teacher subscription will allow a teacher to provide basic Server Side subscriptions to their students during the semester.  With all their students possessing a subscription, the teacher has more options when it comes to assignments.  They can assign tasks such as “submit a video file,” or provide their students with Black Box Models to create Simulations with.  The subscriptions will also allow the student to access the Community features that the teacher chooses.  If a student receives subscriptions from multiple teachers, then their account will have access to all the Community features unlocked by each teacher.

 

Parallelism

                Falcetto can make great use of parallel processors.  Currently, parallel processing is only planned as a Server Side feature, due to the current limits of JS.  The simulation paradigms all utilize the results from the previous processing cycle, and never try to intermingle “current” data with “previous” data, which allows each element to be processed completely separately from other elements within a processing cycle.  After each Element is processed, the data will be collated, and the newly collated data will be what is used by the Elements in the next processing cycle.

This demonstrates how data is collated, then distributed for parallel processing. The process repeats for each processing cycle.

                When running in a browser, the simulation needs to worry about pausing its processing occasionally to allow the browser to do other processing.  If JS runs for a long time without pausing, the web browser will complain and want to stop it from running.  Falcetto will handle this pause/resume cycle, yet another task the User does not need to learn to program.  The pause/resume allows the browser to perform other tasks, effectively performing multi-tasking within the browser.  This allows the User to use other browser tabs, or even to perform other Falcetto tasks while a simulation is running.

 

Server Architecture

                The Server Side architecture will consist of the following functions, spread across as many servers as needed:  web server for JS/HTML delivery (referred to as Web Server), landing server for load balancing (referred to as Landing Server), Server Side functionality handlers (referred to as Handlers), Server Side task dispatchers (referred to as Dispatchers), and Server Side task processors (referred to as Processors).  The Web Server just has to allow Users to download the JS/HTML Falcetto application (referred to as Application), and can easily be mirrored on other web servers (such as on a school server, or on a non-internet network).  The Landing Server will be the server the Application initially talks to, performs authentication for subscribers, delivers messages (announcements, or outage alerts), and set up a session with a Handler for the Application to communicate to when applicable.  The Handler will be what communicates with the Application throughout a session, as it will receive commands from the Application, notify the Application of completed results, and deliver the results to the Application.  The Dispatcher will receive new data from the Handlers, queue the commands, deliver the commands to the Processors when ready, and receive results from the Processors to deliver back to the Handlers.  The Processors will perform whatever command is given them by the Dispatchers, and deliver the results back to the Dispatcher.

Server Side processor servers (referred to as Processors) may be specialized, and thus prefer commands of certain types or complexities.  Most of the Processors will be Cloud based servers (as will Dispatchers, and Handlers) that can be added or removed as use of Falcetto increases or decreases, such as a sudden spike in usage near school finals time.  Some Processors may have highly specialized hardware to handle particular situations, such as having a strong graphics card to render movies, or an abnormally large number of cores for simulations that have many more elements than normal.  The special Processors will also live at a different site, to allow Ether Tear to have physical access.

In the early stages of development, or while Falcetto usage is exceptionally low, some servers may perform multiple functions.  The Web Server, Landing Server, Handler, and Dispatcher may all live on the same server in the beginning, while the first Processor will be a “spare” computer available at Ether Tear.  As usage grows, the functionality will split out until each function is being performed by its own server, or multiple servers in some cases.

This demonstrates how the User's Device (on the left) will communicate with the Web Server (W), the Landing Server (L), the Handlers (H), the Dispatchers (D), and Processors (P). Many of the servers live inside the Cloud. The special purpose Processor is marked with a lightning bolt, and lives outside the Cloud.

Different cloud service architectures may result in changes as well.  The above description assumes a traditional leasing scheme, where the servers are leased and paid for, regardless of usage.  This scheme would require efficient management of how many servers are used, and effective management of the job queue, to ensure higher priority subscriptions get processed sooner.  Some cloud services use a per-hour model though, and allow selection of different hardware configurations.  For such a cloud service, all jobs would be able to be started in a timely manner, but may run on different hardware configurations depending on the subscription priority.  For instance, a basic subscription may be run on hardware that is roughly equivalent to running it on a personal computer, while a professional subscription may be run on something ten times more powerful.  The cost versus power increase is not linear though, so a machine that is ten times more powerful may cost fifty times more to lease, hence one aspect of the disparity of cost between subscriptions.



Content ©2014-2017 Ether Tear LLC. Website powered by Ether Tear LLC, ©2013-2017