|
|
 |
Examples - RIMP Protocol The Rich Internet Media Protocol, or RIMP, is the primary component of the Webby Network software I created for SymbiontWeb; and defines the method and properties of browser and application communication through the Webby Network system. RIMP defines a method of communication which includes high-compression of identified compressible media, modulating encryption based on network properties, multi-layered communication channels for separating key processes, and client/server interactions which alter the browser and connecting applications to more efficiently handle media transfer.
RIMP can be defined as the Rich Internet Media Protocol; which provides a standard for Web browsers and servers to communicate. RIMP is a protocol that software can implement to have improved communication and media transfer abilities beyond common protocols such as HTTP. RIMP is an application layer network protocol built on top of JBT & TCP and HTTP. RIMP clients (such as Web browsers) and servers communicate via RIMP request and response messages. The three main RIMP message types are GET, POST, and HEAD, similar to HTTP. RIMP utilizes several TCP or JBT ports including port 80, 8080, 28021-28081. The current version of the software is not yet released and is based in part on the HTTP version 1.1 as documented in RFC 2068. In the OSI model, RIMP exists primarily at the Application layer delivering browser script. However, RIMP modifies the Session layer, intercepts messages at the Network layer and manages the Transport layer for each interception and pass.
RIMP Data Channels RIMP supports several channels of communication dedicated to data transfers and processing. One such channel, is the native browser interface for the "AJAX" approach, however utilizing a formulated scripting style and intercepted by RIMP facilities (Webby Client & Web Server) to be automatically encrypted and compressed for transfer and decrypted and uncompressed after transfer. Another such channel is a direct Webby Client to Webby Server to Webby Client communication via limited proprietary messaging.
RIMP Media Channels RIMP supports several channels of communication dedicated to media transfer and processing. Within RIMP are channels responsible for video streaming using the RIMP-Video Streaming method. One such channel in RIMP is the High Video Block Streaming or HVBSTM.
RIMP Video Streaming Standard video streaming within RIMP is bi-directional, meaning up and down stream are supported. The standard video streaming uses a proprietary codec to stream media over RIMP to Webby Server whereby the Web Server application can transcode the media before:
The proprietary codec is able to adjust the quality (e.g. frame rate for video or bit rate for audio) of the media to improve transfer times and to remove the need for high bandwidth connections. The transcoded media is prepared based on the dynamics of the connection, including availability, size and receiving device playback abilities.
This component of the technology has an application extension on Webby Client named "Webby Cast"; which is the video capture component I designed for SymbiontWeb. Webby Cast interfaces with the native device camera to capture (e.g. record) audio and video, transcode it and provides it to the Webby Client for RIMP streaming. The standard video streaming does not persist recorded data on the device; nor should it require the use of an external memory expansion to utilize. Live playback of streaming content means that when the receiving application is disconnected the data stream is lost during that disconnection. When the recording stream (up stream) is disconnected the recorded material is lost. *The video streaming system and channels are also used for audio streaming.
RIMP High Video Block Streaming or HVBS Advanced video streaming within RIMP is bi-directional, meaning up and down stream are supported. The video streaming is considered advanced when it uses a consistent quality format and typically is the maximum quality possible to deliver the best audio/video content. The advanced video streaming system must also utilize the block transfer method; which rather than directly streaming the media from point to point, stores the media into scalable file blocks that are than transferred one at a time to the destination. The result; if a loss in connection or transmission occurs, the block file can be re-transmitted resulting in zero stream loss. Also, the block format insures data is persistent until usage of the data is no longer required - seen as a data security and backup feature. However, the block format requires available storage for persistence, which may exceed some systems available memory. Advanced video streaming uses native codecs (typically 3G2) to transcode the media to a standard format, splice the media stream into blocks, transfer the blocks over RIMP to the Webby Server; whereby the Webby Server application can re-transcode the media if necessary before:
This component of the technology has an application extension on Webby Client named "Webby CastTM"; which is the video capture component. Webby Cast interfaces with the native device camera to capture (e.g. record) audio and video, transcode it and provide it to the Webby Client for streaming over RIMP. It is important to understand that advance video streaming persists recorded data on the device; likely requiring the use of an external memory expansion for mobile devices to utilize. Live playback of streaming content means that when the receiving application is disconnected the data stream persists until connection is restored to complete playing the media. When the recording stream (up stream) is disconnected the recorded material is saved for later broadcast. *The video streaming system and channels are also used for audio streaming.
Standard video streaming V.S. Advanced High Video Block Streaming Both audio/video streaming specifications within RIMP have dramatic differences. The Standard Video Streaming or SVS is ideally designed for live broadcasts from mobile devices due to the ability of the media to be reformatted and streamed even as the connectivity is changing; allowing for an un-interrupted broadcast. The Advanced High Video Block Streaming or AHVBS, is ideal for pre-meditated content broadcasts where assured quality and totality of the broadcast is required. However, many environments will experience longer delays in connecting and slower transmissions in delay; resulting that in lower band environments, interruptions (however without loss) will be experienced. For government applications, the AHVBS provides the highest quality format so that the media can be used as evidence. The AHVBS is designed for low-band connections and as such, a disrupted stream does not mean the loss of content or re-connection or loss of integrity.
Webby Server / AHA ServerTM - A RIMP Facility Webby Server is a server-side application that interfaces with the AHA service and is responsible for managing a specific device connection. The AHA service is responsible for managing all the Webby Server connections and facilitating the whole network. Webby Server is responsible for managing the channels of communication and directly the information to the appropriate server (VDA, Application Server, or Message Server for example). The Webby Server" application is also responsible for transcoding content (image, video, sound) going down-stream and providing encryption, Reflection, and Normalization.
Webby Client Webby Client is a client-side device application and/or plug-in to the browser which interfaces with Webby Server and the AHA service to provide RIMP, Reflection, Compression, and Normalization. Webby Client is also responsible for providing access to the hardware layer including file access, drivers, and non-restricted services of the OS. One such device that can be accessed is a printer for example, for printing from the web application interface.
RIMP Reflection Reflection is primarily the technique of intercepting requests for media content and determining if the request is valid. Requests are invalid if native or RIMP caching already has a copy persistently available or accessible through a multicast connection. If the request is determined to be valid, the order, the RIMP adjusted quality and in some situations, the quantities of distribution are determined. The Reflection process handled at both the Webby Server and Webby Client than facilitates the request; controlling the browser. Moreover, Reflection micro-manages browser execution of content media to improve performance.
Client-Side Reflection intercepts browser requests for images, video and sound files to determine the best configuration for the completion of a browser web page load. In many situations, images are cached but the browser must still make a connection to determine if a download is necessary. The Reflection process better tracks this information and in most cases can prevent the request from being fulfilled - reducing network traffic and browser page load time. If the Normalization process factors a low Normalization rate, media may be transcoded by the Webby Client" or Webby Sever (depending on which end the Reflection process is occurring) and reduced to meet the demands. Images can be resized, video can be reduced in frame rate or quality and sound can be resampled to meet the demands of the device. The result is a page, which downloads faster, is processed and loaded faster, and responds better in low-memory environments. Client-Side Reflection does not mean the process is limited only to the client device, it simply means the process is focused on client content upload/downloads.
Server-Side Reflection is a component of Webby Server and Webby Client which multi-casts files, usually media. This feature is not widely used because most interactions to the system are peer to server and server to peer. In true peer-to-peer environments, multi-casting has significant benefits including reducing server traffic. Server-Side Reflection does however create a semi-persistent runtime of transcoded files and media so that multiple requests for the same media do not require the re-transcoding of the media. This reduces significantly the overhead of the server on frequently accessed videos, images, or music.
RIMP Compression The RIMP Compression technique interfaces with both the Webby Client upload and Webby Server transmissions to determine content types which are un-compressed, and should be compressed. MPEG video files for example should not be compressed while text files including a Microsoft Word or HTML page should be compressed prior to transmission. The integrated Webby Server / Webby Client RIMP service handles it transparently without application or user interface.
RIMP Normalization Normalizing is the process of controlling the flow of data based on the dynamics of the connection, preventing disruption of application performance when connectivity is unstable and providing result data to connecting applications so that the source can be altered to fit the connectivity capabilities. Normalization is an important component to RIMP, in that it stabilizes the flow of information across the network - especially in low-band mobile connections. The Normalizing technique occurs in both the Webby Server and Webby Client applications and consists of the three processes:
Performance Expectations The Webby Network technology is best applied to the following situations:
The Webby Network technology will be slower and/or less effective than native systems in the following situations:
General Terms Network Protocol: A network protocol defines a "language" of rules and conventions for communication between network devices. A protocol includes formatting rules that specify how data is packaged into messages. It also may include conventions like message acknowledgement or data compression to support reliable and/or high-performance network communication. TCP: Transmission Control Protocol (TCP) and Internet Protocol (IP) are two distinct network protocols, technically speaking. TCP and IP are so commonly used together, however, that TCP/IP has become standard terminology to refer to either or both of the protocols. IP corresponds to the Network layer (Layer 3) in the OSI model, whereas TCP corresponds to the Transport layer (Layer 4) in OSI. In other words, the term TCP/IP refers to network communications where the TCP transport is used to deliver data across IP networks. The average person on the Internet works in a predominately TCP/IP environment. Web browsers, for example, use TCP/IP to communicate with Web servers.
IP: IP is probably the world's single most popular network protocol. Data travels over an IP-based network in the form of packets; each IP packet includes both a header (that specifies source, destination, and other information about the data) and the message data itself.
FTP: FTP allows you to transfer files between two computers on the Internet. FTP is a simple network protocol based on Internet Protocol and also a term used when referring to the process of copying files when using FTP technology. To transfer files with FTP, you use a program often called the "client." The FTP client program initiates a connection to a remote computer running FTP "server" software. After the connection is established, the client can choose to send and/or receive copies of files, singly or in groups. To connect to an FTP server, a client requires a username and password as set by the administrator of the server. Many public FTP archives follow a special convention for that accepts a username of "anonymous." Simple FTP clients are included with most network operating systems, but most of these clients (such as FTP.EXE on Windows) support a relatively unfriendly command-line interface. Many alternative freeware / shareware third-party FTP clients have been developed that support graphic user interfaces (GUIs) and additional convenience features. In any FTP interface, clients identify the FTP server either by its IP address (such as 192.168.0.1) or by its host name (such as ftp.about.com). FTP supports two modes of data transfer: plain text (ASCII), and binary. You set the mode in the FTP client. A common error when using FTP is attempting to transfer a binary file (such as a program or music file) while in text mode, causing the transferred file to be unusable. |
||
|
Home | Shop | Projects | Skills | My Lab | WebOS | Mobile | Websites |