I am trying to implement a simple gnutella servent (No PING and PONG messages. Just Query and Query Hit messages. A gnutella node reads a startup file to know it neighbors) and I have a few issues which I think developers in this forum will be able to address. I am a bit confused as to how TCP/IP connections are handled in gnutella servents.

I would explain my design below and would really appreciate if the anybody could comment on it and point out the bottlenecks, blunders if any, in it.

The servent in my design would contain two modules (say ) a client and a server. The client presents a command line interface to the user where new search requests may be entered. The server handles Query and QueryHit messages from other neighboring servents.

I am looking at multithreaded server where every new incoming connection at the server starts a new thread. An ansychronous design would be more preferable but could also get a bit complicated. So i decided to stick to multithreading..

Now lets take a scenario. Suppose a user enters a search. The client component would create as many sockets as there are neighbors and connect to the neighbors ( gnutella servers ) and send them query packets or requests.

Question: 1) Should the client close the connection immediately after sending the Query packets ???

What I am thinking is that the neighboring nodes(server component in the neighboring nodes) who receive the query packets would in turn connect to their neighbors and send them the query packets and close the connection. The node or nodes which have that file being searched ( i.e. a QUERY HIT) would then create a QUERYHIT packet and send it back to the upstream node from where the query packet arrived.

Is this approach right ????

my confusion here is this:
After sending the query packet or request the client component of the first node will close all the sockets connecting to its neighbors. The results ( QUERYHITS) will be handled by the server component of the first node.

How does the node confirm that it has received all the QUERY HITS possible. A server could receive a QUERYHIT for a QUERY which was sent a long time ago.

Any feedback or constructive criticism is welcome.

Thank you

You will be disconnected within 30 seconds from most hosts if you do not reply to a ping with a pong.

No. If you close the connection you will never receive any QHs.

When they receive the query they will send it to their CONNECTED
neighbors.

It works like this:
You connect to a neighbor and send a query, not closing the connection. The neighbor in turn, forwards the query to its neighbors and so on. Any hits generated will be routed back down the path they were sent to you. During this same time you will receive pings and queries that you will at least have to read and dispose. When you have received as many hits as you like, you MAY disconnect. Remember though, connecting is one of the most time consuming activities a servent has to do because of all the busy signals and "dead hosts".

You can't determine that you have received all the hits possible. You just wait for some time limit and assume you have received every hit.

That is why messages have the 16 bytes of message id. You store that value when you send the query and any hits resulting from that query will arrive with the same 16 bytes of message id.


If you or anyone made a client that worked in this fashion (ONLY interested in getting hits and not helping the network) would probably have their client banned. If it is just a personal project then there wouldn't really be any problem.

Hello tshdos

Thanks for your comments....but I think you misunderstood what I am trying to do...

Well, first things first, this is my own personal project and I intend to test it on my own LAN..my intention of not going with PING and PONG messages was to test a very very simple version before going to full blown design..

You said that if a client closes the connection as soon it sends a QUERY request it wont be able to receive QH's. Well, I think I did not explain what I was doing properly.

A servent would consist of a client and a server ( all this in one node). These two would be running as threads wherein the client would wait for user inputs ( right now from command line) and the server would be listening for incoming connections ( i,e for QUERY and QUERY HITS) from other nodes....

When a user submits a new request.. the client would connect to all the other neighboring nodes ( server components) and send them the QUERY and close the connection. On the server side a new thread is started everytime a new connection is received and accepted.

The QUERY HITS would arrive only on the server component of the original node which sent the request. So there is no way that the QH's will be missed or not received.

I hope I have explained it clearly now.??? If yes do u think this will work ???


Thank you

Ok. That could work as long as the server component supported all of the basic gnutella messages. If you have a lot of clients sending queries through the same server component, it may lose its connections essentially rendering it useless. Overall this appears to be just a limited ultrapeer approach.