This table provides an overview of servers that a selected computer has communicated with. The table thus tells you about traffic that was initiated by the selected computer.

To view the table, select ANALYZE > Computers > Computer Search, and search for a computer. Then, in the search results, click the name of the required computer, and then select the Traffic Table tab.

Filter Table on Time and/or Process

You can filter the table's content based on:

• Interval: The period of time that you want the table to cover, for example 0-30 minutes. If the predefined intervals don't suit you, select Custom to specify your own interval.

• Process: A specific process that you want to know more about. Note that the amount of processes you see in the list may change based on your interval selection (because more processes may have been active during the last 30 days than during the last 30 minutes).

  IP data process information is not collected on computers that run Windows XP.

Click the Update button.

When ready, click the Update Simple or Update Detailed button.

Understand Table's Contents

Based on your parameters, the table lists some or all of the following:

• Hostname: The server with which the computer communicated.

  You can click the hostnames of monitored servers to view the Computer Traffic graph with data from the server in question. The graph will use the same interval as you have selected on the Traffic Table.

• Port: The port through which communication took place, for example HTTP.
• Protocol: The protocol type used for the communication, TCP or UDP.
• Process name: Name of process used in the communication, for example chrome.exe.
• Process version: Version of process used in the communication.
• Total response time: The time, in milliseconds, until the server/port response was received by the computer.
• Received bytes: The total number of bytes received by the computer on the server/port.
• Sent bytes: The number of bytes sent from the computer to the server/port.
• Received packets: The total number of IP packets received by the computer from the server/port.
• Sent packets: The total number of IP packets sent from the computer to the server/port.
• Responses: The total number of responses.
• Requests: The total number of requests.
• No application response within 500 seconds: The number of times that no application response with payload was received within a time frame of 500 seconds.
• [Response times grouped in milliseconds intervals]: The number of response measurements in the respective intervals by the computer on the server/port.
• Connections: Total number of established TCP connections from the computer to the server/port.

• Connection resets: Total number of times that TCP connections from the computer to the server/port were reset. The number of connection resets can sometimes be higher than the number of connections, for example if a server wasn't ready to respond immediately when it was contacted by the computer.

   What's a connection reset?

   A connection reset is typically the sign of a busy server that puts clients "on hold" until it is ready to serve them. It does this by forcing clients to connect again. This buys the server time, so that it is able to get rid of its current queue of tasks before taking on new tasks. From the server's perspective the advantage of this is that it can keep the queue of clients waiting on the network rather than on the server itself. The amount of time that a connection reset takes is very small, so it typically takes several connection resets before users begin to feel that the server is hard to reach. Once the server has accepted the connection, it will normally respond quickly. That's why connection resets mainly affect users' ability to get in touch with the server in the first place, not their subsequent use of the server. Technically, PerformanceGuard records a connection reset when it receives a data packet with the RST bit set to 1. If a high number of connection resets is a problem, you need to look at the performance of the server: Is the server's CPU heavily loaded? Does the server have enough RAM? Is there a disk I/O bottleneck? If you're monitoring the server with PerformanceGuard, you can easily find out, for example by looking at the server's Utilization Index.

• Retransmissions: The number of TCP retransmissions from the computer to the server/port.