connection problem
 

Hello,
I have written a gnutella client and it works. The problem is I can only get few connection. WHen I got an outcoming connection, it can only keep alive for a little while then disconnect. When I got an incoming connection, it can keep alive for a longer time, but I can only get 1 or 2 incoming connections.
When I run bearshare and my client in the same machine using different port, bearshare can get enough incoming connection while my client cannot. I have no clue about it.
Is anyone know how to get more connection and made them stable?
I appreciate for your help.:confused:

what is a "little while". Most clients (bearshare/limewire) send out "alive" pings .. and if you dont response with a pong within 10 sec.. your history ...

connection problem
 

Thank you for your reply. I can only connect with a servent for about less than 1 minutes. When I receive a message, I put it into a queue. I use another thread keep retriving message from the queue, route the message, and send reply.

connection problems
 

i'm having a similar problem. my client responds to keep-alive pings too. it looks like the problem is related to the other hosts (duh, of course it can't be me :D ) ... seriously. BearShare 2.5/2.6 and LimeWire 2.4.4 seem to represent the majority of clients that my client is finding, and most of them drop my connection almost immediately. usually i'm able to sneak a ping through and sometimes i get some pongs back, enough to keep 25 (i'll explain) connections searching for other hosts. i'm using 25 because with six it was taking forever to find even one host that wouldn't drop my connection. there are a few user agents that don't drop me all the time (mostly Gnucleus 1.6.0.0/1.6.3.0 and MorpheusPE 1.3.3.2). to be fair, the LimeWire clients often send 503 error codes and X-Try headers, so maybe they're just all backed up (or "shielded leaf nodes") :P the only thing i can think of is that my handshake is bad (
i'm sending ) ... any suggestions would be very helpful. thanks!!

Easy
 

Sickfish, you should run LimeWire on the same machine that you are using to develop your client, and just connect the two to each other and see why it drops you.

Or, you could use Gnucleus for testing.

Either way, you've got source code for both LimeWire and Gnucleus, so you can set a breakpoint and look up their stack to find out why you are getting dropped.

duh
 

yeah i should have thought of that. :P

ok, but still
 

i can connect to my LimeWire client, but it seems to Really want to be an ultrapeer and always gives me a 503/shielded leaf node message. but it redirects me to other clients, many of which are LimeWire, and i have successfully connected to a few of those. is possible that my connection problems are due to a dearth of other servants with available connections? (this is my question)

but both my LimeWire and BearShare clients seem to have no trouble connecting at all. i still haven't been able to connect to my own BearShare client. it sends me a 200 OK, that bad packet and then drops me every time. like, immediately. what's up with that?

It is possible but not likely if that helps you at all :)

Re: ok, but still
 

Shareaza and Gnucleus are both great for debugging your client.
The System window of Shareaza shows you all task it is performing (Send Handshake, etc).
In Gnucleus you can go to the Connections tab after you have connected your client with it. Then you can right click on your connected client and see some stats like the effiency and errors your client caused.

I used to do that way.

I ahve nevr done it thta way but it sounds like a good idea :)

ROAR
 

that sounded like a great idea, so i tried it. both gnucleus and shareaza take the same amount of time as my client to find a good number of other clients, so i'm not so worried about that. BUT when my custom client tries to connect to my shareaza client it says "timed out handshaking with 192.168.2.2" (they are running on different machines). it's really weird - it looks like the shareaza client is never receiving the handshake. outside hosts do - i Can connect to the network. i get the same problem when the shareaza client is on my local machine.

I am writing a c# gnutella client. I have written classes for connecting and routing messages but am having trouble connecting to some clients and maintaining connections for others.

Limewire *always* gives me a 503 service unavailable message when I try and connect. (Though I can connect to a copy running on my local machine provided all of its connections slots aren't being used.) I am guessing that if you want to connect to limewire hosts you must pretend to be one of them. Do other gnutella clients use this approach? How difficult is it to do? Is it just a case of sending an appropriate User-Agent header or would you be forced to implement other limewire specific functionality?

Bearshare clients accept incoming connections. 2.x tends to stay alive for something like a hundred messages before sending me a Bye message with an error code of 503 and no error text. Version 4 clients tend to keep connections alive for much longer. Gnucleus and some other clients allow me to connect but tend to disconnect after around a dozen messages.

I am hoping that there is someone out there who can shed some light on why I am finding it so difficult to maintain these connections.

For initial node discovery I have implemented gwebcache. Once I get some x-try headers then I use those instead. Whenever I establish a connection then I use Ping/Pong messages to find new nodes. Is this an appropriate algorithm for node discovery? How beneficial and difficult would it be to implement ultranode functionality?

In summary my problem is that I am droping connections faster than I can make them and can only get at most three or four concurrent connections even though I have ten streams concurrently trying to establish them. Any assistance would be much appreciated.

I am also looking for collaborators. Please contact me if you would like to contribute.

Regards

Jake Mitchell

gnutrinoNOSPAM@PLEASEhotmail.com [remove NOSPAMPLEASE]