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