views:

339

answers:

7

I am working on a bittorrent client. While communicating with the peers the easiest way for me to communicate with them is to spawn a new thread for each one of them. But if the user wants to keep connections with large number of peers that my cause me to spawn a lot of threads.

Another solution i thought of is have one thread to iterate through peer objects and run them for e period.

I checked other libraries mostly in ruby( mine is in java ) and they spawn one thread for each new peer. Do you think spawning one thread will degrade performence if user sets the number of connections to a high number like 100 or 200?

+1  A: 

No.....

Once I had this very same doubt and created a .net app (4 years ago) with 400 threads....

Provided they don't do a lot of work, with a decent machine you should be fine...

daniel
+2  A: 

It shouldn't be a problem unless you're running thousands of threads. I'd look into a compromise, using a threadpool. You can detect the number of CPUs at runtime and decide how many threads to spin up based on that, and then hand out work to the threadpool as it comes along.

psanf
+3  A: 

You can avoid the problem altogether by using Non-blocking IO (java.nio.*).

Emil H
A: 

Well in 32bit Windows for example there is actually a maximum number of native Threads you can create (2 Gigs / (number of Threads * ThreadStackSize (default is 2MB)) or something like that). So with too many connections you simply might run out of Virtual Memory address space. I think a compromise might work: Use a Thread Pool with e.g. 10 Threads (depending on the machine) running and Distribute the connections evenly. Inside the Thread loop through the peers assigned to this Thread. And limit the maximum number of connections.

Daff
+1  A: 

A few hundred threads is not a problem for most workstation-class machines, and is simpler to code.

However, if you are interested in pursuing your idea, you can use the non-blocking IO features provided by Java's NIO packages. Jean-Francois Arcand's blog contains a lot of good tips learned from creating the Grizzly connector for Glassfish.

erickson
I have not worked with nio, i only read a couple of articles here and there but i thought my second plan was close to nio route instead of iterating over peer i iterate over selectors? also what kind of advantages nio would bring?
Hamza Yerlikaya
I don't understand exactly what you mean by iterating over peer objects. At some point, data must be read from a socket. Without non-blocking provided by NIO, the thread will be stuck in the first peer that is slow to respond; the only way to unstick that thread is for the socket read to timeout, which raises an exception.
erickson
+1  A: 

I'd recommend using an Executor to keep the number of threads pooled.

Executors.newFixedThreadPool(numberOfThreads);

With this, you can basically add "tasks" to the pool and they will complete as soon as threads become available. This way, you're not exhausting all of the enduser's computer's threads and still getting a lot done at the same time. If you set it to like 16, you'd be pretty safe, though you could always allow the user to change this number if they wanted to.

TK Kocheran
+1! Why write code when there's a great pre-existing way to do it for you?
Alex Feinman
A: 

Use a thread pool and you should be safe with a fairly large pool size (100 or so). CPU will not be a problem since you are IO bound with this type of application.

You can easily make the pools size configurable and put in a reasonable maximum, just to prevent memory related issues with all the threads. Of course that should only occur if all the threads are actually being used.

Robin