Archived

This topic is now archived and is closed to further replies.

ludde

µTorrent 1.5 released

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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 improvements

Notable fixes:

* Occassionally encrypted connections would send invalid data

...

I hope they did a better job in fixing that then in spelling "Occassionally"... :P

Share this post


Link to post
Share on other sites

µ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?

Share this post


Link to post
Share on other sites

Yeah, because as of right now, some BitComet-users leech the hell out of my initial seed of a 7 GB torrent.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Public betas usually take a while to come out after a stable release. Currently, there is no beta (not even private)

Share this post


Link to post
Share on other sites

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"?

15handshake9bf.jpg

Share this post


Link to post
Share on other sites

Weird... maybe it's a client that's spoofing. 'Cause µTorrent 1.5 cannot make outgoing handshake only encrypted connections, only receive.

Share this post


Link to post
Share on other sites

About UDP protocol on tracker:

this in the connection status of the server

pinolallo@xxxxx# netstat -nap tcp | wc -l

10298

pinolallo@xxxxxx# netstat -nap udp | wc -l

7

You 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/protocol

here the stats of a 6 min of tracker trafic announces monitoring

tcp announces 37588

udp announces 12715

percentile udp/tcp announce ratios ratio 33,8272853

announces/sec 139,73

think 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.

Share this post


Link to post
Share on other sites

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 fun

netstat -an -tcp | egrep ":<tracker port>" | egrep -c "ESTABLISHED"

and see how many ESTABLISHED connections there are, rather than ones that are timing out.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.