solving the re-query problem How to get more results after the initial query has already been brodcast is an ongoing problem. Some developers have set the clients to send out more brodcast searches. This can burden the network with traffic. Some suggestions I have might be to:
1) Begin to structure the network more. Grouping people the file types they are sharing and the types they are looking for. This would be good to do under the ultrapeers.
2)Re-query with a non-bradcast query that is sent from 1 maching to the other in a directed manner toward areas in the network rich in the media type.
3)Have ultrapeers requery for its peers. But instead of simply sending out a query for every file for every client wait until a few of its clients are looking for the same file (or a range of files of the file hash).
4)Better yet, allow packets to contain multiple queries. Then the ultrapeer can simply group many of the queries together in one search. Re-quering the network could take 1/10-1/100 or less of the bandwith by grouping the searches. This could even be done by individual clients if multiple specific file hash queries could be grouped together. A client may be looking for 100 files. Instead of simply sending out 100 differents searches (1 for each file) it could send out 1 search with 100 file hashes it is looking for. |