One of the newer and as yet undocumented option settings under Network -> Connections is .

http://support.tixati.com/Settings_-_Network_-_Connections

The default values seem to be 16 and 14 seconds? respectively.

Anyone know what the range is and the effect of changing these values?

May I join the question...

soitenly

do you have answers? or the same questions?

I have the same question and would love to see some feedback regarding this particular setting.

I frequently see "timed out" connections on my peer lists, and I'm unsure about what, exactly, these values are and how they work, and what settings or inside what range would be recommended for each case. I tried fiddling with them a bit but found the results inconclusive, and some background info would help. Thanks.

I'm curious too. It seems min and max values for both settings are: 5 and 200 seconds. This is my guess-work:

Peer connect timeout is time in seconds that Tixati waits after initiating a peer connection to receive an answer. If the time is up and there is no answer, it displays "Timed out connecting" status message.
1. Example, default timeouts 16/14:
[11:04:29]  going online
[11:04:29]  initiating connection
[11:04:46]  Stopped: Timed out connecting
[11:04:46]  going offline
Peer login timeout is time in seconds that Tixati waits after it gets an answer to establish bittorrent connection. Tixati shows log message "logged in OK" after handshake is sent. Tixati displays "Timed out logging in" if the time is up and handshake is not done yet.
2. Example, timeouts used 16/5:
[11:04:49]  going online
[11:04:49]  initiating connection
[11:04:51]  securing connection
[11:04:57]  retrying connection in unencrypted mode
[11:04:58]  sending handshake
[11:05:05]  Stopped: Timed out logging in
[11:05:05]  going offline
3. Example, same peer, default timeouts 16/14:
[11:12:48]  going online
[11:12:48]  initiating connection
[11:12:48]  securing connection
[11:13:04]  retrying connection in unencrypted mode
[11:13:07]  sending handshake
[11:13:19]  logged in OK
Note, that after login time is out, Tixati tries to establish unencrypted connection and resets the timeout (waits another 5s in the second example and 14s in third).

Peer connect timeout is needed because Tixati could wait forever for an answer if a peer is offline (client closed, computer off, firewalled or behind NAT without port open). I guess login timeout is needed because of different connection problems. Maybe peer who responds that long isn't worth connecting to, because it will be unreliable connection. Peer from 2. and 3. example was from Taiwan, I'm from Europe.

I think default peers timeouts are safe high values "for compatibility". Setting them higher won't help and will only slow down connecting process. With lower timout values, achieving maximum peers connections number can be quicker. It will make difference only when Tixati is just started, or when new torrent is added and there are lots of peers waiting to connect. With too low timeouts it may be difficult to connect some high latency peers. For now, I have set timeouts to half of default values, to see if it makes any difference.

I am about to necro this threat, as I was trying to increase connect timeout and found out: on windows this settings is limited by system (default 21s = initial tcp timeout + retransmissions) and setting it more makes no difference, you get system timeout error instead of tixati one, dunno if point of this setting was to bypass OS limit, if so, its no longer working ...

Only way you could increase timeout on windows, is by tweaking number of tcp retransmissions

I don't know If good or bad but I've the values set to 200 for peer connect and 5 for login timeouts.

For whatever it's worth. Lately, I have been getting a LOT of "Timed out Connecting" messages.

I am running the "latest" release; V2.49

Seriously!! Just PICK a share. ANY one will have MOST connections with this message.

I even shutdown ALL other transfers and limited all resources to ONE transfer and I still could not get the clients to communicate. The other person was running uTorrent (latest as of this writing) and even with just the ONE torrent active, we could not establish a connection.

Also, I had one other person try to connect as well. This is the goocher, too... they were also running Tixati V2.49 as well...  ...???

Now, considering this ONE "share" there was ONE other person who COULD connect with me. The only thing that I know about this one, was that they were hailing from China and he was using a BitTorrent Client. V-?? But he could connect.

Gads!! NOW this starts to get confusing. Okay... the guy with the uTorr Client was calling-in from the US, where I am.

The person with Tixati, who "Timed out" was from Croatia --Gads!! I LOVE this internet stuff... :D-- AND he too, limited his connections to only the ONE torrent that I was TRYING to re-seed.

Again, on with the scenario. The US (uTorr) person COULD connect with the BitTorrent Client, in China but not mine, in the US. The ONLY thing stopping him from seeding from the China connection was that the UL speeds from China were in the 1-4kbps range. And this was a ~2GB file. Would have taken a lifetime to DL from this guy. PLUS come to find out, he was a H&Rer. Once the file was complete, he cut bait and ran. : (

Anyway, we finally used a different method of transfer, but this SHOULD have been REALLY easy-peasy to transfer. But it was not.

Since about TWO "updates" ago, I have noticed this "Timed out Connecting" thing increase, almost exponentially.

I have a Fiber Optics connection, and there is no reason for this Client to be "Timing out" on ANYONE for that matter.

Is there something that I "ooopsed" on, inadvertently? Have I managed to "tweak" something that I should NOT have. I find this improbable, as I do not "tweak" the settings. Only insofar as to what has been recommended on this site. That is about it.

I am by no means knowledgeable enough to be conversed in how these Clients work. All that I know is that this is a REALLY cool Client. : ) and IF I ever want to really get to know one, this is the one that allows that... But with that being said, I do not really "mess" with the settings...

So why all of a sudden, am I seeing the "Timed out" messages in my "Peers" column?? Even on a "HOT" share, where the swarm is at it's PEAK, I am only getting a HANDFUL (6-8) ULs going at a time. Where as before, I would see a few pages full of people UL'ing from my files.

Just curious if anyone knows WHY?? : P It's kind of frustrating KNOWING that I CAN share, but my Client is not letting me.

Also, running Win 7 if that makes a difference.

One more thing while I am at it... WHY do you use "COLOR CODED" verification?? I am color blind. : P  LOL!! Fortunately THIS time, it asked me for "black." Hahahah!! I CAN see that!! : ) But seriously. It would be nice, if you changed your "captcha" thingie, to something a little more, color-blind friendly. : D

Thank you, in advance, for your time and consideration on this. : ) -EB

EB the "why" for just 1 transfer is the same for 100 transfers.
Just because you have a faster connection does not mean you can connect to many peers. Using the plumber analogy, a pipe's BANDWIDTH can be thought of the dimension (3/4" can never hold 2" worth of water). Pressure is the volume of water/data flowing in the pipe aka throughput or SPEED.
If you changed any of the Connections settings it is possible you're oversaturating your link. Connecting to 2000 peers to START IS NEVER a good idea. @Pete points out that with lower numbers you will get to functioning peers FASTER not connect to MORE peers. You cannot force 10060 10061 to come back. Especially on UDP (UE or IEU in peers tab) you can have a multitude of places interjecting packets into your stream, from your local network ISP (not LAN unless you're sabotaging yourself)... all the way to the recipient (end of the connection) ISP. So if you want to try, go lower with max connections on your line (each connection is extra throughput taken away from data and adding to overhead/connections). I get just fine with only 10 connections for a seed and 20 download (and i'm not even on your lucky fiber).
IF at DEFAULT settings you still get alot of problems with connection timeout, diagnose your internet connection. OR you could just ask your ISP if they "traffic shape" "drop connections" or interfere with "third party streaming".
In the USA my area we are finally seeing in big bold print (in the tiny legalese for signups for data plans) .. users at 3% of usage will be throttled during peak hours, or after usage exceeding 24 GB data transfer until cycle resets.

Search for your error you receive the most, and go from there.

PS  I am serious. I would REALLY like a firing solution to this "issue."

As I have stated numerous times, I LOVE this Client but as of late, I have had absolutely NOTHING but "Timed out" messages with my peers.

To clarify a "hot swarm" above, I am talking 100 - 150 Downloaders at a time. Constant for a day or two...

And as stated above I only get a HANDFUL of these connecting to MY Client...

...WHY???  HELP!!!

Should I TRY and "roll-back" to a few releases ago and see if THAT makes any difference??

ANY suggestions are welcome and anticipated.

Thanks again for a wonderful program, and to any and all suggestions that you can lend. : ) -EB

Thanks "Guest" will check the setting out, but I don't THINK that they are set to "2000" did I hiccup somewhere? I cannot see from where I am typing.

Anyway, like I said, this was working "fine" before. Until just recently.

Nice analogy by the way, yes I understand that you CAN get 250GPM through a 1/2" pipe with a TDH that is off of the charts. But I am not certain that this is the issue.

I will lower my # of connections but I am not certain that is the actual culprit.

I MAY have to reset back to orig. settings and see if that doesn't clear this issue up.

Again, I USE to be able to connect to a swarm, and connect to MOST of the peers that were connected. Sure, there was a FEW odd-ball "Timed out" or disconnects but they were few. And my BW was (is) just fine but like, JUST recently this started to happen. ~Two weeks, MAYBE just a bit longer but not by much.

Unfortunately, this has not lead to any conclusions just a semi-reiteration of what I said, just explained differently... except for the # of connections... I will drop those down a bit and see if that changes anything.

Thank you again, for your suggestion. I will let y'all know how this works out. : ) -EB

...Awww man... "RED!!" now I'm screwed. LOL!! At least I can just reenter another number if my guess is off. : )

Did anyone come up with a solution to this problem?  Mine is similar except I also get a message saying, "Remote disconnected."  It happens no matter which client I use, and I have tried about 5. This one is my favorite, BTW.

It seems to depend on what the peer's connection is as to which message I get:

outgoing udp encrypted = timed out connecting
outgoing udp plain = remote disconnected
outgoing tcp plain = remote disconnected

I am able to download just fine, but seeding is impossible.

Remote disconnected seems to be:
The client has put you in an wait state with no channel opens (all sockets closed), for if needed to, connect to you later. The reasons might be: client bad implementation, latency higher than other peers, packet loss, client bandwidth full.

It's normal, not a problem. When someone has stopped the torrent and you try to connect to him, you'll got disconnected immediately.

While I'm seeding one transfer (and not downloading any), about half the peers listed  complete transfer without issue, and the rest repeatedly get "error: Timed out connecting".
Is there a way to collect statistics for analysis of this?

I have joined this topic just for any summaries or updates on the settings.

this thread was started years back.

 Just observing a new seed,  a whole bunch will try to get on and wink out as connection time outs.  Surely a couple could connect  at the outset.  I'm using the default setting as described early in the thread and getting ready to install 2.66.

How can I avoid endlessly harassing seeders only hosting part of a multi-file torrent?