UDP connection

[risingcloud]

the UDP initiation always shows 'connecting' instead of 'downloading'. even if the UDP manage to establish a connection and show 'downloading' it will last for a few seconds only. Eventually, all the UDP peers will disappear from the list. What do I need to do in order to make the UDP peers establish a proper connection and show the 'downloading' status just like TCP? udp1.bmp

I'm using bitcomet version 1.25 with ADSL internet connection. I'm using Innacomm W3100 ADSL modem. I had my listen port TCP and UDP forwarded in the modem and got a green light for my IP address. I'm using Windows XP SP3 with window firewall and Avast antivirus enabled. Both of the TCP and UDP port is opened in the firewall and router. I had set a static IP address as well. udp2.bmp Does anybody know the solution?

[kluelos]

There are no UDP downloads via bittorrent.

There's no such thing as a "UDP peer".

All bittorrent exchanges are natively conducted via TCP only.

DHT creates, maintains and promulgates a distributed database of peers interested in particular torrents. All of its communication is conducted via UDP, but none of this involves transfer of bittorrent metafiles, content blocks or pieces. DHT identifies peers for the client, but after that it's up to the client to contact the peers it chooses -- via standard bittorrent protocol over TCP.

DHT was "tacked on" and rides on top of, the existing bittorrent structure, having as its only point of contact the common "bucket" for interested peers. This is why and how it came to be adopted so widely, because it didn't involve deep changes in the code.

Once a peer is identified, whether it came from the tracker, PEX or DHT doesn't matter. They're all treated the same and do the same.

UDP is also lately used as an additional tracker protocol, but most trackers don't support it and for the few that do, supply exactly the same information over UDP as they do over TCP so you're effectively hammering the tracker twice at every scrape, to no purpose at all.

[greywizard]

The peers from your screenshot are LT-Seeding peers. LT-Seeding can use by default both TCP and UDP as transport protocols. Other than selecting the transport protocol in Advanced Options, you have no control on how connections between peers are being initiated, maintained or terminated; the whole thing is done automatically.

[risingcloud]

It looks to me like a peer because it was in the 'peers' tab with an IP address which seem like it was seeding at that time but bitcomet unable to connect to it. Now that i understand that it is actually a communication protocol that is not involve in any of the file transfer. It's just the status that confuse me a bit. 'connecting' seem to me like UDP tried to connect but took a very long time and failed in the end for some reason. Sometime it did manage to download a few hundred KB of data and sometime a few MB as well but it won't last long. Is that few KB/MB of data a communication data or like greywizard said it may act as a transport protocol and possibly transfer some downloaded data as well? (albeit not stable)

[greywizard]

Now that i understand that it is actually a communication protocol that is not involve in any of the file transfer.

You're confused, because you skipped your networking lessons. B) (You'll get an F for that.)

TCP and UDP are the only two major transport protocols of the Internet, for all intended purposes of our discussion. "Transport" here meaning that they they work at the Transport level of the 4-level TCP/IP network model. That is, they act as carriers for ANY higher-level protocol and DO NOT care what type of data they transport.

For the purpose of our discussion, ALL the protocols used by BitComet (or any other BitTorrent client for that matter) MUST use one of these 2 protocols for packing up their data (e.g. BitTorrent, DHT, LT-Seeding, HTTP, eDonkey, Kad are all protocols used by BitComet and they ALL use TCP or UDP for packing up their data).

When used by LT-Seeding, UDP, will carry file data too, as LT-Seeding is being used to help into the download of the BT task.

Perhaps, now you understand better.

The most important conclusion that you should draw from this, as I said above, is that because you have no control (through options) over the way LT-Seeding works, you shouldn't bother your mind with this, too much.

You can only enable/disable LT-Seeding and choose in Advanced Options, which transport protocol it will use (UDP, TCP or both). That's about all you can control in it.

[risingcloud]

ok, I think I had everything set up right for optimum download speed. Thanks kluelos and greywizard for the explanation.