Jump to content

µTorrent 1.5 released


ludde

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?

Link to comment
Share on other sites

  • Replies 427
  • Created
  • Last Reply

Top Posters In This Topic

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

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment
Share on other sites

Archived

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


×
×
  • Create New...