APIs
 

- Optical Carrier Data Base.

Developed For use initially within GRDB Alone, it was then recognized that if this API was developed as an entirely external instance which can be called by any application that uses its global routines... then it would be MUCH easier to release OCTP relating software, and on the programming and developing end... make life that much easier.  OCDB is commonly refered to as an API because of it's purpose, however what OCDB really is is a collection of API's or an overall scheme in which our programs communicate and adhere to. OCDB uses a variation of the Microsoft COM OLE DB Model, which allows for use of Object Embedding, Linking, and dynamically refering in the presence of compound or multi document interfaces. It also takes some ideas from the OCDB model (hence our backronym name) which is a standard proposed to the IETF that draws our specifications for open connect databases and how they shall be accessed and handled on the internet or networks. OCDB takes this several steps further, but generally, adhere to the same overall element. The Objective of OCDB was to allow all the features we at OCTP developed, to be used by other programms OR even by ourselves, without the neccesity to re-program entire software, or redundatly re-write the same functions for new wave applications, or just... well just NEW applications. So we came up with the idea to create a kind of autonomous SDK. Which allows all the features programmed around GRDB and (other) OCTP Software to be gained, used, and employed on the fly, through methods and logic which is supplied by our realtime OCDB virtual Machine & engine. This works fantastic for us when creating tools that must compationately communicate with GRDB or another OCTP Data handling code entity. While at the same time allowing other 3rd party developers to write around the OCTP API to utilize our powerfull Application Development ideas and Encryption scheme... (without having to learn to port to complex *i386 or script wrappers in C/.NET C++ or OLE(which is inherintly a slow manifest)). It was decided by myself (OC) that it was a bold and neccessary move to create this API, which allows subsequent versions of GRDB or smaller utility Apps or bundle-App to utilize the GRDB type Database engine much the same way common programs use the windows "Common Dialog" control to "save-as" "Open" "print" etc... The Concept is exactly the Same... With the use of many many wrappers and looping, all with hardcoded 2GL Assembler... This was achieved. Now Rather than re-programming all these Encryption engines and algorithms over and over... OCDB now allow the application to call them from a central API functionset which is installed on the windows machine, and contained in the form of several *.DLL libraries, a registry block, a couple binaries for class instancing and structuring, runtime variables, error handling, windows message handling, a few Active X Objects (which allows OCDB to be used on the web) etc... The OCDB package also contains referers to the encryption methods and preprocesses to security for OCTP programming, this method of pre-handling allows work to be evenly distributed throughout the application matrix. This is where actual Development ARCHITECTURE pays off... and the use of Low residing non intrusive effecient code, and coding skills as well. We have achieved a thing of minor beauty here at OCNET/OCTP we believe. All aspects of our software are designed for harmony, and OCDB is our alto-soprano. Overall as far as data-handling, putting aside the API functionset features of OCDB...The results from the newest versions of GRDB benchmark(OCDB was released in version 1.00.3x) which is approx. Version 1.4.42 +/-. is a 37% increase in thread build instance per frame, And a 1/3 downsizing in time-to-live (the time in which it takes for an application to unload once the user either activates the program shutdown sequence...aggrees to "Close The Application" or hits the 'X' in some apps). These benchmark scores alone are enough for a bru-ha-ha on our part. And this wasn't even OCDB's true purpose. (on a quick note... the reason for the TTL decrease is due to the new data handling as well... normally upon close of an application all data must be returned or revoked from memory block per block or segment pushed to segment, memory must be cleared for all data AND the program itself... since OCDB(a seperate entity from GRDB) is handling data... and in the backround mind you... then GRDB simply needs to shut itself down, no more)All in all, This allowed more colorfull and animated GUI features to be added without sacraficing program efficiency. Eventually this led to more network-heavy features. As well as SKINS® **New Version Released 7/10** Final Version Certified by OCTP Staff. Shipped with GRDB Bundle. All Subsequent releases will also remain certified, until next primary version. Latest OCDB Version has new support module for compatability with GRDB Travel. Uses portable MD interface spacial noding to keep track of ascii data. The cipher and cryptographic handling is still handled by the 128b SCB2 Algorithm Encrption, Data compression is still handled by a slightly modified for size OBJ64 "cross kernel"(MIFO), MOGU engine. The only signifigant difference for the OCDB API package for GRDB Travel is the subtraction of large segments of 'repeater' code, and memory code... which allows quicker display of large complex shell and GUI banks, as well as routine compiling. This was to save physical space, as well as keep the Travel version simpler.

 

- Top/Tested Reliable Unseen/Underlying Logics and Network Routines

The Development of TRULAN was entirely for the purpose of cutting-edge network design implimentation. Like OCDB, Trulan was brought about to end the redundancy in programming the same features we developed newly in each version or revision, and centralize our network model in one system and one architecture. It is often mentioned, OCDN and TRULAN in the same sentance... this in fact is perfect because... as I mentioned before, our goal is complete harmony, and these two API's together are TRULY and UTTERLY what power GRDB, as well as the OCTP Data & Security over Network Model. Now for the feat...In order to truly employ the methods of exchange that OCTP developed for use in GRDB... Common Winsock Libraries weren't cutting it. TRULAN houses all the essential scaling, protocalls, MultiPlexers, Bit-Adders, Soft/Firmware Octectial Translation Routines(protocalls) TCP/PP/SLIP/IDP/UDP/UnPnP/PnP/PPOE/NetBUIE/NetBIOS

without relying on MS WinSock (which is outdated and lacking in entirety as far as sophistication any way you look at it) at all. TRULAN combines the fundimentals of winsock for transport, ACK, and error handling, with the cutting edge compression encryption, layering and combining techniques of OCTP developed network Algorithms in one API structure and Library system for Windows. This is the nature of TRULAN. It's suffice to say the combination of TRULAN with OCDB is quite the unbeatable matchup. **New Version Released 7/10*** Final Version Certified by OCNET Staff - shipped with GRDB Bundle.All Subsequent releases will also remain certified, until next primary version. Signifigant chances have also been represented in the TRULAN API for GRDB Travel including the subtraction of the modified socket library(winsock). And custom Transport and MU/G MUX firmware. The fundamental Trulan Kernel 'Basic Transmit and Recieve'(BTR) algorythm is all that is included in the Travel TRULAN engine. This was a primary enabler of the spacial rewards feature of GRDB Travel. Approx. 48,000 lines of hardcode where discarded/not used in the Travel socket of the New API. Making it overwhelmingly effecient...however quite bare. Travel GRDB is ONLY reccomended for Laptop users constantly on the move and in need of a portable management hub for your network. This allows the realistic Remote Administration and Handling of remote DB data, from a laptop. or Tablet PC.

 

 

 

 

4096 bit HDEC Encryption Secure

 

  © 2017 OCNET networks, All Rights Reserved.