AFAIK jtella is even older than peercast.

If you want to use an up-to-date java-based Gnutella client, just have a look at Phex (at least if you want to have a chance to see your improvements in the mainline client).

- Phex sources: http://www.phex.org/wiki/index.php/Subversion

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

Hello,

I have found two versions of JTELLA (Jtella-07 very old 2001, and Jtella-08 more recent 2003).
A Jtella-07 peer doesn't work with a peer Phex because Phex only accept ultrapeers, so I get 503 error codes.
The Jtella-08 seems to be able to connect with Phex because a jtella08 peer can act as an ultrapeer, so I don't have the 503 error anymore. However, I still have some issues when querying files. I will look at both source codes to see if this is an inteoperability issue.

I did also some tests with Limewire but that doesn't work at all (even when I try to connect a Limewire peer with a Phex peer).

After fixing these protocol issues, I will try to extend it with streaming features using peercast.

Have you any ideas about the interoperability issues ?

Yes, firewall detection issues.
Phex will not reply with search results if it determines that downloads won't work anyway because both nodes seem to be firewalled.

__________________

To try interoperability tests within Phex and Jtella, I use the wireshark sniffer.
It seems that Phex truncates the TCP packets (Connect, pong...) which results in bad TCP checksum. This error causes Jtella to close the connection. (I attached the wireshark file).
192.168.1.221 is Phex
192.168.1.78 is Jtella

Attached Files

PhexVsJtella.txt (10.3 KB, 637 views)

Sorry but I can't really believe that Phex is truncating anything on TCP level. The implementation is very high level and is not doing anything TCP related.
If anything is truncated at such a low level, its either because of a bug in the Java VM, OS or something similar.
Additionally there are no connection problems with other client. I assume the interoperability problem is not caused from such a low level problem like faulty TCP packages.

Gregor

__________________

Yes, it seems that the TCP checksum is not the real cause the problem.
After looking deeper in the source and doing some more tests, I see an interoperability issue in PHEX and Jtella.
The Gnutella RFC 0.6 says in section 2.3:
"Servents SHOULD remove any GGEP blocks from Ping, Pong and Push
messages before sending those messages to hosts that have not
indicated GGEP support."
Here, PHEX has not seen that Jtella-0.8 doesn't support GGEP, but sends the GGEP extension anyway. This causes Jtella to discard the PONG message due to a wrong payload exceeding 14 bytes.
AFter modifying some code in JTella, the PONG message coming from PHEX is now accepted, but I guess that a correction should also been done in PHEX, to avoid sending GGEP extensions to servents that doo not support this feature.

______________
Ivan Lovric
ESECO SYSTEMS

I just added the code to drop the GGEP data from pongs to SVN. I have no tested if it works correct, can you please do this...
You can get the changes directly from the Phex SVN or sometimes tonight or tomorrow from our automated build system (in case its running correctly): Index of /snapshots

I only did this change because it was quite easy to integrate, though actually I don't believe it is necessary to still support outdated nodes that don't yet support GGEP extension...

Gregor

__________________

I did also tests with QueryHit messages. The problem is the same: there are GGEP extensions in the QUERY messages sent by PHEX to JTELLA that are not well understood by JTELLA. After some hard coding in JTELLA, the problem is solved, but that should also need some adjustments in PHEX code.

___________
Ivan Lovric
ESECO SYSTEMS