darkX Posted March 17, 2006 Report Share Posted March 17, 2006 hey guys, just got the new release. problem is i keep getting security alerts from my norton asking me to permit utorrent. its really annoying coz it popsup very often. i have set the program control on the worm protection settings to "permit all" but i still have these alerts. is there a way to fix this? Link to comment Share on other sites More sharing options...
Ultima Posted March 17, 2006 Report Share Posted March 17, 2006 http://www.utorrent.com/faq.php#Norton_keeps_prompting_whether_to_permit_or_block_.C2.B5Torrent.21 Link to comment Share on other sites More sharing options...
rafi Posted March 17, 2006 Report Share Posted March 17, 2006 FYI - Azureus officially released 2.4.0.2 with their encryption algorithm fixed , so I believe our Hash-fails problem in Encrypted mode - is going to disappear soon... Bug fixes and performance improvementsNotable fixes:* Occassionally encrypted connections would send invalid data ...I hope they did a better job in fixing that then in spelling "Occassionally"... Link to comment Share on other sites More sharing options...
shadek Posted March 17, 2006 Report Share Posted March 17, 2006 µTorrent needs to implement a system which prevents the abuse of the 'super-seeding'-mode. BitComet abuses it. Bittornado already fixed this... would it be possible to see this in the comming release of µTorrent? Link to comment Share on other sites More sharing options...
1c3d0g Posted March 17, 2006 Report Share Posted March 17, 2006 That's a great idea, Shadek. Link to comment Share on other sites More sharing options...
shadek Posted March 17, 2006 Report Share Posted March 17, 2006 Yeah, because as of right now, some BitComet-users leech the hell out of my initial seed of a 7 GB torrent. Link to comment Share on other sites More sharing options...
Technarch Posted March 18, 2006 Report Share Posted March 18, 2006 I haven't done this, but you could always ban all clients except azureus and utorrent simply by making encryption a required field in your client. Link to comment Share on other sites More sharing options...
Firon Posted March 18, 2006 Report Share Posted March 18, 2006 Pretty much, lol. Link to comment Share on other sites More sharing options...
rafi Posted March 18, 2006 Report Share Posted March 18, 2006 ...and except BitComet as well... Link to comment Share on other sites More sharing options...
darkX Posted March 18, 2006 Report Share Posted March 18, 2006 http://www.utorrent.com/faq.php#Norton_keeps_prompting_whether_to_permit_or_block_.C2.B5Torrent.21thanks Ultima! Link to comment Share on other sites More sharing options...
Firon Posted March 18, 2006 Report Share Posted March 18, 2006 BC 0.63, which like no one has. Link to comment Share on other sites More sharing options...
shadek Posted March 18, 2006 Report Share Posted March 18, 2006 This is true. I only wish I didn't have to force encryption mode. Link to comment Share on other sites More sharing options...
kulmegil Posted March 18, 2006 Report Share Posted March 18, 2006 I wonder : dev. is taking his just rest after release or something changed about beta policy? In any way - You did really a great job so far, especially with 1,5 release (didn't take time to write it sooner) Link to comment Share on other sites More sharing options...
The Mighty Buzzard Posted March 18, 2006 Report Share Posted March 18, 2006 You could always just block incoming BC handshakes. That mitigates a lot of BC's bad behavior by keeping it from being able to connect and disconnect to get itself unchoked but still lets you connect to BC clients. As Firon said though, this excludes BC 0.63. It's pretty easy to do with Kerio but you'll have to figure it out yourself for anything else. Link to comment Share on other sites More sharing options...
Technarch Posted March 18, 2006 Report Share Posted March 18, 2006 So why not write some code in utorrent:if client flag choke and client disconnect and client reconnect right after flag, then put flag back on the new connection and let them wait in line for optimistic unchoke. Link to comment Share on other sites More sharing options...
Firon Posted March 18, 2006 Report Share Posted March 18, 2006 Public betas usually take a while to come out after a stable release. Currently, there is no beta (not even private) Link to comment Share on other sites More sharing options...
Stone Posted March 19, 2006 Report Share Posted March 19, 2006 I have a question about encryption flags. I've never seen "e" (not "E") flag in later beta builds, but now in 1.5 stable, i see some "e" flags, does it realy use "handshake only"? Link to comment Share on other sites More sharing options...
Firon Posted March 19, 2006 Report Share Posted March 19, 2006 Weird... maybe it's a client that's spoofing. 'Cause µTorrent 1.5 cannot make outgoing handshake only encrypted connections, only receive. Link to comment Share on other sites More sharing options...
pinolallo Posted March 20, 2006 Report Share Posted March 20, 2006 About UDP protocol on tracker:this in the connection status of the serverpinolallo@xxxxx# netstat -nap tcp | wc -l 10298pinolallo@xxxxxx# netstat -nap udp | wc -l 7You will say: but why are asking for udp protol if the connections status for udp has a 1000 times less impact against tcp?Because effectively the tracker udp traffic is the 33% of the total tracker traffic but has a evident very less impact on the system than tcp/protocolhere the stats of a 6 min of tracker trafic announces monitoringtcp announces 37588udp announces 12715percentile udp/tcp announce ratios ratio 33,8272853announces/sec 139,73think about that the tracker respond to a 151 announce+scrape/sec In my opinion there is a large payoff about udp tracker protocol that should be considered beside the opinion of a "brainDead" protocol spec. Link to comment Share on other sites More sharing options...
DreadWingKnight Posted March 20, 2006 Report Share Posted March 20, 2006 Efficency at the cost of data accuracy isn't efficency at all.UDP itself (not udp tracker) is for situations where data needs to get there FAST but doesn't need to concern itself with getting damaged along the way. The largest use of UDP is in multiplayer computer games, where latency is more of a concern than data reliability.There are only TWO tracker packages that are otherwise spec compliant that support UDP tracker.The number of tracker packages that support the HTTP tracker standard is FAR larger.The current STANDARD HTTP announce protocol permits the inclusion of scrape information (seed/peer counts) in the announce reply.Just for funnetstat -an -tcp | egrep ":<tracker port>" | egrep -c "ESTABLISHED"and see how many ESTABLISHED connections there are, rather than ones that are timing out. Link to comment Share on other sites More sharing options...
Klaus_1250 Posted March 23, 2006 Report Share Posted March 23, 2006 I don't see why that makes a difference. Whether or not the TCP-connections is an established one, or in another state, the port is still in an used state.Another point; how much accuracy is absolutely neccessary? And how expensive is that accuracy? Another problem with TCP is that you (tracker) are also dependend on how well people configured their TCP-stack, how good the TCP-stack actually is and how good the connection actually is (packet-loss, latency, etc).Looking at my own TCP-logs, I'm sometimes baffeled about what I see. Ridiculous MTU-sizes, ACK's that seemed to get lost leading to useless resends, extremely high latencies, etc. I can imagine that a tracker can have a pretty though time dealing with those. Link to comment Share on other sites More sharing options...
jyopp Posted March 23, 2006 Report Share Posted March 23, 2006 UDP itself (not udp tracker) is for situations where data needs to get there FAST but doesn't need to concern itself with getting damaged along the way. The largest use of UDP is in multiplayer computer games, where latency is more of a concern than data reliability.Well, it's also *very* useful when the protocol itself can manage its own retransmissions and/or error control. I've worked on projects where varying amounts of data (like in a game!) need to be sent regularly (read: hundreds to hundreds of thousands of times per hour). In situations like this, even if you need to retransmit every packet several times, you make up for it by sending *updated* information until it gets through. And remember, TCP is retransmitting the information as well, it's just done at a higher level and with more overhead.Trackers benefit from this; They serve information to clients often, clients receive the same information, and clients always want the most current data. UDP is a 'send-and-forget' system, where the server doesn't keep connections open, it just fires off some packets aimed at the client and moves on to the next request. If the receiver gets corrupted or incomplete data, or doesn't receive a timely response, it requests it again.The advantage TCP has is when you want to send a LOT of information that is contiguous and specific to each client/request pair. TCP implementations make sure that all the packets arrive, that they're all in order, and can retransmit individual packets as needed from its buffers. While this seems like a great savings in bandwidth (and it is for lots of things!), it also requires the communications stack to cache outbound data for each of its active connections, and it imposes this (comparatively) massive, continuous two-way conversation between the client and server, and it requires a lot of memory usage and processor time on the server.Hopefully, the UDP tracker protocol is well written (we'll assume this is the case). Client A requests an update (basically, a changelog) by sending a torrent ID with the timestamp from its last checkup. The server finds that there are 4 changes in its log since that time, and sends "{4byteNewTS}+{4byteIP}-{4byteIP}+{4byteIP}*{4byteIP}" back to the client, adding two new IPs, removing a dropout, and converting one peer into a seed, for a total of 24 bytes. With smaller packets like these, overhead is really going to add up. *If there are no changes, you are sending only 4 bytes (timestamp).* TCP uses a 24-byte header per packet (plus 12 more for timestamps, if used), and UDP only 8 (100-150% vs. 33% in our example), plus the client is getting newer information if it needs a retransmit. Link to comment Share on other sites More sharing options...
Firon Posted March 23, 2006 Report Share Posted March 23, 2006 the UDP tracker protocol isn't well written Link to comment Share on other sites More sharing options...
B!LL Posted March 24, 2006 Report Share Posted March 24, 2006 Could you tell us if there will be a new public beta this month? Link to comment Share on other sites More sharing options...
1c3d0g Posted March 24, 2006 Report Share Posted March 24, 2006 Why? :| Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.