2011-05-22 18:04:29 -0600 fdlimit.c:645 [Debug] Transmission: SO_SNDBUF size is 131070
2011-05-22 18:04:29 -0600 fdlimit.c:647 [Debug] Transmission: SO_RCVBUF size is 262140
As near as I can tell these values are returned by the system but may be influenced by the application.
Would it be helpful if Transmission tried to reduce these values via setsockopt()?
SO_SNDBUF and SO_RCVBUF are options to adjust the normal buffer sizes
allocated for output and input buffers, respectively. The buffer size
may be increased for high-volume connections, or may be decreased to
limit the possible backlog of incoming data. The system places an abso-
lute limit on these values.
Yes, IMO it would be interesting & possibly useful to know what the kind of performance you get by lowering those values to be small enough that they don't trigger the error message anymore. That's not something that I (or Juliusz, afaik) tested on OS X.
Appreciate the reply. I take it you thought I was referring to µTP? I have shown that you can build and run without error with any combination of SND/RCV buffers to a total of 4 * 1024 *1024. Trouble is the current code is asking for a total of 5 * 1024 * 1024 (4 * ... RCV + 1 * ... SND) resulting in the error (RCV) "asked for 4194304 got 42080". Should be easy to fix---pick a number between 1 and 4.
Actually, in this post I was referring to TCP connections and thinking of slow-death-like issues. In the code I can only find setsockopt() being used for announces (2-3KB) and clientisSeed (8 KB RCV net.c) but not for leechers. Since the application is allowed to override default values after reaching the threshold number of sockets (default 64) then calling setsockopt() for leechers and using any appropriate value less than the default (65535 SND 65535 RCV) might help stave off system freeze particularly for users who like to use hundreds of connections.
