Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About ReP0

  • Rank
    Advanced Member
  1. Because chances are most of us didn't upgrade to 1.8 and never will voluntarily. .
  2. The only reserved bits I'm aware of are in the peer handshake however it is my understanding that when a client talks to a tracker no such peer exchange occurs. All it is is a simple GET <> followed by a tracker response consisting of a bencoded reply. If I'm incorrect and a peer handshake occurs between the tracker and client then I really want to know since I'm currently working on a project for work and the sooner the better. I didn't factor that into a prelim design I have. At least I haven't seen anything in the specs nor on the wire indicating a handshake with the tracker so that is where my confiusion is arising. I uderstand that some trackers may want to filter on peerID to stop malicious clients or broken ones but there aren't any reserved bits so to speak of in a peerID.
  3. Threads a little long and with no thread search options (not that I could see) it makes it hard to tell whether its been asked before.. Can anyone expand on "Note to tracker staff: update your build checks! 1.8 is different from 1.7.7. The reserved bit is no longer set." What do you mean reserved bit and where would it be located.? TIA
  4. ReP0


    Please don't take this personally but I am forever astonished that people think that they understand a person completely just from interaction on a forum. I think it's a rather foolish notion. Maybe you need to live a little more but I've seen people who I thought I understood completley who I have known personally in the living flesh for years do things and make decisions I thought they would never do. Your justifications of risk based on your examples are somewhat dubious. In all of you examples we are not just trusting said parties to do there job on their own but they are also checked by third parties (government organisations to ensure safetly standards are met) to protect us. If that is not enough then there are serious consequences monetary wise for breaching that trust which would drive a company bankrupt. Money and success are significant driving factors in any business to do the right thing which is why penalties exist. It's not just shear trust without consequences that ensures that things are done right. In utorrents case there is no such deterrant or incentive for ludde to ensure that any trust we place is backed up. There are no third parties to check on him to ensure our interests. In fact if anything it's completley the opposite for us in this case. There are no penalties financially that can be inflicted and the fact that utorrent doesn't make a cent from us but can make significant $$ if it joins up commercially with parties (which may not be interested in our wellbeing) puts the general users at a significant disadvantage in the trust stakes. I'm sorry if you can't see or accept this. I may be completley off the mark in what utorrents intentions are or what it's future intentions are but for me I don't have blind faith based on a persons words in a forum as to the type of person they are. Actions are usually more important than words and taking this step has raised doubts more than I and I think quite a few people are comfortable with. The fact he entered into a business agreement and didn't do a background check on his partner to even know their history smacks of incompetance or a decision to mislead and feign ignorance after the fact. A person capable of writing the complexity of code utorrent requires usually has a bit of a clue so unfortunately I can only conclude the latter. Now tell me whether you think that trust of yours is still warranted?. I know what my answer would be and I'm re-installing azureus as we speak. PS: Please don't get me wrong. I don't have a problem with commercial ventures arising from such development in general but when a venture is undertaken with such a company that has such a history I think I and others have a right to doubt the aim of the venture especially with the source being private. Pity it wasn't a more innocent p2p friendly company... Edit: Well after installing Az2.4.0.0 for the first time and running it I just got 1Mbps xfer rate. alot more than ut ever did (even after tweaking forever following advice). I'm quite surprised by the difference (really, not trolling as in all the time torrenting I never got near to that speed). Dont want to make this into a speed thread (don't care anymore) but that with the recent events has clinched my decision. I didn't realize what I was sacrificing (even bc didn't get me there). Xfer cause PC to become a little slow for the record but given for the increase I'm ok using more resources to achieve those results. Farewell all!
  5. ReP0


    The fact that such an agreement was made with a company whose history has been tied to anti-p2p has concerned me more than enough to never touch utorrent ever again. Given that there are other clients out there that have no such ties means that I don't need to run the same level of risk as I do with utorrent and have blind faith in ludde's new deal or future deals. I guess thats the advantage open source offers. I don't see azureus for example going down this path and there are many people looking at the code so that we have a high level of confidence that nothing sneaky will happen along the way. I understand that there may be nothing untowards to tracking and reporting users at this point in time but a closed contract would have a clause that would state that if such a tack was taken it could not be reported. I also know that companies license software and use it in many creative ways the original authors never could foretell so who knows what they have in mind to exploit (if anything). Couple this with the fact that as time goes on the relationship can grow stronger between the two then any stats or whatever collected by ludde not yet released to his partner (or future partners) under the current contract can be released under a new contract and the situation can change over night now. There is nothing legally as users you can do to stop ludde releasing anything to anyone he gathers which has always been a risk with any client out there but given the new relationship the risk has increased significantly. More to the point he doesn't have to report all the changes he makes given the terms of the contract or future contracts. You can all go out of your way and make excuses of why no one should worry about the new agreement but given the options of other clients out there I don't believe it's worth the risk. Ludde doesn't owe anything to anyone and up till now has been doing us a favor in providing utorrent and we have been doing him a favor testing it and offering ideas but the fact it's moving in this direction should be a major concern to you all, not just in the current agreement, but what future agreements could be made. I know there will always be the die hard fans out there who will defend it till the end and I hope it works out for you all. I'm just glad I'm not hung up on any particular client though. I'll keep an interest in the forum just to see how this pans out though. It's an interesting development if nothing else. Personally I think from a financial standpoint the decision was understandable and I had a feeling it was going to have a commercial side to it but not in this particular direction. Pity, it was a reasonable client in the end..
  6. Yes I know the settings may be suboptimal but then one has to question why have them set like that. Simple answer I guess is a bad guess at what the average PC/network capability is and its being refined over time, quite understandable. Yes you can't get everyones PC optimal (well you can but that requires another optimisation module) but you have to take a guess at what the average PC out there is and tune to it so that users don't need to know how the protocol works or the internals of the implementation to get the best speeds. So in essence it is the clients (utorrent) fault because of the bad choice of defaults requiring the exposure of the user to the implementation/protocol specifics but there is a workaround, ie you tweak the settings assuming you have the experience/knowledge. I know this is freeware but I like I said from the beginning, if we can get better default values then we should have them so that newbs get a good out of box experience and threads like this become a thing of the past. I would assume vurlix and any others coding utorrent will see it as a fault (albeit minor in their eyes) in the client because as every software developer knows the straight out of box experience with minimimal configuration knowledge is what leads to a happy user. Sounds like that is happening so it's all good.
  7. Yet I keep hearing that azureus is better out of the box regardless. Remember I don't know whether it's true or not but for those advocating that there is a nice compromise on default values azureus has chosen then maybe we should do the same in utorrent. I have to admit I'm not clear on your point. At the end of the day if you load up both clients on the same PC with the same internet connection and one performs better than another then you can say that that client is faster for you and maybe we need a review site or two which is objective to tell us that if you have a low end machine spec then utorrent is better than azureus but otherwise it may not be. Again I don't use azureus so I don't know I'm just thinking out loud. At the end of the day I think you have to pick what a "common" spec PC for today is and use that as your baseline if you where to do a review. I would has it a guess that if you can afford an internet connection you have a PC that is more than capable of running most clients without problems. If you want to play games and stuff while torrenting that's another issue and imho not relevant to the speed argument for obvious reasons. Regardless there is nothing stopping you doing a test yourself to see which client is fastest for you. And so you have a client which if if has not implemented SP2 limits is shit slow and not worth the time regardless. At the end of the day I'm not too worried whether a client reaches steady state speed in 5 minutes or 10 minutes just so long as the difference is not stupidly large. What is of interest is the range of steady state speeds that are reached. As to your news about this limit rating it was fixed a while back with bitcomet fyi. I'll apologize ahead of time if I'm wrong but I think you don't understand the issue with event 4226 because you seem to imply that you are being limited by your peers client choice because of it. This limit is only applicable to outgoing connection you make and not incoming connections to your PC so you are not being limited by your peers client doesn't have this limit patch in it's client. The reason is that you are requesting a connection with them (so they exist and you exist) and there will be minimal time completing the connection so you are not waiting on anything. Event 4226 comes into play because you send out a connection request and wait. If the peer doesn't answer you wait for a default time. Enough time that other connection requests start piling up and you hit the limit. Not sure if that is clear but I hope you get the idea. To give you a unbiased opinion I am hangin for utorrents dht feature but until that day bitcomet is the superior client for torrenting in it's purest form without being a resource hog like azureus. Basically bitcomets speeds are comparable at least to utorrents and often are better especially when tracker troubles arise or you have a hard to find file you want to track down.. That is a fact for me which is why I've shelved utorrent until dht is here. To be honest the only reason I'm keeping an eye on utorrent is because I love the built in scheduler. Fanastic feature for a bt client.
  8. I disagree. If you let a torrent run for a bit and you get 60k with client A and if you try another client and get 5k for client B and go back to client A and get ~60k then it's pretty straight forward which is faster. At the end of the day it doesn't matter what the reason is for client B going so slow you just won't use it. I've done such comparisons in the past which have led me to bitcoment/utorrent as preferred clients. I don't like Azureus because it just so excessively slow starting up and consuming memory than I believe is adequate.
  9. I keep hearing azureus is fast out of the box with no tweaking so why is it that utorrent comes with a so called crap set of defaults? Surely we are shooting outselves in the foot if we don't get the defaults fixed or are we just making excuses. DHT may well be a factor in this guys speed issues but it will be interesting once DHT is implemented what the excuse will be if it continues. Please, if you are all convinced it is bad default values put in a feature request to get the values changed so that people get the same experience speed wise as azureus. I personally don't think it's the settings but I keep hearing it so... Currently it seems like it's analogous to asking a car owner to go into their engine management unit and start tweaking the map sensors and the like so the car works smoothly. Sure some of can do it and know how but most don't. Just for the record I don't have a problem with speed but then again I like to tweak so I never use defaults.