ты внимательно почитай 9ую и 10ую страници

Многоуважаемые, эт опросто замечательно что вы нашли и исправили ошибку, но кажется естьпобочный эффект, вероятно связаный с вашими экспериментами. У меня два файла докачались только после стоп-пуск, по другому они завершаться не хотели. Может конечно это и не связано
Выше уже была просьба - если надо поднастроить азурес как то не так, как у казано в руководстве пришпленом на форуме - скажите, или обновите руководство, благодароности пользователей не будет конца! ;-)

PS попробовал мторрент, вроде ничего, но азурес лучше

Скорее всего не связано. У меня и до исправлений бывало такое пару раз, стопорились некоторые релизы за несколько килобайт до конца и моментально докачивались после стоп/старта

Полностью поддерживаю Simvol_B: если трекер поддерживает Азур, то есть смысл обновить его топик (Про Azureus), я так понимаю, там есть чего исправить-добавить...

This post has been edited by iii333 on 30-04-2006, 23:00

Мы уже заняты этим вопросом Просто моментально не можем...

Главно что процесс пошел..... © ;-)

Извините, что спустя несколько дней возвращаю всех к этой теме. Просто сначала поверил, а несколько дней спустя вспомнил и задумался. Итак, цитата:

1) Каким образом делается вывод, что неспособность клиента общаться с другими клиентами по UDP "может значительно ограничивать скорость приема/отдачи".

2) Мне кажется, что overhead самого битторрент протокола куда больше, а разница между TCP и UDP не будет так сильно заметна. Впрочем, тут я разбираюсь не очень, поэтому спорить не буду.

3) Если какой-то клиент умеет общаться с пирами по UDP, а другие не умеют - значит по UDP он будет общаться только с такими же клиентами, как и он. Если (очень грубо) долю Azureus оценить в 30%, то получается, что две трети общения с пирами происходит все равно через TCP.

4) Ну и наконец самое главное - я нигде не нашел упоминания о том, что в Azureus реализовано общение с пирами через UDP.

Fellow
Спасибо, что поднял вопрос. Меня тоже интересует второй вопрос. Более того, что-то не пойму, как быть с тем, что в UDP отсутствует помехоустойчивость? Не получится ли, что накладные расходы TCP будут больше, чем повторно отосланные датаграммы? Ведь служебных данных вроде бы мало (сколько, кстати) и вес идет скорее от количества установленных и запрошенных соединений (каковые все равно идут по TCP), нежели от запросов чанков, которые теперь пойдут по UDP?!

This post has been edited by TCPIP on 05-05-2006, 00:17

Служебных данных дофига, особенно дурацких сообщений типа что у меня есть кусок (have) - я так понимаю что они идут в азуре по udp и если они теряются - то и хрен с ним Вы включите логер и поглядите что оно там (и с какой бешенной скоростью) пишет...

Ну, согласись, что это все же, как ни крути, та же вода, что мы слышим от тех, у кого другое мнение, кто считает, что UDP ничего не даст, так как служебных данных существенно меньше, чем запросов. Существенно это сколько? Дурацких сообщений, это сколько? Хотя бы в процентах.

ну я же тебе ответил - логер включи в азуре и посмотри сколько По станадрту как только ты сливаешь кусок - ты всем пирам об этом сообщаешь (have) - чем быстрее ты сливаешь и чем меньше куски - тем больше трафика идет на это. Я не считал сколько это в процентах, тем более что не понято в процентов от чего мы считаем Потом там не только have - там чоки, анчоки, хочу, не хочу и прочее - протокол весьма занудный и очень говориливый. Зависит от кол-во конкетов тоже - если у тебя скажем 100, то have идет 100 человекам, а если у тебя 1000 - то тысячи. Соотвественно посчитать весьма затруднительно. Чтобы перейти к цифрам - поставь скажем Хк аплоада, посмотри сколько сверху уходит - это и будет служебный трафик приминтельно к тебе

Так я и в µ эти сообщения вижу. И что? Сколько каждое размером?

Ну здесь как раз понятно --- от полезной информации. То есть от содержимого торрента. Как минимум. Плюс, от такой бесполезной, как число запросов на подключение и прочая.

Тогда на основании чего делается утверждение о выгодности смены протокола?

У себя я уже подсчитал. При простое, когда все работает лишь на отдачу (то есть полезная информация идет только по обратному каналу), клиентов в сварме не более 2-3, получается, что нагрузка на простаивающий прямой канал составляет 3% от всей нагрузки по обратному каналу. Не так уж и мало. Хотя, сказывают, будто бы это и есть тот самый процент накладных расходов TCP, от которого хошь не хошь, никуда не деться. Вполне может быть. Проверить, стало быть, просто, если бы иметь что-то на udp. Так как грубо говоря получается, что нагрузка есть sum(Ui; Di, s={pl, p, s}), где U - нагрузка обратного канала, D --- нагрузка прямого, pl --- нагрузка полезных данных, p --- нагрузка протокола транспорта (те самые накладные расходы), s --- нагрузка служебных сообщений протокола торрента. Но у меня ничего нет. Вот я и спрашиваю, раз тут пошла речь об экономии при смене протокола, какова экономия.
Интересно просто. Может, у кого есть много торрентов на UDP и с примерно таким же распредлением клиентов, что и на TCP, возьмет статистику за сутки, да и покажет. Вдруг?

На, считай


Peer wire protocol (TCP)
Overview
The peer protocol facilitates the exchange of pieces as described in the metainfo file.

Note here that the original specification also used the term "piece" when describing the peer protocol, but as a different term than "piece" in the metainfo file. For that reason, the term "block" will be used in this specification to describe the data that is exchanged between peers over the wire.

A client must maintain state information for each connection that it has with a remote peer:

choked: Whether or not the remote peer has choked this client. When a peer chokes the client, it is a notification that no requests will be answered until the client is unchoked. The client should not attempt to send requests for blocks, and it should consider all pending (unanswered) requests to be discarded by the remote peer.
interested: Whether or not the remote peer is interested in something this client has to offer. This is a notification that the remote peer will begin requesting blocks when the client unchokes them.
Note that this also implies that the client will also need to keep track of whether or not it is interested in the remote peer, and if it has the remote peer choked or unchoked. So, the real list looks something like this:

am_choking: this client is choking the peer
am_interested: this client is interested in the peer
peer_choking: peer is choking this client
peer_interested: peer is interested in this client
Client connections start out as "choked" and "not interested". In other words:

am_choking = 1
am_interested = 0
peer_choking = 1
peer_interested = 0
A block is downloaded by the client when the client is interested in a peer, and that peer is not choking the client. A block is uploaded by a client when the client is not choking a peer, and that peer is interested in the client.

It is important for the client to keep its peers informed as to whether or not it is interested in them. This state information should be kept up-to-date with each peer even when the client is choked. This will allow peers to know if the client will begin downloading when it is unchoked (and vice-versa).

Data Types
Unless specified otherwise, all integers in the peer wire protocol are encoded as four byte big-endian values. This includes the length prefix on all messages that come after the handshake.

Message flow
The peer wire protocol consists of an initial handshake. After that, peers communicate via an exchange of length-prefixed messages. The length-prefix is an integer as described above.

Handshake
The handshake is a required message and must be the first message transmitted by the client.

handshake: <pstrlen><pstr><reserved><info_hash><peer_id>

pstrlen: string length of <pstr>, as a single raw byte
pstr: string identifier of the protocol
reserved: eight (8) reserved bytes. All current implementations use all zeroes. Each bit in these bytes can be used to change the behavior of the protocol. An email from Bram suggests that trailing bits should be used first, so that leading bits may be used to change the meaning of trailing bits.
info_hash: 20-byte SHA1 hash of the info key in the metainfo file. This is the same info_hash that is transmitted in tracker requests.
peer_id: 20-byte string used as a unique ID for the client. This is the same peer_id that is transmitted in tracker requests.
In version 1.0 of the BitTorrent protocol, pstrlen=19, and pstr="BitTorrent protocol".

The initiator of a connection is expected to transmit their handshake immediately. The recipient may wait for the initiator's handshake, if it is capable of serving multiple torrents simultaneously (torrents are uniquely identified by their info_hash). However, the recipient must respond as soon as it sees the info_hash part of the handshake. The tracker's NAT-checking feature does not send the peer_id field of the handshake.

If a client receives a handshake with an info_hash that it is not currently serving, then the client must drop the connection.

If the initiator of the connection receives a handshake in which the peer_id does not match the expected peer_id, then the initiator is expected to drop the connection. Note that the initiator presumably received the peer information from the tracker, which includes the peer_id that was registered by the peer. The peer_id from the tracker and in the handshake are expected to match.



Messages
All of the remaining messages in the protocol take the form of <length prefix><message ID><payload>. The length prefix is a four byte big-endian value. The message ID is a single decimal character. The payload is message dependent.

keep-alive: <len=0000>
The keep-alive message is a message with zero bytes, specified with the length prefix set to zero. There is no message ID and no payload. Peers may close a connection if they receive no messages for a certain period of time, so a keep-alive message can be sent to maintain the connection. A keep-alive message is generally sent once every two minutes.

choke: <len=0001><id=0>
The choke message is fixed-length and has no payload.

unchoke: <len=0001><id=1>
The unchoke message is fixed-length and has no payload.

interested: <len=0001><id=2>
The interested message is fixed-length and has no payload.

not interested: <len=0001><id=3>
The not interested message is fixed-length and has no payload.

have: <len=0005><id=4><piece index>
The have message is fixed length. The payload is the zero-based index of a piece that has just been successfully downloaded and verified via the hash.

Implementer's Note: That is the strict definition, in reality some games may be played. In particular because peers are extremely unlikely to download pieces that they already have, a peer may choose not to advertise having a piece to a peer that already has that piece. At a minimum "HAVE supression" will result in a 50% reduction in the number of HAVE messages, this translates to around a 25-35% reduction in protocol overhead.

A malicious peer might also choose to advertise having pieces that it knows the peer will never download. Due to this attempting to model peers using this information is a bad idea

bitfield: <len=0001+X><id=5><bitfield>
The bitfield message may only be sent immediately after the handshaking sequence is completed, and before any other messages are sent. It is optional, and need not be sent if a client has no pieces.

The bitfield message is variable length, where X is the length of the bitfield. The payload is a bitfield representing the pieces that have been successfully downloaded. The high bit in the first byte corresponds to piece index 0. Bits that are cleared indicated a missing piece, and set bits indicate a valid and available piece. Spare bits at the end are set to zero.

A bitfield of the wrong length is considered an error. Clients should drop the connection if they receive bitfields that are not of the correct size, or if the bitfield has any of the spare bits set.

request: <len=0013><id=6><index><begin><length>
The request message is fixed length, and is used to request a block. The payload contains the following information
index: integer specifying the zero-based piece index
begin: integer specifying the zero-based byte offset within the piece
length: integer specifying the requested length.
According to the official specification associated with mainline version 3, "All current implementations use 2^15 (32KB), and close connections which request an amount greater than 2^17 (128KB)." As of version 4 of the mainline, this behavior was changed to use 2^14 (16KB) blocks, and that size was enforced against peers that tried to request more. Note that block requests are smaller than pieces (>=2^18 bytes), so multiple requests will be needed to download a whole piece.

Due to the new version of the mainline placing the limit at 16KB, attempting to use 32KB blocks can best be compared to playing Russian Roulette with about 4 bullets, you'll likely run into trouble at this time. Smaller requests will result in higher overhead mostly in time and space due to the overhead of tracking a greater number of requests. As a result imlementers should likely used 16KB as all clients will allow that.

The choice of request block size limit enforcement is not nearly so clear cut. With mainline version 4 enforcing 16KB requests, most clients will use that size, there is one crucial group of clients that will not. Most older clients use 32KB requests and disallowing those will distinctly shrink the set of possible peers. At the same time 16KB is the semi-official (only semi because the official protocol document has not been updated) limit now, so enforcing that isn't wrong. At the same time, allowing larger requests enlarges the set of possible peers, and except on very low bandwidth connections (<256kbps) multiple blocks will be downloaded in one choke-timeperiod, thus merely enforcing the old limit causes minimal performance degradation. Due to this factor, it is recommended that only the older 128KB limit be enforced.

piece: <len=0009+X><id=7><index><begin><block>
The piece message is variable length, where X is the length of the block. The payload contains the following information
index: integer specifying the zero-based piece index
begin: integer specifying the zero-based byte offset within the piece
block: block of data, which is a subset of the piece specified by index.
cancel: <len=0013><id=8><index><begin><length>
The cancel message is fixed length, and is used to cancel block requests. The payload is identical to that of the "request" message. It is typically used during "End Game" (see the Algorithms section below).

port: <len=0003><id=9><listen-port>
The port message is sent by newer versions of the Mainline that implements a DHT tracker. The listen port is the port this peer's DHT node is listening on. This peer should be inserted in the local routing table (if DHT tracker is supported).

Ну вот, я же еще и считай . Ei incumbit probatio, qui dicit, non qui negat. Ладно, наверное действительно нужно почитать эту вашу спецификацию, а не воду в ступе толочь. Только вот там про UDP ни слова. То есть мы посчитаем (U, D)s и все...

This post has been edited by TCPIP on 05-05-2006, 15:25

Еще раз. Клиенты для обмена кусками файла между собой общаются по TCP и только по TCP. За исключением использования UDP NAT Traversal в BitComet и BitSpirit.

Нет отдельных TCP торрентов, нет UDP торрентов. Если внутри торрент файла ты где-то увидел "UDP", то видимо это относилось к адресу UDP трекера.

Я так думаю. Или давайте все так думать, или наконец покажите мне, где я неправ :)

This post has been edited by Fellow on 05-05-2006, 15:45