Introduction

When I'm feeling philosophical, I sometimes say "Implementing Server Based Computing is a piece of cake as long as you are on a LAN". Although this is a bit blunt, it is kind of true. A lot of the issues (problems) that you face when troubleshooting Server Based Computing environments are related to the network that users are connecting over.  This is especially true for wide area connections (WANs). When you need to troubleshoot such an environment, you need to "use" the offending network connection. Due to obvious reasons this is not always possible. There are wonderful devices you can buy to simulate all kinds of different networks but these usually cost tens of thousands of dollars. In this article I will show you how you can simulate poor WAN connections by using free tools.

Why WAN?

Before we get into simulating a poor network connection we need to take a look at the question why are WANs usually the culprit. WANs are usually the slower connections that clients use to connect to Terminal Servers or Citrix servers. WANs main characteristics are that they are limited in bandwidth and high in latency. Although ICA and RDP by their nature do not require that much bandwidth, they are very sensitive to latency. In fact, latency is an absolute killer in Terminal Server and Citrix environments. It's as simple as that.

Latency, as you all know, is about the time it takes for a packet to travel to the server and back again (roundtrip time). Clients by the very nature of the RDP and ICA protocol are dependent on the server responses for their screen updates. Any delay in screen updates impacts the perceived performance for the user. Depending on the application and - even more importantly - what users are willing to put up with, you usually need to stay below a latency of about 250 ms to get acceptable performance. Latency also increases as the packet size decreases. Because Citrix often sends very small packets, this makes the user experience even worse on high latency connections. Even if you have a low latency connection, there's no guarantee that you will never have any latency. This is because latency and bandwidth have a special relationship. Once your bandwidth is saturated, latency soon increases tremendously. Think of this as a highway. When the highway is full of cars chances are that you won't be able to drive at the maximum speed. You will probably arrive (a lot) later at your destination.

Building a Slow Network

Now that you know what a slow network connection consists of, let's make one for ourselves. What we need are tools to simulate a low bandwidth, high latency connection perhaps even with some packet loss. First let's start with creating a low bandwidth connection. A tool I often use for this is NetLimiter. We will need the Pro version. This version is not free but if you need to troubleshoot a certain issue you can download a fully functional 28 day trial. NetLimiter is a very cool tool (that btw mostly is used to limit the connection speed of certain peer-to-peer filesharing programs) that allows you to monitor the up- and download speed for any process running on your system. The coolest feature however is that you can limit the bandwidth per process. You can use this ability in two ways:

1.  You can install it on the Citrix Server and limit the incoming bandwidth.
2. You can install it on the Client machine and limit the outgoing bandwidth for the client.

I prefer to use the second option. Simply download the NetLimiter trial on your client and limit the ICA Client (the wfica32.exe process) to the amount of bandwidth you want to simulate. When you use the tool you'll be able to learn a lot about the network bandwidth which different processes on your system use. Pay special attention to the wfica32.exe process...

Incoming traffic is the traffic you receive from the Citrix Server (largely display data) and Outgoing traffic is the traffic your client sends to the Citrix server (mouse movements and keystrokes). Notice the checkbox behind the speed. This is where you can limit the up- or download for each process.

Another phenomenon that you might need to simulate on your connection is latency. This is the cool stuff. The talented Mr. Tim Mangan has created a *free* tool  to allow you to simulate network latency. You can even simulate packet loss! This tool is called TMnetsim and is freely downloadable from his site, Tmurgent.com. Again, you have several options on where you can implement this tool. You can install it on the client or on the Citrix server. I prefer to use the tool on the Citrix Server. The way the tool works is that it acts as proxy server. When you fire it up on your server you need to set up a port that it listens on and then configure the port it should forward the connection to. Before it forwards the client's traffic to the "actual" Citrix server (port 1494) it adds the latency you configure. On a typical Citrix server the setup would look like this:

On the upper left corner of TMnetsim (Inbound Connection) you configure the port TMnetsim "proxy" listens on. This is the port you need to connect to. On the right of this is the outbound connection. In this case it forwards the connection to the local host (since TMnetsim is running on the Citrix server itself) to the true Citrix port (1494). In the center you can see that I've specified a latency of 250 ms with 25ms of jitter. This  means that the latency is variable from 225-275 ms. This is a very realistic simulation because often latency is far from static. This way anyone connecting through TMnetsim experiences the  delay I've configured. Note that the delay applies to Inbound traffic (to the Citrix server).

The only thing you need to do after this is to configure your ICA Client to connect to the port TMnetsim is listening on. The easiest way to do this is to save an ICA file of a Citrix Published Application and edit it. You need to find the  Address line in the ICA file. See the bold section of this sample ICA file below. You need to add the port number you configured in TMnetsim, with a semicolon.

Once you've got this set up you can start testing what it is you want to test.  So how do you know that your connection is indeed being lagged by latency? Well, let Citrix tell you. Just fire up performance monitor on the Citrix Server and locate the ICA session object. Select the "Latency Last Recorded" counter and select your connected Citrix session. If you configured everything correctly you should now see the latency on your connection, you configured in TMnetsim (give or take a few milliseconds).

If you set things up correctly then you can even change the characteristics of the connection on the fly. Play around with it and see what latency and/or limited bandwidth do to your connection. Especially the combination of limited bandwidth and corresponding latency is very interesting to see. I will be publishing a Thincomputing.net Premo that delves into these kinds of issues.

This setup of course isn't  just for Terminal Server or Citrix environments. For example, you could test it to see how certain replication topologies deal with poor network connectivity or how your company's new web application responds to high latency.

Conclusion

In this article I showed you how you can simulate poor network connectivity quickly and easily and without spending thousands of dollars. This does not just apply to Terminal Server or Citrix environments but for all kinds of different environments. Go ahead and give it a try. You will learn a lot in the process!

This article was previously published at MSTerminalServices.org.