Filter
Top Products
RTR Terminology
connection to the current router is maintained until the current
router fails or connections to it are lost.
All RTR software components can reside on a single node but
are typically deployed on different nodes to achieve modularity,
scalability, and redundancy for availability. During initial
application development, it can be convenient to use a single
physical node for all RTR roles and application software.
With different physical systems, if one node goes down or off
line, another router or backend node can take over application
processing. In a slightly different configuration, you could have
an application that uses an external applet component running
on a browser that connects to a client running on the RTR
frontend. Such a configuration is shown in Figure 1–8. In the
figure, the applet is separate from but connects to the client
application written to work directly with RTR.
Figure 1–8 Browser Applet Configuration
RTR FrontendPC Browser
Web Server
Process
RTR Client
Application
Applet
VM-0826A-AI
The RTR client application could be an ASP (Active Server Page)
or a process interfacing to the webserver through a standard
interface such as CGI (Common Gateway Interface) script.
RTR provides automatic software failure tolerance and failure
recovery in multinode environments by sustaining transaction
integrity in spite of hardware, communications, application, or
site failures. This automatic failover and recovery of service can
exploit redundant or underutilized hardware and network links.
1–12 Introduction