Memory/CPU Optimization in Citrix

Citrix Presentation Server 4.0 introduced two resource optimization features that help increase scalability by as much as 25% and ensure a smoother user experience. These two features, memory optimization and CPU optimization, are distinct and function in unique ways. Memory and CPU optimization are not enabled by default.

Memory Optimization

When an application starts, the operating system maps application DLLs to the base memory address space. The default base memory address of applications is 0x10000000. Memory optimization works by redirecting the base memory address of applications to an alternate location. When multiple applications start and try to write to this base memory address and find it already in use, they must be relocated elsewhere. In doing so, the module code must be modified and produces a performance hit on application initialization time.With memory optimization invoked, the base memory addresses of installed applications are rebased at a predefined interval. This means that the base memory address is altered, and as such, the applications are relocated to another address automatically during initialization. The end result is that applications load faster because intermediate redirection.


During the predefined memory rebasing interval, a safe memory base address is calculated and designated. Thus, the 0x10000000 address is altered. The memory rebasing interval is set within the server farm properties, and should be scheduled during times of minimal use. Options are: startup, daily, weekly, or monthly. By default, the files listed in the HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SFO\ProcessExclusionList registry key are excluded from rebasing. Additional applications can be excluded from memory rebasing by being added to the exclusion list within farm properties memory optimization. Once added in the GUI, they will also be added to this registry key. The repair.sfo file includes the files that have been rebased, and the timestamp of the rebased DLLs will be modified to reflect the approximate time of the rebasing interval.

Some applications cannot be rebased. These include applications with digitally signed components, DLLs protected by Windows Rights Management, and any executable that programmatically checks the DLL after it has been loaded. However, even if an application is not included on the exclusion list, it simply means that rebasing will be attempted but will not be successful. Since rebasing should be scheduled during a time of minimal server use, the resource impact of the attempted rebasing should not be noticeable.

Memory optimization is based on the Citrix Virtual Memory Optimization service. This Windows service scans loaded DLLs every 10 seconds to determine which DLLs have been relocated. By default, this service runs under the context of the local system account but can be modified within farm properties.

The graphic shown below shows that without memory optimization invoked, all applications attempt to write to the same base memory address space, whereas with memory optimization invoked, each application cleanly gets directed to a unique address space.

Without Memory Optimization Configured

 

 With Memory Optimization Configured

 

CPU Optimization
CPU optimization is based on Presentation Server reserving approximately 20% of the CPUs for automatic optimization. As a result, no single session controls the majority of CPU processing. However, CPU power can be borrowed from idle or inactive sessions but re-allocated when active again.

CPU optimization is based on two Windows services:

• Citrix CPU Utilization Mgmt/Resource Mgmt: Monitors users and processes, calculates load, and sets CPU priority.
• Citrix CPU Utilization Mgmt/ User-Session Sync: Ensures that user processes get associated with user to determine load.

Impact to Architectural Designs

Invoking memory and CPU optimization is typically beneficial and should not have any noticeable negative impact. Memory optimization should be scheduled during a time of low or no usage. If an administrator is uncertain as to whether specific applications cannot take advantage of this feature, they should not be added to the exclusion list. Only those applications which have known issues based on the criteria described above should be placed on the exclusion list. Because CPU optimization uses approximately 20% of the CPU processing power, older servers with limited CPU resources may not have sufficient CPU to support this feature.

Considerations

As part of the application testing process, memory and CPU optimization should be tested to ensure that there is no adverse impact to the environment.

The impact of memory and CPU optimization can be viewed in standard Access Suite Console reports. In addition, CPU utilization can be viewed within the new Citrix CPU Utilization Mgmt User object, which can be accessed via Resource Manager or Performance Monitor. This object includes the following counters: CPU entitlement, CPU reservations, CPU shares, CPU usage, and long-term CPU usage.

Making Virtual IP Addresses Available to Applications in Citrix

Some applications, such as CRM and CTI, use an IP address for addressing, licensing, identification, or other purposes and thus require a unique IP address or a loopback address in sessions. Other applications may bind to a static port, which, because the port is already in use, causes the failure of multiple attempts to launch an application in a multiuser environment. For such applications to function correctly in a XenApp environment, a unique IP address is required for each device.

Use the virtual IP address feature to assign a static range of IP addresses to a server and have these addresses individually allocated to each session so that configured applications running within that session appear to have a unique address.

Processes require virtual IP if either:

• They use a hard-coded TCP port number, or
• They do both of the following:
  • Use Windows sockets, and
  • Require a unique IP address or require a specified TCP port number

Also, this feature lets you configure applications that depend on communication with localhost (127.0.0.1 by default) to use a unique virtual loopback address in the localhost range (127.*).
Processes require virtual loopback if either:

• They use the Windows socket loopback (localhost) address (127.0.0.1), or
• They use a hard-coded TCP port number

If the application requires an IP address for identification purposes only, configure your server to use the client IP address.

How Virtual IP Addressing Works

The virtual IP Address feature works as follows:

• During IMA startup, the virtual IP address assigner binds the assigned IP addresses to the NIC that matches the same subnet as the virtual addresses.
• When the virtual IP feature is enabled on a specific server, the virtual IP address allocator allocates all new sessions connecting to the server an address from   the  pool of available addresses that were assigned by the virtual IP address assigner.
• Each new session is allocated an address that is removed from the pool of available addresses. When the session logs off, the allocated address is returned to the available address pool.
• After an address is allocated to a session, it uses the allocated virtual address rather than the primary IP address for the system whenever the following calls are made:

  Bind¸closesocket¸connect, WSAConnect, WSAAccept, getpeername,
  getsockname, sendto, WSASendTo, WSASocketW, gethostbyname,
  gethostbyaddr, getnameinfo, getaddrinfo

Note: All processes that require this feature must be added to the Virtual IP Process list. Child processes do not inherit this functionality automatically. Processes can be configured with full paths or just the executable name. For security reasons, Citrix recommends that you use full paths.

 

To make virtual IP addresses available to aplications running in sessions

Use virtual IP addresses to provide published applications with unique IP addresses for use in sessions. This is especially important for Computer Telephony Integration (CTI) applications that are widely used in call centers.

Users of these applications can access them on a XenApp server in the same fashion that they access any other published application.

To assign virtual IP address ranges, you must have a reserved range of static IP addresses to assign to the server. Work with your network administrator to obtain a list of free addresses that are not part of your DHCP pool. Ensure that you do not include broadcast addresses.

Before assigning virtual IP address ranges, determine the maximum number of users you may have connecting concurrently to the server. Because every session connecting to the server is assigned an IP address (not just sessions launching the application that require virtual IP addresses), assign at least as many static IP addresses to the server as the maximum number of users who may be connecting concurrently to that server.

 

Note: In the event more sessions are launched on a server than IP addresses are available, the server displays the error message: “No virtual IP address is available for this session, please contact your administrator.” The inability of the server to assign a virtual IP address to a session does not prevent the user from launching an application that requires a virtual IP address within the session; however, the application may not function correctly.

• At the farm level, configure virtual IP address ranges and assign them to servers.
• Enable applications to use virtual IP addresses.

In addition to configuring virtual IP address ranges and enabling applications for use with virtual IP addresses, this feature can control and monitor virtual IP addresses available from each server.

 

To determine whether an application needs to use virtual IP addresses

Some applications cannot run in multiple sessions on XenApp. For example, if the application binds to a fixed TCP port on a specific IP address such as 0.0.0.0 or 127.0.0.1, this prevents multiple instances of the application from running in multiple sessions because the port is already in use. The virtual IP feature of XenApp can help solve this problem.

To determine whether or not the application needs to use virtual IP addresses:

1. Obtain the TCPView tool from Microsoft. This tool lists all applications that bind specific IP addresses and ports.
2. Disable the Resolve IP Addresses feature so that you see the addresses instead of host names.
3. Launch the application and, using TCPView, note which IP addresses and ports are opened by the application and which process names are opening these ports.

To use the virtual IP address feature, configure any processes that open the IP address of the server, 0.0.0.0, or 127.0.0.1. To ensure that an application does not open the same IP address on a different port, launch an additional instance of the application.

Citrix Access Gateway

Citrix Access Gateway is a secure application access solution that provides administrators granular application-level policy and action controls to secure access to applications and data while allowing users to work from anywhere. It gives IT administrators a single point of control and tools to help ensure compliance with regulations and the highest levels of information security across and outside the enterprise. At the same time, it empowers users with a single point of access—optimized for roles, devices, and networks—to the enterprise applications and data they need. This unique combination of capabilities helps maximize the productivity of today's mobile workforce.

How Access Gateway works

Citrix Access Gateway is a secure access solution that provides administrators with application control while empowering users with access from anywhere. With flexible deployment options and a single point of management, IT administrators set policies—based on roles, devices, and networks—to control access and user actions, ensuring better security and compliance management.

Identify device, user, and location

When users attempt to connect to corporate resources, Access Gateway collects and verifies information including client device configuration, user identity, and network location to ensure compliance with security policies and to optimize the user experience.

Establish a secure, accelerated connection

Access Gateway establishes an encrypted connection between the client and datacenter to ensure desktops, applications, e-mail, and other resources are securely accessed from anywhere. Access Gateway also works with Citrix Branch Repeater to accelerate each connection and deliver a high-performance experience.

Adapt access and application actions

Once a session is established, information collected about the connecting device, user, and location dynamically
adapts the level of access and available actions. This ensures that the data needed is delivered to users in the most secure manner according to their particular access scenarios.

Monitor sessions in real time and reconnect as users roam

Access Gateway monitors active connections in real time to detect when a user roams between networks or moves between devices. When this occurs, Access Gateway transparently reconnects the session and dynamically adapts access and available actions to ensure security as the user's access scenario changes.

XenApp Content Redirection

I see a lot of people struggling with content redirection. The issues that people normally have are understanding what it is, how it works, and it’s limitations. Hopefully this blog post will clear it up.

What it is

Content redirection is a XenApp technology which, as the name implies, allows content to be passed from either the client to the server, or from the server to the client.

In real terms – for client to server – this is the ability to double-click a document on the client and have this open using a XenApp hosted application; for server to client it is the ability to click on a URL within a XenApp session and have it open using the local browser on the client.

Out of the box this is content redirection. Nothing more is supported. You cannot:

• Use any proxies on the client. By this I mean things like right clicking on a file, selecting Send To and have it open a hosted version of Outlook and attach the file to a new message. This will not work.
• Redirect anything from Server to Client Except URLs. E.G Double clicking a .xls file in your XenApp session and having it open in Excel on the local client

How it works

Client to Server

Provided you have everything configured correctly, when you authenticate to the Online Plug-in it will pull down the File Type Associations you have configured for a published application and write these into the client registry. Now any file that is associated with the XenApp hosted app will launch a connection to a XenApp server when double clicked. Once the application is launched on the XenApp server the file will be opened in the published application.

The Online Plug-in updates the HKEY_CLASSES_ROOT portion of the registry. If you look at one of your application file extensions before being logged into the Online Plug-in you will see that it points to local version of the application



And once logged into the Online Plug-in it now points to the XenApp version of the Application.



If you’re wondering what VisioViewer.Viewer and ctx.VISIO.DRAWING.11 refer to, if you scroll further down in HKEY_CLASSES_ROOT you will find registry keys with the same name, drill down into Shell–> Open–> Command and you will find the path to the executable that is to be launched. In the case of content redirection it looks something like this

“C:\Program Files\Citrix\ICA Client\pnagent.exe” /qlaunch “CXAPRD6:Visio 2010 Professional” /param:”\\client/%251”

This is the path to Online Plug-in, followed by the XenApp farm name (as configured on your Web Interface servers, not the actual farm name), the application name, and a parameter of \\client\%1. When the application is launched %1 get substituted for the path to the file that was double clicked.
You must have the following components for Client to Server Content Redirection to work:

• Citrix Online Plug-in
• Citrix Web Interface
• Client Drive Mapping Enabled
• Content Redirection Policies Enabled

You must have Client Drive Mapping enabled so that XenApp can make the call back to the client to open the file. If the file is located on a network share you must also have these mapped into the session as client drives. You do not need to make them visible though, as long as they are available through the client network in the background it will work.

Server to Client

Again, provided everything is configured correctly, when you click on certain URLs in a XenApp hosted Desktop or Application, it will be intercepted and passed back to the client. The default browser will be launched, if not running, and the URL will be opened in the browser on the client. If the client cannot open the URL, E.G if it has no route to the internet, it will pass it back to the server for it to be launched there.
The way that XenApp intercepts the URL is by overwriting the shell open command for the URL type, redirecting the call to its own version on Internet Explorer. The registry keys that do this are located under HKEY_CLASSES_ROOT and the I.E executable they point to is C:\Program Files (x86)\Citrix\system32\iexplore.exe

Looking at rtsp (which is one of the URL type than can be redirected) we can see what I have described above.



 You must have the following components for Server to Client Content Redirection to work:

• Citrix Online Plug-in
• XenApp Content Redirection Policy enabled

It will also only work with these URL types:

• HTTP (Hypertext Transfer Protocol)
• HTTPS (Secure Hypertext Transfer Protocol)
• RTSP (Real Player and QuickTime)
• RTSPU (Real Player and QuickTime)
• PNM (Legacy Real Player)
• MMS (Microsoft Media Format)

Configuration

Client to Server

Client to Server content redirection is configured by associating the file types with a Published Application. To do this, open the properties of the Published Application, and click on Content Redirection.



 If you are not seeing all the file types for your application this is because they may not yet be in the datastore. To pull the information from a server’s registry, right-click the server in the console select Other Tasks–>Update file types from registry. To pull FTA from all your servers right-click on the root of the farm and select Other Tasks –> Update file types. Bear in mind this is going to pull from all your server in the farm so if you have a large farm it may take a while.

Remember you must also configure Client Drive Mapping for Client to Server content redirection to work.

Server to Client

Server to Client Redirection is configured using XenApp Policies. The setting is located under User Configuration–> Policies–> Citrix Policies–> Policy Name–> ICA–> File Redirection–> Host to client redirection.

The following keys can be used to control Server to Client content redirection. These are taken from CTX113457, which does not specify XenApp 6 or 6.5 in the “Applies to section” but I have tested on both.

To configure file types that can be redirected, complete the following procedure:
Add the HKEY_LOCAL_MACHINE \SOFTWARE\Wow6432Node\Citrix\SFTA\DisableServerFTA registry key with the following values:

Name: DisableServerFTA
Type: REG_DWORD
Value: 1

Add the HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\SFTA\NoRedirectClasses registry key with the following values:

Name: NoRedirectClasses
Type: REG_MULTI_SZ
Value: <Specify any combination of file type names that you would like to exclude from redirection.>

Note: These values are comma-delimited with no space in between the values.

To configure server to file redirection for specific URLs,
Add the HKEY_LOCAL_MACHINE \SOFTWARE\Wow6432Node\Citrix\SFTA\ValidSites registry key with the following values:
HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\SFTA
Name: ValidSites
Type: MULTI STRING
Value: www.example.com
Note: Specify the required URLs in the Value field. The asterisk (*) is supported as a wildcard character.

Keyboard Shortcuts for VMware Workstation

VMware has a set of shortcut keys or hotkeys for quick control over your virtual machine. This is a list of them.

Ctrl+B	Power on the Virtual Machine
Ctrl+D	Edit the Virtual Machine Settings
Ctrl+E	Power off the Virtual Machine
Ctrl+G	Grab keyboard input focus
Ctrl+N	Create a new Virtual Machine
Ctrl+O	Open a Virtual Machine
Ctrl+P	Edit User Preferences
Ctrl+R	Reset Virtual Machine
Ctrl+Z	Suspend the Virtual Machine
Ctrl+F4	Close the Virtual Machine
Ctrl+Alt	Ungrab Input focus
Ctrl+Alt+Enter	Switch to Full Screen Mode
Ctrl+Tab	Switch between ungrabbed virtual machines
Ctrl+Alt+Tab	Switch between virtual machines

Change the DHCP IP Address Range for VMware NAT

VMware Workstation includes a network utility that allows you to manage the virtual networks. Typically virtual machines will use NAT (Network Address Translation) to automatically assign a virtual IP address that hides behind your host address, but the default range of 192.168.200.0/24 may not work for everybody.

You can change this address range to anything you like easily. Note that you should not have virtual machines running during this.

First open the Manage Virtual Networks start menu item:

Click the Host Virtual Network Mapping tab, and then click the arrow button next to the VMnet8 dropdown box. VMnet8 is the default NAT adapter for VMware.

Choose the Subnet option, and you will see a dialog where you can change the network range:

Once you have changed the network here, you can click the OK or Apply buttons, and after a few seconds it will update.

How to Change the Virtual Machine Boot Device in Virtual PC

If you’re trying to install an OS or are testing out boot disks, you might be wondering how to change the boot device. Here’s the quick and easy technique to change it.
What we’re going to do is go into the virtual machine’s BIOS and tweak it there.

Tweaking the Boot Device

First, click on the Ctl+Alt+Del button in your virtual machine so it can reboot.

When the POS comes up (as shown in the image below), you should press the Esc key until you bet into the BIOS menu.

Once in the BIOS menu, navigate using your left and right arrow keys until you get to the Boot menu.

Press Enter on Boot Device Priority and you will see a menu to select your primary booting device.

Use your + and – keys to select your primary boot device. Assuming you will use a CD, DVD or ISO file, you should select your CDROM device as 1st Boot Device.
Then press F10 to save and exit and you will see a screen like this:

After you confirm your changes, your virtual machine will boot and you will be able to begin your installation.

Make Virtual Machines Always Hide To The System Tray in VMware Workstation

My favorite feature in the latest version of VMware Workstation is that you can run virtual machines entirely in the background. This is most useful for “appliance” machines that you won’t actually use from the prompt, but through a web browser or ssh client.

The only problem is that when you click the close button on the VMware window, you get a prompt saying “Some virtual machines are still powered on. You can continue to run these virtual machines in the background, suspend them for later use, or power them off now.“

I always want my virtual machines to run in the background!

You can disable that window by just telling VMware to always run virtual machines in the background by going to Edit \ Preferences.

Click the checkbox that says “Run powered on virtual machines in background after close”. Now when you click the close button, it will always just minimize the virtual machines to the system tray. Very useful

Turn Off Debug Mode in VMWare Workstation 6 Beta

VMWare Workstation is great. The version 6 beta has even more awesome features…  but it’s slower than dirt, because debugging mode is turned on by default.

Thankfully there’s a quick and easy trick to turn off debugging, which will increase the speed a lot.

Here’s what we’re going to do:

1. Open an explorer window and browse down to the VMWare install folder. (C:\Program Files\Vmware\VMware Workstation)
2. You’ll see two folders, one named bin and another named bin-debug. 
3. Rename bin-debug to bin-debug-old.
4. Make a copy of the bin folder, and name the copied folder bin-debug.
5. Enjoy Workstation 6 without debugging.

Here’s a screenshot of what the folder structure now should look like:

How to Increase the VMWare Boot Screen Delay

If you’ve wanted to try out a bootable CD or USB flash drive in a virtual machine environment, you’ve probably noticed that VMWare’s offerings make it difficult to change the boot device. We’ll show you how to change these options.

You can do this either for one boot, or permanently for a particular virtual machine.

Even experienced users of VMWare Player or Workstation may not recognize the screen above – it’s the virtual machine’s BIOS, which in most cases flashes by in the blink of an eye.

If you want to boot up the virtual machine with a CD or USB key instead of the hard drive, then you’ll need more than an eye’s-blink to press Escape and bring up the Boot Menu. Fortunately, there is a way to introduce a boot delay that isn’t exposed in VMWare’s graphical interface – you have to edit the virtual machine’s settings file (a .vmx file) manually.

Editing the Virtual Machine’s .vmx

Find the .vmx file that contains the settings for your virtual machine. You chose a location for this when you created the virtual machine – in Windows, the default location is a folder called My Virtual Machines in your My Documents folder.

In VMWare Workstation, the location of the .vmx file is listed on the virtual machine’s tab.

If in doubt, search your hard drive for .vmx files. 

Open the .vmx file with any text editor.

Somewhere in this file, enter in the following line… save the file, then close out of the text editor:

bios.bootdelay = 20000

This will introduce a 20 second delay when the virtual machine loads up, giving you plenty of time to press the Escape button and access the boot menu. The number in this line is just a value in milliseconds, so for a five second boot delay, enter 5000, and so on.

Change Boot Options Temporarily

Now, when you boot up your virtual machine, you’ll have plenty of time to enter one of the keystrokes listed at the bottom of the BIOS screen on boot-up.

Press Escape to bring up the Boot Menu. This allows you to select a different device to boot from – like a CD drive.

Your selection will be forgotten the next time you boot up this virtual machine.

Change Boot Options Permanently

When the BIOS screen comes up, press F2 to enter the BIOS Setup menu.

Switch to the Boot tab, and change the ordering of the items by pressing the “+” key to move items up on the list, and the “-” key to move items down the list. We’ve switched the order so that the CD-ROM Drive boots first.

Once you make this change permanent, you may want to re-edit the .vmx file to remove the boot delay.

Boot from a USB Flash Drive

One thing that is noticeably missing from the list of boot options is a USB device. VMWare’s BIOS just does not allow this, but we can get around that limitation using the PLoP Boot Manager that we’ve previously written about. And as a bonus, since everything is virtual anyway, there’s no need to actually burn PLoP to a CD.

Open the settings for the virtual machine you want to boot with a USB drive. Click on Add… at the bottom of the settings screen, and select CD/DVD Drive. Click Next.

Click the Use ISO Image radio button, and click Next.

Browse to find plpbt.iso or plpbtnoemul.iso from the PLoP zip file. Ensure that Connect at power on is checked, and then click Finish.

Click OK on the main Virtual Machine Settings page.

Now, if you use the steps above to boot using that CD/DVD drive, PLoP will load, allowing you to boot from a USB drive!

Conclusion

We’re big fans of VMWare Player and Workstation, as they let us try out a ton of geeky things without worrying about harming our systems. By introducing a boot delay, we can add bootable CDs and USB drives to the list of geeky things we can try out.

Download PLoP Boot Manager

How to Boot a VMware Virtual Machine from a USB Drive

Do you have an OS installed on your USB thumb drive? Booting from it in a VM is now possible, you’ll just have to use a simple trick to get it to work.
All we need to do is to load the Plop ISO in VMware, attach and enable the USB drive in VMware, and finally select the USB option in Plop Boot Manager to boot from the USB.So, visit the Plop boot manager download site.

Click Download, download the latest version, save it in a location, and unzip it. The file named “plpbt.iso” is the one we need to use.

Open VMware, select “Create a new Virtual machine”

In the window that opens, select “Installer Disc image file”, browse to the Plop ISO and select it. VMware will ask you to specify an Operating System. Click next to continue

Select Linux as the Guest Operating System, and from the list of versions, select Ubuntu (or if you have a different OS, select it and its version). Click Next

Specify the name of the VM and the destination where it will be saved.

On the next screen, select “Store Virtual Disk as single file”, and allot 5 GB to it, since we will be booting from the USB drive, and not actually doing an install. Click Next

On the final screen, you’ll see the hardware resources automatically allocated for this particular VM.

Make sure that USB is enabled, and if it isn’t, click “Customize Hardware”, click the USB Controller device, and check the first two options. Click OK to continue.

Make sure your USB drive with a bootable OS is attached. Start the VM, you’ll boot into Plop. First, right click the USB icon on the bottom right corner of VMware Player, and click Connect (Disconnect from Host). Wait a couple of seconds, then click inside the Window, and select the USB option using the arrow keys on your keyboard.

And now you’ll be booting into your OS from the USB. Not only you can boot into Ubuntu from a bootable USB, but you can boot into any bootable OS using this method (DSL, Puppy, or even Windows Installation ISO, whatever bootable OS you have on the USB). Not quite handy perhaps, but still geeky!

---

Download Plop Boot manager

Allow Access to a VMware Virtual Machine(NAT) From Another Computer

If you are running a virtual machine on your computer, you may want to access that virtual machine from another computer. Let’s use an example: Say you have an Ubuntu virtual machine with Apache running on port 80, and you want to show other people on your network to access the website you are hosting.

We’re going to assume that the virtual machine is using NAT, and has been assigned an IP address of 192.168.23.128.

First open the Manage Virtual Networks start menu item:

Click on the NAT tab, and then click on Edit. You will see the NAT Settings dialog:

Click the Port Forwarding button, and you will see this dialog:

Now we are finally on a screen we can actually use. We’re going to use port 8080 on the host machine. We enter the ip address for the ubuntu virtual machine, and port 80. These ports could be any ports.

We should be able to test this out by going to http://localhost:8080 on our host pc. We can give out the url to our host machine by replacing localhost with the host computer IP address.