cannot respond to clients from my server thread .
 

hey this is abhiexx...( i am registered....but i don't have my password right now!!:-().So don't flame me..

hey i was working on the server thread...for my gnutella client...i 've got bearshare running too...so when i establish an outgoing connection from bearshare to my server....after the GNUTELLA OK...part...i get a ping from bearshare..and some extra bytes...total length is 134.


the problem is that when i try to respond to the client socket(which is returned from the accept() call) ....i am able to send the pong....but Bearshare does not show that it has recieved any bytes from me.(i have tried the same thing from a client thread....and this time the packets...show up ....so there is no problem with the writing of packets from my side )...

after a while....the outgoing connection from bearshare is dropped saying...this host is not responding.HELL i am responding !!!!!!!


so what do i do .. i have tried everything...wouldn't work any suggestion would be cool ...

While I may not be absolutely sure about this, because it's Bearshare you're testing with, what you might be receiving is a Bearshare spy packet as well as a ping. Basically it's an encrypted packet of some sort that Bearshare sends to everyone, but is intended for other Bearshare servents. It supposedly contains versioning information (as stated by Vinnie), but nobody has really been able to verify the information contained in it. It always shows up as a query and always has a payload of 88 bytes. And apparently the IP address field within this packet is always wrong so it's no use trying to respond to it.

After giving it a bit of thought, this theory fits rather well because you stated you're receiving a total of 134 bytes. Well, if you do the math, the header of a gnutella packet is always 23 bytes. A ping is basically just a header packet... it has no payload. The Bearshare spy packet is a query with a payload of 88 bytes meaning the entire packet is 111 bytes. Add everything up and you've got 134 bytes. Following this theory through, I am assuming this is the very first packet that is sent out by Bearshare whenever a connection is established with a Bearshare servent. So, assuming the address from this packet is the address that you used to respond to with a pong, it would explain why your Bearshare servent didn't report receiving any data.

At any rate you'll have to filter that spy packet out. According to what I've read on it, it shows up as a query but isn't structured as one. A normal query ends in a null and this packet doesn't terminate this way so the best thing to do is just ignore any query packets that don't terminate with a null. You'll also find that you receive this same packet when you first connect to a host cache.

Here's the thread about the Bearshare spy packets.

ooops thanks for the info...but ..
 

So, assuming the address from this packet is the address that you used to respond to with a pong, it would explain why your Bearshare servent didn't report receiving any data.




hey dude !
well u are absolutely right about the spy packet..thing...the payload and everything else match up...but the thing is that i am testing the servant that i am developing with bearshare running on the same pc...but running on a different port..i.e 6347...so i am not using the ip addresss recieved...from the spy packet..as suggested by you..(am i right ??).Here's some code from my server thread ..hope this makes things clear....




CBlockingSocket g_listener;
UINT serverthread(LPVOID param)
{
CSockAddr client_address;
CBlockingSocket client_sock_in;
CObList temp;
CMessage* poly;

byte* buffer=new byte[100];
int size=0;
int rec=0;
try{
if(!g_listener.Accept(client_sock_in,client_addres s))
{
TRACE("SOCKET CLOSED\n");
//socket closed for some reason..return
return(0);
}
AfxBeginThread(serverthread,param);
//TRACE("secondary thread started\n");
rec=client_sock_in.Receive((char*)buffer,(size=str len("GNUTELLA CONNECT/0.4\n\n")),10);
buffer[rec]='\0';

TRACE("the request is %s",buffer);
if(strnicmp((char*)buffer,"GNUTELLA CONNECT/0.4\n\n",size)==0)
{

client_sock_in.Write("GNUTELLA OK\n\n",14,10);
TRACE("\n\nWROTE HANDSHAKE");

poly=CMessage::read(&client_sock_in,buffer);
TRACE(" \n %s",poly->GetRuntimeClass()->m_lpszClassName);
temp.AddHead(poly);


CPong* p=new CPong(poly->getGUID(),0x07,6348,((byte*)"127.0.0.1"),7,890) ;
p->write(&client_sock_in);

TRACE("\nRITTEN");

CPing* pi=new CPing(0x07);
pi->write(&client_sock_in);
}

}
catch(CBlockingSocketException* e)
{
char* temp=new char[100];
e->GetErrorMessage(temp,100,NULL);
TRACE("the exception is %s",temp);
client_sock_in.Close();
delete e;

}

return(0);
}


As u can see i am using the socket returned in the accept call to write to bearshare client...which is running on the same pc on which i am developing the client.So there is no question about me mistaking the ip address to which i am sending the packet to...well i tried some sending packets to bearshare in an infinite loop...in the same thread as shown above...and the client does report recieving a bad packet of a huge length...so i am still confused.

I haven't kept up on Bearshare, but another thing I noticed is that you are using the Gnutella 0.4 protocol... last I heard, Bearshare blocks all 0.4 servents. If you add the 0.6 handshaking, you may get a response. However, what you can also do is try your testing using different servent software... like Gnucleus. I'm almost certain Gnucleus hasn't blocked 0.4 servents yet and as long as you have it set as a standard servent and not a supernode or leaf node, you'll probably get the results you're looking for (sans spy packets as well).

(EDIT: DUH! I guess I wasn't thinking... I think I got a few things straight like first, Bearshare is connecting to YOUR server. Second, obviously if you're recieving spy packets and pings from Bearshare, you're connected so it obviously still uses the 0.4 protocol.... but you may want to try another servent anyway just to see if it will give you different results. If you get the same results from a different servent, then it might help you trace it back to the source.)

ya i tried that with gnutella 0.56
 

hey joe....
thanks for ur interest in solving my poblem...


anyways....i did try the code...that i posted..with gnutella 0.56...with similar results..that is it is not showing the packets...that i sent...in the SRD fields.

which means that i am doing something wrong in my code...maybe someone can specify the exact sequence of transfers that take place when a client connects to my server...


well another interesting thing that cropped up was that..i sent a ping after the gnutella ok part...bearshare reported that as a bad packet....however...if i sent a pong it didn't show up at all !

however both these packets are reported as good packets...if a write ...to the bearshare server....using...a client thread in my code......hell this is confusing stuff....GIMME A FREAKING BREAK !!!

Re: ya i tried that with gnutella 0.56
 

The sequence of events (as I understand it) starts with your server listening on a specific port (normally 6346) for a connection attempt. After making a connection to your server, the remote client would initiate the handshake procedure. Under the Gnutella 0.4 protocol (I don't have the 0.6 handshaking stuff handy), the client would start with "GNUTELLA CONNECT 0.4\n\n" and your server would respond with "GNUTELLA OK\n\n". Then your server should wait for the remote client to send a ping. Upon receiving the ping, your server would respond with a pong (and it would also propogate that ping to all of the other nodes you're connected to, but first things first). Any pongs you receive from other nodes responding to the ping that was sent by the remote client would also be routed back to it. The rest we can get to when you've made a successful connection.

Just off the top of my head, are you sure the packets your server is sending are of the correct size? For instance, a ping is always 23 bytes. Any shorter and it would probably be detected as a bad packet.

hmmm....
 

well i guess...there are some probs...in life...u just gotta solve on ur own...i guess....this is one of them.

thanks to all the ppl who tried to help...Thanks Joe.
i will report anything out of the ordinary...lol...seeya..happy hacking