HTTP Listener configuration

Service Virtualization updates port settings for HTTP/HTTPS communication according to the Service Virtualization default configuration, during installation of the Designer, or when the Server is run for the first time. When you create or modify Service Virtualization agent configurations, Service Virtualization automatically updates these settings. Checking the settings manually may be useful for troubleshooting purposes.

To change the automatic configuration settings, see Windows firewall and TCP port configuration.

Default port settings

Default settings are defined for the Service Virtualization Server, Designer, and Service Virtualization Management. Ports are also defined for the product demos, which are not required for anything else.

The default configuration is as follows:

Product Detail Reserved URL Protocol Certificate Binding
Designer HTTP Gateway Agent http://+:7200/ HTTP No
HTTP Proxy Agent http://+:7201/ HTTP No
HTTPS Gateway Agent https://+:7205/ HTTPS Yes
Management Endpoint http://+:7280/ HTTP No
https://+:7280/ HTTPS Yes
JDBC Agent http://+:7288/ HTTP No
Server HTTP Gateway Agent http://+:6070/ HTTP No
HTTP Proxy Agent http://+:6071/ HTTP No
HTTPS Gateway Agent https://+:6075/ HTTPS Yes
Management Endpoint http://+:6080/ HTTP No
https://+:6085/ HTTPS Yes
JDBC Agent http://+:6088/ HTTP No
Service Virtualization Management Web interface https://*:6086/ HTTPS Yes
Demos* (installed with Designer) Not specific http://+:8101/ HTTP No
http://+:8102/ HTTP No
http://+:8103/ HTTP No
http://+:8104/ HTTP No

* Only URL Reservations are created for ports used by the demo projects to allow you to start the demos. Windows Firewall is not opened for the ports used by the demos for security reasons. As a result, you can only call demos from the local machine.

Back to top

Checking the port settings

Checking the settings manually may be useful for troubleshooting, especially if Windows User Access Control (UAC) is enabled.

You can use the Windows netsh command line tool to check the port settings used for HTTP communication. For older Windows operating systems, use the httpcfg tool.

Examples:

  • To show ACLs on all ports:

    netsh http show urlacl

  • To show SSL certificate bindings on all ports:

    netsh http show sslcert

  • To show ACLs on a specific port for HTTP:

    netsh http show urlacl http://+:PortNumber/

  • To show ACLs on a specific port for HTTPS:

    netsh http show urlacl https://+:PortNumber/

  • To show SSL certificate binding on a specific port:

    netsh http show sslcert ipport=0.0.0.0:PortNumber

where PortNumber is the TCP port number.

Back to top

Checking the port status

You can use the Windows netstat command line tool to list protocol statistics and network connection information. For example, you can check that the Service Virtualization agents are listening on their assigned ports to determine that the virtual service endpoints are functioning. The statistics can also be useful to troubleshoot port conflicts that might require you to reconfigure agent port assignments.

To list all ports on the local machine on which services are listening:

netstat -a | find /i "listening"

The output lists all listening services. The ports used by the Service Virtualization Server are as follows:

TCP [::]:6070 hostname:0 LISTENING

TCP [::]:6071 hostname:0 LISTENING

TCP [::]:6075 hostname:0 LISTENING

TCP [::]:6076 hostname:0 LISTENING

TCP [::]:6085 hostname:0 LISTENING

TCP [::]:6088 hostname:0 LISTENING

Back to top

How to check connectivity to ports

The open connection between the machine running the real service and the machine running Service Virtualization is essential for successful message recording. The connectivity can be blocked and checking it with a simple tool can save you time. For example, for a Service Virtualization agent listening on a port, you can check the connectivity to this port using telnet.

Note: The telnet client may not be enabled in Windows. You can enable it using Windows Control Panel.

Example:

To check connectivity from the machine where the real service is running to the machine where Service Virtualization is running, type the following at a command prompt:

telnet ServerName PortNumber

where:

  • ServerName is the machine where Service Virtualization is running
  • PortNumber is the TCP port number of the agent for requests

The result is one of the following:

  • A connection failure - a message is displayed.
  • A successful connection - the command window is cleared and displays only a blinking cursor. If you enter Crtl^C, the connection is closed and a message is displayed.

Successful connection indicates that the communication should be open and the recording of real service messages by Service Virtualization should work. However, if it still does not work, this indicates that the problem is not caused by firewall or port settings. The problem is more likely with the virtual service configuration.

A failed connection via telnet indicates that the communication is blocked in transit. The first thing to do is to check Windows Firewall settings and TCP port configurations.

If everything is set correctly but the connection is still blocked, the problem is likely caused by the infrastructure between the machines.

Back to top