Encryption Enabled by default?

[splintax]

Because using encryption is a waste of CPU time if you're not shaped.

[Kazuaki Shimazaki]

That's true, however, I can see the point of those guys that want it on Enabled. Maybe there should be a switch called "Enabled, Last Ditch Only". What that setting would do is start off trying to connect to people without encryption. That would connect to everyone except those desperate enough to disable "Allow Legacy Connections". When we connect to those, they would presumably Refuse our connection.

After a (preferably user-definable) period of time, if the connection slots aren't all filled yet, uTorrent can offer encrypted connections to all those that had refused the un-encrypted connections, hopefully getting them on the bus.

Workable?

[hofshi]

this sounds like a good idea, Kazuaki.

[juniorx]

The further add to the confusion, i use BTComet with encryption enabled. For the first month, it worked awesome but then my speeds decreaed to 1-2KB/sec. Not sure how this will differ when the utorrent encryption is released. seems like isp throttling adapts to the encryption after awhile.

[kurahashi]

BitComet encryption is a goner. Detectable and recognizable, thus easily shapeable even using any linux based router.

Of course if uTorrent/Azu encryption method has any flaws they can share BitComet's fate. I hope it won't happen... we'll see.

[uusr]

Encryption is 2-way, not one-way, the only control you have is over who initiates the encrypted connection!

Not sure if that was in answer to me but I did say that although I probably worded it terribly so it wasn't clear what I meant. But I did say "in order for the remote party [Disabled] to get unrestricted data from you [Enabled] they will have to have their client set to encryption "Enabled", otherwise I think they'll only initiate a non-encrypted link into you" with emphasis on "initiate".

[Falcon4]

in order for the remote party [Disabled] to get unrestricted data from you...

^ *sigh*

Why do I have to go over this again?

Connections are only created, by one person or the other, and they never determine which way the data flows.

Do I really need to say any more?

[uusr]

in order for the remote party [Disabled] to get unrestricted data from you...

^ *sigh*

Why do I have to go over this again?

Connections are only created, by one person or the other, and they never determine which way the data flows.

Do I really need to say any more?

No, as I understand that fully. The point is *which side initiates the link*.

[castle]

seems to me that enabled by default is the way to go...

and that there are really only three sensible options for encryption settings

1) the throttled user

should be force encryption

legacy connections not allowed

2) the non-throttled user

attempt encrypted connection first, then legacy (that way you can always connect to everybody and in the case of a throttled peer who forgot to disallow legacy connections, you get the best speeds from them, thus helping the entire swarm)

allow legacy connections

3) the 'poor excuse for a computer' user (i.e., CPU and RAM can't handle the pressure)

encryption disabled

allow legacy connections

I can't see a good reason for a throttled user to operate in legacy mode ever

I can't see a good reason for a non-throttled user to avoid encryption, but also be able to work in legacy mode for the diehards who use mainline or bittornado or shadow or ABC

it seems to me that the current options are confusing people a lot. if it's this bad for people who actually come to the forums and are interested, what will happen when this is out to the masses.

[kurahashi]

seems to me that enabled by default is the way to go...

and that there are really only three sensible options for encryption settings

1) the throttled user

should be force encryption

legacy connections not allowed

Not quite. That really depends how much BT is being throttled.

If ISP is leaving some part of user bandwidth to BT (for example, 40% of it) then forcing encryption and disabling legacy connetions will be really bad idea.

I can't see a good reason for a throttled user to operate in legacy mode ever

Well, if he is 100% throttled then yes, but usually such users are somewhere in the middle of being throttled and non-throttled. Thus each case of such partially-throttled user must be resolved accordingly.

[Switeck]

The throttled user should use encryption by default but support legacy connections.

Only extremely throttled users should disable legacy connections.

[Falcon4]

I gotta agree with castle, except there should be two divisions of throttled - "throttled" and "REALLY throttled". If allowing legacy connections slows down your speed because of the ISP "finding out" what that port is being used for, you probably should disable it and force encryption, but that would limit you only to people who have encryption supported and enabled (note the "supported" part, because though we all want it, not everyone will be using µT!).

I enable encryption on mine because it may even give me better speeds as a non-throttled user - because when I connect to a shaped user in another country and I'm not encrypted, I'll get shitty speeds to/from them. Yuck.

So yeah. It would take a lot of explaining, though, to get people to understand what encryption is all about, so it's kinda mixed. People still don't even understand that incoming connections != a downloader, so it'll be extremely hard to explain enabled, disabled, etc...

[DomZ]

Probably best to have some sort of information page provided when the stable gets released (or just a direct link to that part of the FAQ)

[Firon]

Like I said in the other thread, ludde will consider making it default enabled, but it's not likely for 1.5, mainly because the connect performance blows in swarms where there's few PE-enabled peers.

[castle]

informative replies...

I hadn't heard of partly throttled people until the chello comments. Rogers seems to be all or nothing the way their customers talk about it, so completely encrypted is the only way to go for them.

in the private tracker world, the PE capable swarm will be quite large as the majority of peers seem to be Azureus or utorrent right now, which will be good.

if encryption is enabled but not forced, does that mean that the client will first attempt encrypted connection, then attempt legacy connection to the same IP?

is it the wasted encrypt attempt to a nonPE peer that is the reason for default disabled?

[Falcon4]

Pretty much. If the client an encrypted user connects to does not support encryption (e.g. most current µT users - note "SUPPORT" because if you encrypted-connect to a disabled user it'll still encrypt), it'll have to wait to time out first, then fall back to normal connection. It's that extra wasted time that makes it bad to enable it by default.

As far as "partially throttled" goes, that's caused by ISPs having a per-packet throttle going - if it detects a BT packet, it'll "shape" it and slow it down. By "fully-throttled", I (at least) am referring to ISPs that "intelligently" detect BT packets going through a user's port, then slow that whole port down for encrypted and standard, I'm guessing. The only reason you'd want to completely disallow legacy (normal) connections is if your ISP detects the BT traffic and slows your entire BT connection down because of it, despite the encryption.

But if it's only slowing down individual BT packets, then encryption-not-forced is a great plan. You'll still be able to connect to non-PE-supporting peers, and you'll get the added boost from peers that do support it.

Get it now?

[castle]

sounds good to me

[jblade]

Honestly the argument that encryption takes up too much CPU time is worthless. I have used it full encryption multiple torrents on a 400Mhz comp, causes little to no CPU use. Having Encryption not enabled by default will cause one thing, and that is making the traffic shaped pears into servers more or less. Why enable encryption, if your gonna just get the same download speed without having to worry about upload speed.

As far as public torrents go, most of those guys use Bitcomet still. I think the next push is for Bitcomet to adapt the same encryption standard, and to have all 3major torrent programs having encryption enabled by default.

If not enabled by default, then better detections of encrypted users, so that it actually does what Falcon thought it does, and that is if user is sending encrypted packets, then encrypted packets will automatically be sent back.

[Ultima]

To detect whether someone is encrypted or not, you have to connect anyhow, and the connection rate (as Firon said above) is a little lower with encryption enabled... so I'm not sure where that suggestion is leading =T

Either way (again, as Firon said above), ludde will consider it when PE is used more.

[Firon]

It already works like that, NO ONE READS! God.

all incoming encrypted connections are encrypted ffs, doesn't matter if YOU have it enabled or disabled, you only control YOUR outgoing connections

[jblade]

I know incoming are, but not outgoing. Whats the point if you connect to me first, and you upload non encryptedly and therefore I recieve a slow speed on my trafic shaped naetwork, while I send it fine cause I encryption enabled.

Edit: I dont know how you can say its working fine, when it is clear to me that it is not. When I see peer dl are in the 50-400 and i am uploading at 200 with a 7.0 ratio, and only recieving at 20 total. Yes most users on it are Azureus 2400 but still that shouldnt make a difference, as its the same protocol.

[Firon]

encryption is 2 way, it's either on, or it's not.

[hofshi]

jblade: did you try to uncheck "allow legacy" ?

[jblade]

hofshi why should I not check allow legacy. Just so I don't upload to the non encrypted users?

Whats the point in that.

clearly if they can accept my encrypted packets, they should be sending them back encrypted, but they are not.

[hofshi]

The allow legacy unchecked will mean that you will not accept unencrypted connections. If in addition to that you set outgoing encryption to forced, then you will only have encrypted connections. In the case of an ISP that is throttling you, this will make it pretty hard on your ISP to detect BT traffic.