Gone are the days of emailing and managing bank and utility accounts from a single Windows or Apple desktop computer. Today we all have a quiver of smart electronic devices we use to manage and enhance both our personal and professional lives.
Our smart devices are implemented using many heterogeneous operating systems most notably Android, iOS and Windows Phone. Each operating system has its own Software Development Kit (SDK) which application developers must learn to in order to implement their native applications. Developing native applications for each device manufacture is extremely expensive and time consuming. To reduce the development costs, many application vendors have instead implemented browser based applications.
Browser based applications have provided software vendors with several benefits. First, thanks to bootstrap, developers are able to write a single application that targets desktops as well as mobile devices. Second, the latest security and encryption algorithms are built into web browsers. Third, the client/server architecture is built into each browser enabling software vendors to focus on their business rather than networking. Browser based applications, however; still have several major downfalls.
Each device manufacturer and desktop operating system implements there own Internet browser. Since each implementation is slightly different, application developers are required to develop and test against each browser negating much of the cost benefits browser based applications have historically provided prior to the proliferation of smart mobile devices. To make matters worse, browser updates often change application user interface behavior requiring software vendors to rapidly react interrupting current development cycles.
Second, browser based applications ride on top slow stateless ASCII based protocol stacks and data formats, namely HTTP, REST, SOAP, JSON and XML. These ASCII based protocols transmit 100s or even 1000s times more data than is actually necessary slowing applications and overworking networks with no technical reason to back the bloat. Also, since HTTP is stateless, neither event callbacks nor variable subscriptions are supported. Instead browser based applications must poll data sources for updates further overworking the network infrastructure.
Finally, users demand good looking, highly usable, fast, responsive and powerful applications rarely obtainable in browser based applications.
Simply put, a stateful binary protocol stack with implementations for each of the major device manufactures' operating systems. A stateful protocol stack enables client applications to subscribe to variable updates and receive event notifications important in many financial, technical and defense applications. When properly implemented a binary protocol stack allows client applications to transmit data without bloat important in many data intensive applications such as music and video applications. Stateful binary protocol stacks are typically very expensive and difficult to develop and have, due to the proliferation of fast networks, computer processors and the high cost associated with application development, gone by the wayside in favor of technically inferior protocols such as HTTP, REST and SOAP.
Upper Setting offers a solution to the problem. We have developed our own network application framework, DotNetCloudServer SDK, that includes a stateful binary protocol stack we call FASTack short for Fast Access STack. Our network application framework is lightweight, secure, robust and easily implemented on any mobile or desktop operating system such as Android, iOS, Windows Phone, Windows, Mac and Unix/Linux flavors. DotNetCloudServer can handle all your networking requirements so you can focus on your business instead of networking.
Our DotNetCloudServer is implemented on Windows using the .Net Framework 4.5.2. The server uses .Net Reflection to load .Net assemblies you create that house your service functions and business logic. Our DotNetCloudServer SDK installs a Windows Service that houses the server. The Windows Service is redistributable, however; if you need to expose existing components that reside within existing services or processes, our DotNetCloudServer can be referenced directly within your already existing .Net project. So what makes FASTack so powerful, lightning secure and robust?
Remote Object Access Protocol (ROAP)
The core of our DotNetCloudServer if our Remote Object Access Protocol (ROAP). ROAP exposes your server-side component objects, methods, variables and events to your client applications. Developers create their own objects in a stand-alone assembly DLL which is then automatically loaded and started by the DotNetCloudServer. Your applications can not only remotely invoke server-side methods but can also receive immediate event notification and variable updates as they happen without costly polling mechanisms found in our competitors' products based on REST or SOAP.
Granular role and user authorization (security access permissions) can be assigned to each method, variable and event enabling systems administrators to regulate who can execute methods, receive event notifications and read as well as write variables. For example, a variable can be configured so users can read the value but only administrators can update the value.
Support is included for the latest security and encryption protocol used on the Internet now, SSL/TLS 1.2, enabling the financial, aerospace and defense industries to implement data sensitive client/server applications with our framework.
Session Layer Protocol
Our session layer protocol has been designed to minimize the amount of damage denial of service (DOS) attacks can impose yet supports large packets.
Authentication Protocol (AUTHP)
We have implemented an Authentication Protocol (AUTHP) layer that is fully extendable. Out of the box, DotNetOpenServer supports Windows Authentication, however; any authentication method can be implemented by simply extending our simple base authentication class.
Keep-Alive Protocol (KAP)
A common problem many stateful client/server applications encounter is the ability to expose network failures in a timely fashion. DotNetOpenServer solves this problem with our Keep-Alive Protocol (KAP) commonly referred to as a heartbeat protocol. Both the client and server send tiny packets back and forth. As soon as the heartbeat stops the framework notifies the application the network has failed enabling server-side component objects to release associated resources and notifies the end user a network failure has occurred.
Our DotNetCloudServer SDK supports all of the major smart mobile device and desktop operating systems:
- Windows Phone
- Unix/Linux flavors