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?
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.
Related
I am working on the project that is asking me to use peer to peer network because this project will be applied in the environment that don't have a server. So I need help on which protocal and C/C++ API I can use to perform this.
In order to perform peer-to-peer you have to handle NATs which means you must perform a NAT Transversal (NAT Punch). This is typically done using UDP and STUN. From the second link:
Here’s a parting “TL;DR” recap: For robust NAT traversal, you need the
following ingredients:
A UDP-based protocol to augment
Direct access to a socket in your program
A communication side channel with your peers
A couple of STUN servers
Even then you are not guaranteed success. It is a very complicated subject so i recommend reading the entire NAT Transversal article.
When I use bep_0005 get_peers method to find an infohash like "1111111111111111111111111111111111111111", I can receive the response with "values' key, But when I use bep_0003 to send BitTorrent protocol handshake to each peer in "values", Peers always disconnect TCP connect, In fact, It seems Peers don't have ut_matadata.
Why node send me fake data?
There are several possible causes for this
Old utorrent versions returned values stored for the nearest target key if they did not have an exact match. this was fixed a while ago but many people are still running old clients
Various dubious implementations monitoring the DHT try to harvest data by responding to any and all get peers request with values and then recording connection attempts for whatever reasons
Malicious entities use bittorrent clients as dDoS amplifiers by inducing them to spam targets with TCP connnections
But there are various measures a node can implement to sanitize that data.
When creating a peer to peer audio connection using webRTC, the STUN server we use will return the public IP if a user is behind a router. Now in the ICE objects, I can see that the rport is always something between 50000 and up.
Is there a way to use a specific port so that the user does not have to open all those ports?
Is there a way to use a specific port so that the user does not have to open all those ports?
I think you have a misunderstanding. The whole point of STUN and ICE (including its WebRTC derivative) exists to avoid anyone having to open a port on their NAT. Instead, STUN and ICE dynamically open the port.
Here's how it works (in a really brief description).
Client opens a socket on a random port (e.g. 50001)
Contacts STUN server using that socket to discover the external IP:port mapping for this socket. (e.g. 192.168.1.2:50001 maps to 1.2.3.4:50001). Ports don't necessarily have to match between internal and external addresses, but they usually do, so I'll keep with that for this example.
Through an external mechanism (SIP, XMPP, Jingle, cups with strings), the candidate address list of both nodes are exchanged. This includes all known internal and external addresses collected (e.g. 192.168.1.2:50001 and 1.2.3.4:50001).
Using the same socket opened in step 1, both sides send (STUN) messages (UDP packets) directly between each other. The first pair of messages may be blocked by the router/firewall. But because one side initiated an outbound packet to the remote address, subsequent packets from that address are allowed back in. This is called the "hole punching step". Hence, the port is dynamically open without the router needing any specific configuration.
Hope this helps.
You can't programatically unless you are using webrtc API in your own application. The browser will pick specific local ports from a range locally; and then it will inform you about them in the SDP and ICE candidate information.
STUN server only helps discover whether a client is behind a NAT/firewall; and then ICE uses this information in establishing peer-to-peer connection.
I have heard somewhere there might be a way to control that port range via Chrome policy templates(used by enterprises to restrict Chrome settings) - http://www.chromium.org/administrators/policy-templates. It might worth looking into...
In our system, we used to test the connectivity between different nodes using ICMP messages. But out of security concern, this keep alive mechanism is required to be banned by our customers. So we have to replace the ICMP message with some other protocol messages. Currently, our solution is using TCP. Obviously, this solution has at least 2 disadvantages:
1. failures occurred on one TCP connection don't necessarily mean the same thing happened to the others, and don't mean lower-layer connectivity(eg, IP) failures as well.
2. establishing a TCP connection and sending/receiving TCP message are quite time-consuming, which is another challenge to our existing connectivity testing schedule.
I'm wondering if there is any other solutions other than TCP that can meet our requirement.
I am a newbie in network related aspects. I have few basic questions related to tcp/ip protocol and network
If a network switch (in a LAN network) between two PC's running Client and server (that are communicating through async. sockets) is powered down. Can the client and server will be notified that the socket connection is no longer active. Client and server are running on Win XP OS and are coded using C#.
Does network topology play a role in case of half open connection between socket client and socket server. For e.g. Will a disconnect status of either one or both be notified to other end and does it depend on network topology.
Thanks in advance.
A network element such as a router/hub/switch does not activly cause anything anything to happen on the TCP layer if it goes down. The operating system might notice that the physical layer is down and error out all sockets bound on that network card if it's a network element directly connected to the PCs that breaks - this will vary among operating systems/network cards and other things. Other than that, in order to detect that the connection has been severed, you'll have to send something and rely on the TCP timeout mechanisms to error out. This can be done implicittly by enabling TCP Keepalives on the connection.
A disconnect on one side will only be noticed if those messages reach the other side, if the network topology changes or sometinhg breaks in the middle of the connection in such a way that messages no longer reach the other end, a disconnect won't be noticed. (NAT gateways are a big source of problems such as this, they might time out a TCP connection they're tracking and you'll never know the connection is no longer valid unless you try to write something (or enable TCP keepalives) to the connection). Note that most networking APIs require that you Read from the connection to discovver that a the other end has closed the connection - assuming those "close" messages actually reach your side.