Please help us test the compatibility of BearShare's new chat system with LimeWire.

The latest beta of BearShare 4.7.0 is available at http://www.bearshare.net/announcement.php?f=50

If you search in BearShare and get LimeWire sources in the Search Results pane, you can right-click on the sources and chat with the server.

We would like chat to work in both directions. Currently, when we try to chat with a BearShare server in the LimeWire Search Results pane, the chat menu item is grayed-out.

What GGEP/vendor code/HTTP headers does LimeWire expect to see from the server before providing the client with the option to chat?

Unfortunately, it aint gonna happen in existing LimeWire's.

An extract from our QueryReply code:

//Parse LimeWire's private area. Currently only a single byte
//whose LSB is 0x1 if we support chat, or 0x0 if we do.
//Shareaza also supports our chat, don't disclude them...
int privateLength=_payload.length-i;
if (privateLength>0 && (vendorT.equals("LIME") ||
vendorT.equals("RAZA"))) {
byte privateFlags = _payload[i];
supportsChatT = (privateFlags & CHAT_MASK) != 0;
}


That's probably the only area in the whole of LimeWire that looks at vendor codes. Oh well.

Ah, so we should test compatibility with RAZA too...

Would you consider supporting a new GGEP flag 'CHAT' (with no payload) in the per-server (not per-file) GGEP of Query Hits, to indicate that the server supports Chat?

And/Or, specifying chat support in X-Features during Uploads/Downloads would enable chatting with transferring hosts, even if you couldn't chat through the Search Results.

CHAT in per-server GGEP of replies is a great idea.

For HTTP connections (both upload & download side), I believe LimeWire might already support a "chat/0.1" feature.

We just tried downloading a file from a BearShare server using a LimeWire 4.2.4 client, and we didn't see chat specified in X-Features.

Is its presence conditional on something? I definitely have the Chat check box enabled in LimeWire.

Upload from X.X.X.X ("LimeWire/4.2.4") Processing request
--REQUEST--
GET /uri-res/N2R?urn:sha1:___K7ZU7QVCZHWFU7CE7RQBKOWMUFFME HTTP/1.1\r\n
HOST: X.X.X.X:6632\r\n
User-Agent: LimeWire/4.2.4\r\n
X-Queue: 0.1\r\n
X-Gnutella-Content-URN: urn:sha1:___K7ZU7QVCZHWFU7CE7RQBKOWMUFFME\r\n
Range: bytes=0-99999\r\n
X-Features: queue/0.1, fwt/1.0, fwalt/0.1\r\n
\r\n

--RESPONSE--
HTTP/1.1 503 Queued\r\n
Server: BearShare 4.7.0b43\r\n
Content-Length: 0\r\n
X-Queue: position=1,length=1,limit=6,pollMin=30,pollMax=120 \r\n
\r\n

If LW detects it can't receive incoming connections, it won't send the chat feature (because no one would be able to chat with it).

Thanks. Waiting for incoming connections did the trick.

BearShare 4.7.0 beta 44 implements the vendor-independent Chat feature advertisements we've been talking about:
* GGEP 'CHAT' in Query Hits (sending and receiving)
* "X-Features: chat/0.1" in HTTP headers during transfer (sending and receiving)

We will follow the same strategy of not announcing Chat capability from firewalled servers (and not attempting to connect to firewalled servers).

Thanks for working with us on compatibility.