4

I'm trying to understand how to correctly implement p2p communication for the torrent protocol. Specification is not clear on this account.

If I, as a client, connect to a peer, then send the handshake, establishing communication, then I can send messages to that peer and receive responses. That is quite understandable from the client standpoint. What I don't understand is if the peer wants to send certain requests to me, in this case the peer is in a client role and I'm a peer in regards to it, will it use the same opened connection which I initiated or will it try to establish a new connection?

That leads to another question. Is it possible or is it normal to establish multiple connections to the same peer?

alex.49.98
  • 609
  • 5
  • 13

1 Answers1

4

in this case the peer is in a client role

As far as the wire protocol goes there is no special 'client role' distinct from a server role. Both peers are equal and perform and support the same set of operations - give or take some protocol extensions.

Hence peer-to-peer.

The term client in the context of bittorrent simply means any participant in the network. In specs it's often used interchangeably with implementation and peer.

TCP connections are bidirectional. In bittorrent each stream consist of an endless flows of messages that is not in lockstep with the other direction. I.e. there is no request-response cycle.

Is it possible or is it normal to establish multiple connections to the same peer?

possible? yes, assuming the <source IP, source port, destination IP, destination port> tuple is distinct, which basically is what TCP demands.

But other implementations are likely to drop duplicate connections.

the8472
  • 40,999
  • 5
  • 70
  • 122
  • There is one more thing which is not clear. Is it one connection per torrent? I guess only one handshake can take place right after the TCP connection is done. What if I want to connect to the same peer in regards to a different torrent? Should I initiate another connection or should I send another handshake on the same connection? – alex.49.98 Jul 22 '15 at 16:30
  • No, the specification is quite clear on that. I think your thought process clouds your understanding, it starts with assumptions based on what you want to do instead of trying to look at what the protocol actually does. – the8472 Jul 22 '15 at 18:27
  • I still didn't completely understand. Handshake message has info_hash and the handshake is supposed to be send the first. Thus the connection is bound to a particular info_hash. Now, I want to download another torrent and I know that this particular peer has it. To do it I have to establish another connection to this peer with the new info_hash? But in this case it will be second connection to the peer which accordingly to your answer might be dropped or it is not considered duplicated because of the handshake with different info_hash? – alex.49.98 Jul 23 '15 at 13:53
  • That's implementation-specific behavior, not really a part of the protocol specification itself (it provides a lot of leeway regarding such details). Some clients might enforce uniqueness on a per-torrent basis, some globally and some not at all. And normally it doesn't really matter that much since a swarm consists of many peers and you can connect to any one of them. – the8472 Jul 23 '15 at 19:15
  • @the8472 A quick question. When a client can close the connection? Do I have to reestablish "handshake", if I close the connection after each "message" read? – Ritwik Aug 23 '19 at 16:11