Hi, two things come in my mind:

First, Bearshare (perhaps other clients too) have a pong throtteling... which means they will not route a heavy number of pong descriptors in a short time window, but delay them, perhaps also throw some away (?).
Second, we had statistics some months ago saying ping/pong traffic was eating a huge percentage from the gnutella backbone traffic. It is a good idea not to use broadcast pings in a standard client to meassure horizon (avoid network broadcasts), but for sure it is okay in a rarely used statistic tool. I'm not sure if ping/pong for meassure of horizon will still work in future, perhaps Pong Limiting and Pong caching will provide falsified results. See http://www.limewire.com/index.jsp/pingpong and http://www.limewire.com/index.jsp/med_require.

To answer your question (I'm not sure what you want to do exactly): Ping/Pong is theoretically the most accurate Gnutella protocoll v0.4 method to meassure horizon, but unhealthy to the network if many clients do + allready falsified by anti broadcast techniques + limited by TTLs. Perhaps you should ask Limewire how they collect their rolling host count at http://www.limewire.com/index.jsp/size. Other methods for gnutella size meassure could be: Asking query caches how many unique IPs they served, how many unique pings and pongs they received/transmitted. Asking upcoming superpeers, how many unique IDs they have routed. Implement new protocoll features to provide a better horizon estimation (some ideas in this thread).