At first I thought I had a bug in my 'InspectPacket' Routine. All of the routed pongs i'm receiving have only spaces for the messageID. And the length is correct for a messageID(15). After reviewing my logfile with more attention, I found that this is ONLY the case when I recive a 'routed' pong. The pongs I recieve from my connected servant are correct, as well as the ping messageID's as well. The connected servant is BearShare 2.4.2 on another pc through my router/switch with BS. having 3 internet servants connected to it.

Any clues as to what i'm doing wrong?

Here is a clip of my logfile:

*Note: the empty brackets did contain 16 spaces, but pasting it here altered that. Trust me the MsgId length is correct, it was just full of " "'s

Received Ping On Connection: 1 At: 6/10/2002 6:44:05 AM
DescriptorID: {hñ Fº~ÿzvý
ˆ }
TTL: 1
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:44:05 AM
DescriptorID: {hñ Fº~ÿzvý
ˆ }
TTL: 1
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Sent Ping On Connection: 1 At: 6/10/2002 6:44:06 AM
DescriptorID: {ýíHÀÿsø½àÓÐ }
TTL: 7
Hops: 0
Payload Length: 0


Received Pong On Connection: 1 At: 6/10/2002 6:44:06 AM
DescriptorID: {ýíHÀÿsø½àÓÐ }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 54
Files Size: 213MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:09 AM
DescriptorID: { }
TTL: 1
Hops: 6
Payload Length: 14
IPAddress: 24.187.66.38
Port: 6346
Files Shared: 52
Files Size: 192MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:11 AM
DescriptorID: { }
TTL: 4
Hops: 3
Payload Length: 14
IPAddress: 213.189.164.99
Port: 6346
Files Shared: 2
Files Size: 3MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:17 AM
DescriptorID: { }
TTL: 2
Hops: 5
Payload Length: 14
IPAddress: 24.68.248.38
Port: 6346
Files Shared: 1
Files Size: 3MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:22 AM
DescriptorID: { }
TTL: 6
Hops: 1
Payload Length: 14
IPAddress: 80.132.56.51
Port: 6346
Files Shared: 12
Files Size: 906MB


Sent Ping On Connection: 1 At: 6/10/2002 6:44:29 AM
DescriptorID: {\™-{¥^9‚ÿKuÉ> }
TTL: 7
Hops: 0
Payload Length: 0


Received Pong On Connection: 1 At: 6/10/2002 6:44:29 AM
DescriptorID: {\™-{¥^9‚ÿKuÉ> }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 54
Files Size: 213MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:36 AM
DescriptorID: { }
TTL: 2
Hops: 5
Payload Length: 14
IPAddress: 213.73.221.213
Port: 6346
Files Shared: 236
Files Size: 1GB


Received Pong On Connection: 1 At: 6/10/2002 6:44:39 AM
DescriptorID: { }
TTL: 2
Hops: 5
Payload Length: 14
IPAddress: 4.62.78.132
Port: 6346
Files Shared: 118
Files Size: 455MB


Received Ping On Connection: 1 At: 6/10/2002 6:44:44 AM
DescriptorID: {ÜÞHX,ÑËOÿ}.Go§ }
TTL: 1
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:44:44 AM
DescriptorID: {ÜÞHX,ÑËOÿ}.Go§ }
TTL: 1
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:48 AM
DescriptorID: { }
TTL: 4
Hops: 3
Payload Length: 14
IPAddress: 158.75.63.86
Port: 6346
Files Shared: 5
Files Size: 629MB


Received Pong On Connection: 1 At: 6/10/2002 6:44:49 AM
DescriptorID: { }
TTL: 4
Hops: 3
Payload Length: 14
IPAddress: 65.119.183.231
Port: 6346
Files Shared: 1246
Files Size: 5GB


Received Ping On Connection: 1 At: 6/10/2002 6:44:59 AM
DescriptorID: {Ì~3ã½Àý§ÿ#&h¹Ê }
TTL: 1
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:44:59 AM
DescriptorID: {Ì~3ã½Àý§ÿ#&h¹Ê }
TTL: 1
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Sent Ping On Connection: 1 At: 6/10/2002 6:45:07 AM
DescriptorID: {|èÖ†93ÿƒQÕìjŸ }
TTL: 7
Hops: 0
Payload Length: 0


Received Pong On Connection: 1 At: 6/10/2002 6:45:07 AM
DescriptorID: {|èÖ†93ÿƒQÕìjŸ }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 54
Files Size: 213MB


Received Ping On Connection: 1 At: 6/10/2002 6:45:09 AM
DescriptorID: {•?HhYHåÿ8ÅV¤ }
TTL: 7
Hops: 0
Payload Length: 0


Sent Pong On Connection: 1 At: 6/10/2002 6:45:09 AM
DescriptorID: {•?HhYHåÿ8ÅV¤ }
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.3
Port: 6346
Files Shared: 80
Files Size: 6MB


Moak?, Morgwen?

Could well be a bug in BS. Routed pongs usually are cached pongs, so that could explain it. But I wasn't aware BS would cache pongs and also cache the TTL and Hops ( in my case, I don't )

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

But even if they are cached pongs, standard operating procedure would be to insert my messageID into the cached pong then send it to me. Correct? I am no real fan of Vinnie or his BS, (no pun intended) but I would almost have to give him a little more credit than distributing a version of BS with a flaw like this in it.

I assume that your app does not suffer this problem? Has anyone ever seen this before?

After a bit of research using a sniffer, i have found that ALL routed pongs (at least through Bearshare) have a messageID of: {00000000-0000-0000-0000-000000000000}. This does not seem to follow accepted procedure.

It is my understanding (correct me if i'm wrong) that when receiving a pong with a messageID that matches a previously seen ping, it is forwarded through the connection the ping was received (if not pongcaching).

If pongcaching Is being used, and the servant receives a ping, the servant dips into it's pongcache (if the cache is sufficently full) and INSERTS the message id of the RECEIVED ping (the receiving client never knows the difference, with exception of TTL & hops), and sends it back through the connection from which it came, this reducing traffic on the network.

I do understand there are variants of this scheme, but I have not seen any that stated you should insert a messageID of all zero's.

Is this normal practice? I mean, i guess theres nothing wrong with it. It make the identification of routed pongs a snap. but again, Is this normal practice? ie. do I need to incorporate this into my servant? It does not seem wise to hardcode something like this into pong handling routines.

Yes, it has to match your ping's message ID, or for whatever ping you have forwarded (which didn't show in your log). So it is either a bug in BS (although older version) or there's something in your code.

__________________
Okay, so I've been gone a while - but hey, meanwhile online translators have gotten better:

Ce n'est pas ma faute. Blâmer vous-même.

----

Ne me blâmez pas. Blâment votre individu.

All pings in the log above where originated by my servant there where no forwarded pings at all. The only pings sent through this connection(the only connection) where created by me. Therefore all routed pongs to me are for me. Correct?

As you can see, when i sent a ping it had a messageID of X when I received a pong(ping reply) from the connected servant(hops = 0), the messageID matches X, BUT all other pongs received after (Hops > 0) have this 'zero'ed out' messageID.

This log was created using BS 2.4.4 ( I can't go much higher in the BS version because it will kick me off when it gets enough BS clients.

look at the log:


*Ping Sent By Me*

Sent Ping On Connection: 1 At: 6/10/2002 6:19:44 PM
MessageID: {Ü
Øî„0þÿhÎ?ò }
FuncID: 0
TTL: 7
Hops: 0
Payload Length: 0

*Pong From Connected Servant* **MessageID is Correct**

Received Pong On Connection: 1 At: 6/10/2002 6:19:45 PM
MessageID: {Ü
Øî„0þÿhÎ?ò }
FuncID: 1
TTL: 7
Hops: 0
Payload Length: 14
IPAddress: 192.168.1.2
Port: 6346
Files Shared: 56
Files Size: 215MB

*Routed Pong through Connected Servant* **MessageID is NOT Correct**

Received Pong On Connection: 1 At: 6/10/2002 6:19:45 PM
MessageID: { }
FuncID: 1
TTL: 6
Hops: 1
Payload Length: 14
IPAddress: 211.44.xxx.xxx
Port: 6346
Files Shared: 54
Files Size: 670MB

*Routed Pong through Connected Servant* **MessageID is NOT Correct**

Received Pong On Connection: 1 At: 6/10/2002 6:19:52 PM
MessageID: { }
FuncID: 1
TTL: 1
Hops: 6
Payload Length: 14
IPAddress: 200.255.xxx.xxx
Port: 6346
Files Shared: 34
Files Size: 70MB

**UPDATE**

Using Gnucleus, I monitored the good and bad packets being received. The image below tells the story. I personally would like to thank Vinnie for producing and distributing a such fine product as BearShare. Thank you for the hours of headbanging trying to debug my code that I thought must have been flawed. I will never again over-estamate you.

P.S. The connected servant was BearShare 2.6.2

Attached Images

bam.jpg (48.5 KB, 180 views)

This pretty much explains everything:
http://www.limewire.com/index.jsp/pingpong

I believe this defect is fixed in BearShare 3.0.0.

In any event, the GUID on pings and pongs doesn't really matter, since these messages are no longer routed.

No longer routed?

As of 6/12/2002 7:07:11 AM they still where... in the sense that a servant still needs to see a pong as a response to one of it's previous pings.

At least by BearShare 2.6.2...