 |
 |
Statistics Page
|
Overview
|
 |
Although not necessary for operating the program, the Statistics Page
displays useful information about your incoming messages, outgoing
messages, shared files, network statistics, and memory usage.
|
 |
Appearance
|
 |
 |
 |
 |
Incoming Message Statistics |
Information about incoming messages is displayed in this area. The
total number of messages, number of messages per second, and appropriate
percent are shown for each incoming message type along with the incoming
message totals.
|
 |
 |
Outgoing Message Statistics |
Outgoing messages are counted and measured in this section. Outgoing
messages includes your search results and searches, as well as incoming
messages that were routed or re-broadcast as per the Gnutella protocol.
|
 |
 |
Processed Message Statistics |
This area shows statistics about the messages the BearShare is processing,
and what is happening to them. Handled messages are messages that were
processed locally and possibly forwarded to other connections. Unrouted
messages are messages for which the return path could not be located,
usually due to a host disconnecting. Duplicate messages are common,
due to the broadcast nature of the Gnutella network. Dropped messages are
those messages that have expired due to their time to live settings.
A high percentage of dropped messages is possible, mainly due to poor
client implementations.
Bad messages are messages that were malformed, or did not adhere to the
Gnutella procotol. Note that BearShare silently 'repairs' some malformed
messages in cases where it can.
Because Gnutella messages have limited time to live, the FreePeers Agent
drops messages whose time to live is expired, or whose hop count has
exceeded the maximum. A number of other Gnutella clients incorrectly
forward these messages when they should drop them.
Until this situation changes, you can expect to see a high percentage of
dropped messages in this section. This is normal. You can help to solve this
problem, and help the entire Gnutella network in the process, by telling
and encouraging others to use BearShare.
|
 |
 |
Routing Table Statistics |
Since part of the Gnutella protocol involves remembering the
unique 'identities' of certain messages, BearShare stores the messages
in its internal routing tables. The routing table statistics panel
shows the times associated with the three major tables used by
the program, for your local messages, and for messages that originated
remotely.
|
 |
 |
Bandwidth Statistics |
All of the bandwidth consumed by the program is displayed in this
section, including the host connection bandwidth, upload bandwidth,
and download bandwidth, along with the totals for each, and the
totals for the entire program. This does not measure bandwidth usage
by other programs.
|
 |
 |
Memory Usage |
This displays an estimate of the amount of memory that BearShare is
using for certain critical core components. Note that additional
connections, large search result sets (over 10,000), large amounts of shared
files (over 10,000), or large amounts of failed and completed uploads or downloads
(over 1,000) all require increasing amounts of memory.
The Server memory display shows the memory for all server related data
including the routing tables, host cache, IP history, messages, uploads and
downloads, shared files, and search results. The Network memory display
shows the amount of memory used for network buffers, which can change
dynamically in response to load.
|
 |
 |
File Transfer Statistics |
The number and kilobytes of files shared by you, downloaded by you,
and uploaded by you to other people is displayed here. The number of shared
files and the sum of all shared file sizes adjusts itself immediately as
shared files and shared directories are added or removed
|
 |
 |
Horizon |
This section reports on the estimated 'size' of the portion of the Gnutella
network which is reachable by your computer. This size is measured in the
number of hosts, number of shared files, and total size of all reachable
shared files. It is normal for these values to fluctuate over time.
Depending on the size of your host cache, these numbers may be lower than the
actual values.
The FreePeers count shows the number of users who are currently running BearShare,
or another program that uses the FreePeers Agent, on the same network. Clicking
on either the FreePeers link or the Hosts link will broadcast a ping message
to the network, updating the horizon. It can take up to a minute after pinging
for the horizon to update to its full size. After several minutes, the values
displayed in the horizon will become inaccurate, since ping messages are not
continually sent out (in order to reduce network traffic). If an accurate measurement
of the horizon is desired, click a link.
The amount of time that the FreePeers Agent has been running is also displayed.
|
 |
|
 |
|
 |
BearShare relies on the FreePeers Agent for network communication.
This Agent is a .DLL file which handles all of the core logic for
communicating with the Gnutella network. The Gnutella protocol specifies
a simple set of messages which computers exchange with each other.
The messages can tell you about the IP address of another computer,
a search request, search results, or upload requests. These are the
different message types:
Ping |
This is a request for host IP addresses and shared file counts.
These messages are broadcast when received or sent, which
means they are sent to every other host you are connected to.
|
Pong |
This is a response to a ping message. The response contains the IP
address of the responding host along with their shared file counts.
Pong messages are routed, traveling back on the path the original
ping message came in on. They are not broadcast.
BearShare can find alternate paths for pong messages
if the original path is not available.
|
Search |
This message represents a search for files. The message contains the
search keywords along with the minimum speed of the hosts which
should respond. These messages are broadcast, like ping messages.
|
Results |
These messages hold responses to searches. The message contains one
or more files and their sizes, the speed of the responding host,
and a unique identifier used during a push request. Search results
are routed, traveling back on the path the original search message
came in on. BearShare can find alternate paths for search result messages
if the original path is not available.
|
Push |
A Push message is a request for a remote server to initiate a push
of a shared file. This is used when the server hosting the file is behind
a firewall and cannot accept incoming connections. The firewalled host,
upon receipt of the push message, opens an outbound connection to the
host requesting the file, thus bypassing the inability of accepting
incoming connections. If the host requesting the file is also behind
a firewall or cannot accept incoming connections, the push request will
fail.
Push messages are routed, traveling back on the path the original
search result message came in on. BearShare remembers the paths for all
seach results, so if the original path is not available, a back-up
route will be used.
Some Gnutella clients do not route push messages, but broadcast them
instead. This is a serious flaw in logic, and contributes to a large
amount of unnecessary traffic. You can help to solve this problem by
using and recommending BearShare, which properly handles push messages.
|
For more information about the Gnutella protocol messages, consult the
Gnutella v.4 protocol documentation,
provided by
Clip2 DSS.
|
 |
|
|
 |