Show TOC

 Configuring the Polling TypeLocate this document in the navigation structure

Use

For security reasons, the Internet imposes certain limitations on server-client interactions; for example, a server cannot initiate contact with a client. To overcome this restriction in the Collaboration environment, a polling type was developed to support certain components, such as RTC. Polling enables clients (portal end users) to interact with one another using the RTC as an intermediary point of contact.

RTC uses the Real-Time Messaging Framework (RTMF) as an infrastructure for transferring messages between clients and servers in the portal environment. Portal clients are connected to the RTMF through an RTC client running in a hidden frame in their portal browser.

Examples of events controlled by RTMF:

  • Instant messaging.Messages are sent from user to user via the RTC. The sender's message is stored in the server. The targeted recipient picks up the message from the server. See figure below for an example.
  • Session invitations.Portal users send invitations to other users to join application sharing sessions. The session host's invitation is stored in the portal server. The targeted participants pick up the invitation from the server. Each participant's reply is sent back to the host via the RTC in the same manner.
  • Availability status. Portal users register to an event. RTMF monitors which user is registered for the duration of the session.
  • Session-specific tasks. For example, during an application sharing session, a participant's request to take control of the host's cursor and the subsequent response by the host is also controlled by the polling type via the portal server.
  • Online/offline status. Via RTMF, the portal server tracks which users are logged on.

RTMF does not affect the Application Sharing Server. The streaming of data in an application sharing session is managed solely by the Application Sharing Server.

Every RTMF-based client sends an automated request to the RTMF every number of seconds to check if messages have been sent to it. The time between each check is commonly referred to as the polling interval. The polling type, if not configured properly, has the potential to generate load on the portal server as the total number of users increases.

The figure above illustrates two clients communicating through instant messaging. The events are logged chronological from top to bottom. In this example, each client polls the portal server, via the RTMF, at regular 3 second intervals.

 

You can configure the polling interval and what to consider to vary and limit the load generated by the polling type. You choose the polling policy which best suits your environment, and then configure the parameters relevant to that scenario. 

While configuring the polling settings so that the system does not become overloaded, you need to make sure that end users do not notice a major decrease in performance over time. Keep in mind that the greater the polling interval, the less frequently users receive updates.