Introduction to SoftGrid networking


This article describes SoftGrid networking. This article contains a high-level introduction to the streaming protocols that are used with SoftGrid. This article also describes the way that these protocols interact with load balancers and with firewalls.

More Information


The SoftGrid Platform uses the Real Time Streaming Protocol (RTSP), the Real Time Transport Protocol (RTP), and the Real Time Control Protocol (RTCP) to deliver sequenced applications to SoftGrid clients, as follows:
                 Ports               Ports
[**] <--- RTSP ---> [554]
SoftGrid Client [**] <--- RTP ---> [***] SoftGrid Server
[**] <--- RTCP ---> [***]

** Client ports are in the range of 1024-49151.
*** Server ports are in the range of 49152-65535.
NOTE: Port 554 can be changed.
RTSP is an application-level protocol that controls the transport of multimedia content, of session announcements, and of teardowns. RTP and RTCP are used to deliver the actual media. RTCP controls streaming of the media for Quality of Service (QOS). The media data is transported by using RTP. These protocols are used for a variety of applications. These applications include audio applications, video applications, and streaming applications.

To stream applications, the SoftGrid platform uses three channels that are carried through three sockets. First, the SoftGrid client uses the RTSP channel to set up a connection with the SoftGrid server. The server opens two private ports for the RTP channel and for the RTCP channel. The server also sends the port numbers to the client in a response. The client then opens two sockets. Then, the client connects to the private ports that are created on the server. The application is then streamed over the RTP channel. The RTCP channel provides real-time control over the data channel.

For each application that is streamed to a SoftGrid client, a new set of RTP and RTCP channels are created. However, all streamed applications use one common RTSP channel. The RTSP channel is also used to discover available applications on the SoftGrid server.

The SoftGrid platform supports Unicast connections over TCP. The SoftGrid platform does not support multicast connections or UDP connections.

Use RTSP, RTP, and RTCP over TLS

| Firewall |
| |
Port | | Port
SoftGrid [**] <---(RTSP, RTP, RTCP)---> [332] SoftGrid
Client | TLS | Server
| |

** Client port is in the range of 1024-49151.
Note: Server port is 332 unless changed.
An additional protocol, Transport Layer Security (TLS), can be used to encapsulate all network traffic and to encrypt all network traffic between SoftGrid clients and SoftGrid servers. TLS is a version of Secure Sockets Layer (SSL). By default, TLS uses port 332. However, the port number can be changed.

The URLs in the .osd file must be updated to use RTSPS, as follows:
For more information about how to set up the SoftGrid platform with TLS, click the following article number to view the article in the Microsoft Knowledge Base:

930870 How to enable secure connections


If a firewall device exists between the SoftGrid systems, or if the systems are running firewall software, the device or the software must be configured to enable port traffic for SoftGrid.


By default, the SoftGrid client and SoftGrid virtual application server communicate by using RTSP protocol over port 554. If RTSP is used, TCP port 554 and TCP port range 49152-65535 must be opened. If RTSPS is used, TCP port 332 must be opened.

Desktop configuration refresh

In the SoftGrid Management Console, the .osd files and the .ico files can be configured to use HTTP or to use UNC. When a desktop configuration refresh is performed, the SoftGrid client pulls the .osd files and the .ico files from the HTTP path or from the UNC path. If HTTP is used, port 80 must be opened. If HTTPS is used, port 443 must be opened. If UNC is used, TCP port 139 and TCP port 445 must be opened. Additionally, if UNC is used, UDP port 137 and UDP port 138 must be opened.

Note These ports may vary depending on your environment. Contact the network administrator for more information.

Load balancers

A load balancer divides the work of one server between two or more servers so that more work can be completed at the same time. The load balancer distributes incoming requests so that the administrator can provide a more consistent end-user experience to the users. In addition, load balancers enable an organization to provide improved availability by incorporating redundancy. For example, if five servers are required to service the user base, and you use a load balancer, seven servers can be online servicing requests. If one of the seven servers requires maintenance, the remaining six servers can service all requests. Additional servers can be added seamlessly if the user base grows.

SoftGrid servers are load balanced at layer 4 of the Open Systems Interconnection (OSI) reference model. When the SoftGrid platform is set up for load balancing, the .osd files must be changed to point to the virtual IP (VIP) address of the load balancer, as follows:
Note "" resolves to the VIP address.

Currently, the SoftGrid platform does not support layer 7 load balancing. Layer 7 load balancing is also known as application level load balancing. We recommend that the load balancer use the PING protocol to contact the SoftGrid server. Alternatively, the load balancer determine availability by periodically trying to establish a connection on the correct port of the SoftGrid server.

Because the SoftGrid server opens two high ports, and the SoftGrid client connects to the ports, a “sticky” connection is required between the SoftGrid client and the SoftGrid server. If the load balancer is not configured correctly so that the load balancer redirects all connections from one SoftGrid client to one SoftGrid server, applications do not stream. To make sure that the SoftGrid client is redirected to the least loaded SoftGrid server, we recommend that the sticky connection expire after a certain period of inactivity from a SoftGrid client. One SoftGrid client can be a terminal server. Many end-users may be logged on to that terminal server. For terminal server farms, we recommend that the sticky table be flushed periodically. For more information about how to script the flushing of the sticky table, see the documentation that the manufacturer of the load balancer provides.

Enterprise solutions should use a hardware load balancer instead of the Microsoft Windows NT Load Balancing Service (WLBS) or DNS round robin load balancing.

For performance reasons, we recommend that the Network Address Translation (NAT) feature of the hardware load balancer be disabled unless the NAT feature is required. Network traffic between the SoftGrid servers and the SoftGrid clients should bypass the load balancer after the initial request. Foundry calls this method “direct server return.” F5 calls this method “nPath routing.” If a SoftGrid server fails, the SoftGrid client seamlessly reconnects to the VIP address. Then, the SoftGrid client is load balanced to a new SoftGrid server. New high ports are then created on the new SoftGrid server so that the streaming of the application continues. There is no intrinsic advantage in hiding the IP address of the SoftGrid server from the SoftGrid client. The load balancer only has to process the incoming requests to the VIP. The load balancer does not have to process later incoming or outgoing requests from the SoftGrid server to the SoftGrid client. If the SoftGrid clients are behind a router that is performing NAT, the SoftGrid clients are all load balanced to one SoftGrid server.

For more information about how to set up the SoftGrid platform with Windows load balancing, click the following article number to view the article in the Microsoft Knowledge Base:

932018 SoftGrid networking and Windows network load balancing


Article ID: 932017 - Last Review: Mar 21, 2007 - Revision: 1