rafi Posted February 4, 2006 Report Share Posted February 4, 2006 Test case : * Running Build 417* PHE - "Enabled" mode (supports legacy peers as well)* openoffice torrent (~ 60 seeds, ~20-30 on-line)The intentions was: to be able to, eventually, when many peers will support PHE, bypass some ISPs' capsThe problem may be: This will be a gradual process. During this (long) time people will have many peers that *do not* support PHE, and will not want to degrade uT performance (and timing/aggressiveness) BECAUSE of it's PHE support. If the performance will degrade - people will disable it, and it will not have a chance to 'evolve'.The gaol : Achieve similar uT performance in both PHE "enabled" and "disable" modesTesting w/o PHE (disabled): uT is very quickly connecting to about 20-30 seed-peers in 2-5 seconds! nice!Testing with PHE("enabled", not forced!): uT is getting one peer at a time, with a timeout/delay of about 10-20 sec in between peers' connections, resulting in about 6-10 min. to connect to 20 peers. Too slow! [that is - if I was not doing somthing wrong...]Suggestion:Find a quicker way to achieve the fast connect-time to the legacy peers (not supporting PHE) . As I see it - there is no reason not to try connecting to peers in parallel (as before ?) thus achieving a total delay/timeout - equals to that of trying to connect to one peer.A difference approach can be to start with non PHE mode, and then try to use the PHE (on a different defined port ?) peer by peer . This might effect the ISP detection of BT traffic, but - hey , even connecting to one legacy peer can cause to cap the traffic... and also there is a "enable alway" mode if you want...All in all - I personally do not believe in this being an effective , long lasting method to prevent ISP caps, but this is another story... Link to comment Share on other sites More sharing options...
splintax Posted February 4, 2006 Report Share Posted February 4, 2006 Well, basically, if you have PHE disabled, you can still accept connections from encrypted peers (unless you have legacy mode forced, which is a "bad idea" )So even if everyone has PHE disabled, if one person comes onto the scene with PHE they will be able to connect to everyone.There is no real reason to enable PHE unless your ISP filters your internet connection. If you do enable it, you simply slow down µTorrent as it has to wait for the encrypted request to time out before falling back to standard, non-encrypted communications. Link to comment Share on other sites More sharing options...
Firon Posted February 4, 2006 Report Share Posted February 4, 2006 There is no legacy mode anymore, and yes, that's correct, there's no point turning it on unless you need it, because the reduced connection performance is inevitable. Link to comment Share on other sites More sharing options...
rafi Posted February 4, 2006 Author Report Share Posted February 4, 2006 Firon & splintax - If you want to give this PHE any change to really evolve and be used, we need people to leave is ON (enabled) as a default. splintax - I'm not talking about "being able to..." but how fast (=performance/aggressiveness of connecting). "the real reason" (?) - is also helping others and not only yourselfFiron: doesn't "legacy mode" = disabled ? and about "you need it" - see above...bottom line - try to get the connect performance (not CPU...) like it was w/o PHE. Link to comment Share on other sites More sharing options...
Firon Posted February 4, 2006 Report Share Posted February 4, 2006 * Disabled: Does not encrypt outgoing connections, but will accept encrypted incoming connections. * Enabled: Attempts to encrypt outgoing connections, but will fall back to an unencrypted mode if the connection fails. * Enabled, Always: Attempts to encrypt outgoing connections, and will NOT fall back to an unencrypted mode if the connection fails. * Allow legacy incoming connections enables or disables incoming legacy (non-encrypted) connections.There is NO way to turn off accepting encrypted connections. You ALWAYS accept them, what you can control is making them. So, it doesn't matter what people set it to, the ones who actually need it, can turn it on and it'll work so long as there's someone running a PE-enabled client.The reduced performance in connecting is inevitable unless there's lots of µT/Az peers in the swarm, and there's no way around this. That is why PE defaults to Disabled (and if you look to the left, it says Outgoing) Link to comment Share on other sites More sharing options...
rafi Posted February 4, 2006 Author Report Share Posted February 4, 2006 There is NO way to turn off accepting encrypted connectionsI fully agree, but I was talking on initiating connections to othersThe reduced performance in connecting is inevitableI have to disagree with this FAQ fellow ... , but I'm not so familiar with the theory and the implementation.I suggest to ask ludde about this. My belief is - that it IS possible to implement if more efficiently like I suggested. But as ludde once said - it can be only in my imagination... Link to comment Share on other sites More sharing options...
Snapphane Posted February 4, 2006 Report Share Posted February 4, 2006 I was going to make a post about that, since I', confused with the settings. I tested "Encryption on" and I had like 5 peers (on OpenOffice) and speeds that of course was terrible. Then I tested "Encryption on, Always" and now it worked like a charm The thing I DON'T get is that with "Encryption on, Always" it should ONLY use encryption, but I had lots of non-encrypted connections as well as "handshake only" (flagged with the lower case e). So is this some sort of bug or is it just me who don't get it?But as I conclusion: YES you can get great speeds with an encryption turned on, as long as you also except non-encrypted connections (both ways). I for one will continue to run this, at least for awhile Link to comment Share on other sites More sharing options...
rafi Posted February 4, 2006 Author Report Share Posted February 4, 2006 r u sure we are talking on the same version ? 417 ?and if u do - don't u see a BIG difference in the time it takes uT to collect/connect/start-DL from many seeds when it is enabled vs disabled ? Link to comment Share on other sites More sharing options...
splintax Posted February 4, 2006 Report Share Posted February 4, 2006 This seems to be really confusing for a lot of people, so I'll try to explain. This is at least how µTorrent is supposed to work:Encryption disabled: µTorrent will not encrypt communications by default. However, if it receives encrypted communication, it will attempt to decrypt it and continue to communicate using encryption with that peer. Recommended if your ISP is not throttling - you are NOT harming encrypted peers by using it.Encryption enabled: µTorrent will encrypt all outgoing communications. If no response is received (that is, the client you're trying to talk to does not understand encryption) then µT will fall back to "legacy mode", that is, unencrypted. Recommended to try first if you have some sort of throttling going on.Encryption enabled always: µTorrent will encrypt all communications. If no response is received because the other peer doesn't support encryption, µTorrent cannot communicate with that peer. Recommended only when your service provider is limiting ALL communications once BitTorrent is connected, and as a last resort only.In build 413 (which I was basing what I said earlier on), there was an option called Force Legacy Mode, which basically meant µTorrent behaved as if it had no PHE support whatsoever. There is no real reason to have this option, so it was removed because it hurts peers that need to use encryption.Firon, let me know if anything I said is incorrect. Link to comment Share on other sites More sharing options...
dAbReAkA Posted February 4, 2006 Report Share Posted February 4, 2006 splinax enabled doesn't fall back to normal though.. Link to comment Share on other sites More sharing options...
rafi Posted February 4, 2006 Author Report Share Posted February 4, 2006 Thanks for the clear explanation. To me, at least, most of it was known before, and it cleared a few more points. I agree with it all.The point I was trying to raise - was related to the implementation of the "enabled" mode, and if it must have an impact on the performance. Also , I was pointing out - that if we want the PHE mode to spread/evolve THIS should be the preferred default mode , and eventually - all users should be using it....If no response is received (that is, the client you're trying to talk to does not understand encryption)I believe these are the most common cases now , and those are causing the delay in creating connections. It's implementation should be improved if possible. See my suggestions above. Link to comment Share on other sites More sharing options...
rafi Posted February 4, 2006 Author Report Share Posted February 4, 2006 splinax enabled doesn't fall back to normal though..I think it does. Anyway - it should... Link to comment Share on other sites More sharing options...
chaosblade Posted February 4, 2006 Report Share Posted February 4, 2006 Well, since "Disabled\Enabled\Always" relates to YOUR outgoing connections, the default mode doesnt really matter, And for performance reasons might aswell stay on disabled.Now, as for the "Allow legacy.." box to be unchecked, THAT is the bad point. If people just turn off allowing throttled peers to connect to them in an encrypted manner.. Link to comment Share on other sites More sharing options...
dAbReAkA Posted February 4, 2006 Report Share Posted February 4, 2006 at the moment it doesn't but ludde said he has already fixed that for the next beta Link to comment Share on other sites More sharing options...
rafi Posted February 5, 2006 Author Report Share Posted February 5, 2006 Yes, looks like in build 418 the timeouts are much better! It took abgout 10sec to establish about 20 connections peers-seeds (in openoffice) ! very similar to the performance in the "legacy" mode before.BTW I propose to rename the PHE "enabled" to "auto-detect" so it will be understood better (this term is also used in BitComet... so some potential users are allready familar with it...) Link to comment Share on other sites More sharing options...
Firon Posted February 5, 2006 Report Share Posted February 5, 2006 the point of allow legacy is so throttled users can turn it off and only have encrypted connections, since a throttled connection will be of no use to them or the other people and just waste connection slots (most of the time, there's few ISPs that do "reasonable" shaping) Link to comment Share on other sites More sharing options...
Vectorferret Posted February 6, 2006 Report Share Posted February 6, 2006 BTW I propose to rename the PHE "enabled" to "auto-detect" so it will be understood better (this term is also used in BitComet... so some potential users are allready familar with it...)That's not a bad idea, it is more self intuitive than the way it is. I'd prefer "Encrypt When Asked By Other Peer Only", "Encrypt When Possible" or "Opportunistic Encryption" (like PGP) and "Encrypt Always" with a warning that "Encrypt Always" will make it impossible to make an outgoing connection to non-encrypted peers. Link to comment Share on other sites More sharing options...
Falcon4 Posted February 6, 2006 Report Share Posted February 6, 2006 Allow me to propose some more understandable options... if I read this properly...Disabled => Incoming OnlyEnabled => Auto In & OutForce Enable => Force In & OutThat took a few minutes of thinking, but it seems to make the most sense, and a heck of a lot more sense than "disabled, enabled, force enable". But then, the lack of a "disabled" option would prompt people to ask about such an option, wouldn't they? Link to comment Share on other sites More sharing options...
Firon Posted February 6, 2006 Report Share Posted February 6, 2006 Well, is it really that hard to understand right now? After all, it says Outgoing next to it... Link to comment Share on other sites More sharing options...
Falcon4 Posted February 6, 2006 Report Share Posted February 6, 2006 *checks options page*Why are people complaining then? Link to comment Share on other sites More sharing options...
splintax Posted February 6, 2006 Report Share Posted February 6, 2006 Disabled => Incoming OnlyEnabled => Auto In & OutForce Enable => Force In & OutThese do make sense to me. I was able to grasp what the options meant relatively quickly, but apparently a lot of people weren't able to. :/For the last time, it does not matter whether you "enable" encryption or not - you are still helping it to spread and therefore making the feature useful. Link to comment Share on other sites More sharing options...
1c3d0g Posted February 6, 2006 Report Share Posted February 6, 2006 I concur with Splintax. Falcon4's explanation is crystal clear. Link to comment Share on other sites More sharing options...
Firon Posted February 6, 2006 Report Share Posted February 6, 2006 Enable and Enable, always only control out, not inencrypted in is always allowed (and normal in is controlled by a separate checkbox) Link to comment Share on other sites More sharing options...
Falcon4 Posted February 6, 2006 Report Share Posted February 6, 2006 I concur with Splintax. Falcon4's explanation is crystal clear. I'm not sure if he was saying "There was nothing wrong with the way it was said before" or if he was saying "I love his explanation".I wrote those with the option "Encryption: " in mind, not "Encryption - Outgoing: " in mind. Wasn't until I looked at the options page (DUH!) that I realized it already made sense. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.