I am studying bit torrent protocol. I have confusion regarding torrent protocol. Suppose I have a router with static IP and two clients are connected to that router that are C1 and C2. One of that client say C1 is acting as a seed. Now how will the client downloading the file will know that C1 is seeding taking consideration the fact the only thing know to the outer-network is static IP of the router.
Is there is any way through which torrent can identify the client C1 ??? Please explain that.
a) they can find each other via local service discovery, it's widely deployed but currently lacking a specification
b) they can talk to each other through their respective public socket addresses as discovered through other peer discovery mechanisms if the router supports hairpin NAT routing
Update: Now there's a spec for LSD.
Related
I know that BitTorrent DHT can be used to coordinate torrents without the need for a tracker. Now, I would like to build a P2P network of nodes and I would prefer to avoid the hassle of developing my own discovery / signaling / handshaking / NAT traversal.
So I was wondering: is there any library (preferably nodejs) that I can use to just:
Generate an identifier on a node A.
On a node B, use A's identifier to connect to A.
Both nodes get some callback with a socket, ready to write on?
I mean, this should be somehow part of the handshaking protocol for BitTorrent, but instead of directly using the torrent protocol to send data, I would like to directly get to talk with the other node and implement my own protocol.
Is it possible?
The bittorrent DHT and the bittorrent data transfer protocol are separate things. So yes, it is possible to find other IP/Port contacts through the DHT and connect to them with a custom protocol.
I have two scenarios for implementing IoT devices and I want to know which one has most security? Because I am a programmer and I have bit knowledge on network issues
Main Goal is to implement IoT devices and have modification and configuration from outside of local network. Assume we have IoT device in smart house and I want to change its configuration from outside of house by changing some parameters.
NOW:
First Scenario:
On the below picture indicates with red color on the left.
Writing our own web services and make it accessible by setting up "static ip" and and using "Port Forwarding" + SSH in order to have high secure connection.
In this story, user write static ip on address bar from outside of smart house and connect to web services and can have modification
now my question is if this way can harmful for our firewall and network?
If this way open firewall port permanantly?
If all users can send request so do we have attackers that can attack other devices or not?
We can have our authentication to have more safty.
Second Scenario:
On the below picture indicates with blue color on the right.
In this scenario we are using APIs from IoT company instead of writing our own services and user send request to IoT Company and on the our smart house we have gateway from IoT company which send request for instance per 1 second to check if ther is any on IoT company server or not and if there is any so make a modification.
Because in this scenario Iot Company might to use DHCP IP instead of static ip , is it possible to have some hurt to fire wall?
Because I am not sure but I think firewall will be opened whenever ther is any request so is it possible that this way is more secure?
If possible, I would suggest not opening any port on the IoT device. This does create a lot of worries as the question suggests.
Instead, would it make sense in your case to have the IoT device poll a web service for instructions? You could use web sockets or long-polling if it's important for the devices to be highly responsive to incoming requests.
Mahsa's description is not detailed enough, so i decided to add some more information... otherwise it would be a "what tastes better: a pear or an apple?" discussion.
More precise scenarios
The first scenario (S1) uses port forwarding. This port can be used by everybody in the internet. Security is based on the software and implementation of that webservice. Which has to be maintained good and updated regulary.
The Second scenario (S2) does a polling from a internet-server, maintained by the manufacturer (Philips). The local IoT-gateway initiates a TCP/HTTP-rest-request to the philips-hue server in the internet. The firewall/NAT does not need to be changed at all. "Open Port whenever we need" is not 100% correct, it's a NAT-firewall which accepts only packets from request destination of Philips-server (SPI)
Please read about how networks, firewall and NAT works in most environments before making assumptions:
Network: OSI Layers 3,4,7 (and at the moment we talk about IPv4 ;-)
Firewall/SPI: Stateful Package Inspection
NAT: Port-restricted cone or symmetric
Questions of safety
What is "safety" in your case? You have to define what you want to protect. In this case it's the local network,so that no intrusion is possible. The detailed questions "what is more safe?" are:
A1) port-forwarding or A2) port-restricted/symmetric NAT and SPI?
B1) pattern user ⇒ firewall ⇒ own webservice ⇒ gateway or B2) pattern user ⇒ Philips-server ⇐ firewall ⇐ gateway
C1) security is based on higher layer 5-7 or C2) based on lower layers 3+4
Side aspects
The picture should tell that the "own web service" can NOT directly talk to the IoT-device. It has to talk over the gateway/bridge with the IoT-device.
This means you have to setup a local webserver parallel to the IoT-gateway.
D) Costs, effort and the maintennance of such local webservice... is it really needed to have a secure scenario?
Please send your answers A-D
and some arguments would be nice. Perhaps you find also some other security issues E,F,G,H... let us know. Thanks Frank
I recall reading an article about a proposed way to do this. If I recall correctly, the researchers successfully created a connection to a client on another network without port forwarding by sending HTTP packets to each other (Alice pretends that Bob is an HTTP web server while Bob pretends Alice is a web server).
I'm not sure if that makes sense, but does anyone know where I can find the article or does anyone have any other ideas how to connect two clients together without a central server or port forwarding?
Is it even possible?
Edit: I would know the IPs of both computers and port the program listens on.
It is possible. I see at least 2 parts to your question. (It is not going to be HTTP packet. It is a lot more complex than that.)
First off, I believe you might be talking about a concept called decentralized P2P network. The main idea behind a decentralized peer-to-peer network is the fact that nodes conjoint in such a network will not require central server or group of servers.
As you might already know, most common centralized peer-to-peer networks require such centralized system to exchange and maintain interconnectivity among nodes. The basic concept is such, a new node will connect to one of the main servers to retrieve information about other nodes on the network to maintain its connectivity and availability. The central system gets maintained through servers constantly synchronizing network state, relevant information, and central coordination among each other.
Decentralized network, on the other hand, does not have any structure or predetermined core. This peer-to-peer model is also called unstructured P2P networks. Any new node will copy or inherit original links from the "parent" node and will form its own list over time. There are several categories of decentralization of such unstructured networks.
Interestingly enough, the absence of central command and control system makes it solution of choice for modern malware botnets. A great example could be Storm botnet, which employed so-called Passive P2P Monitor (PPM). PPM was able to locate the infected hosts and build peer list regardless whether or not infected hosts are behind a firewall or NAT. Wikipedia's article Storm botnet is an interesting read. There is also great collaborative study called Towards Complete Node Enumeration in a Peer-to-Peer Botnet, which provides excellent conceptual analysis and techniques employed by Storm botnet network.
Second of all, you might be talking about UDP hole punching. This is a technique or algorithm used to maintain connectivity between 2 hosts behind NATed router/gateway using 3rd comment host by means of a third rendezvous server.
There is a great paper by Bryan Ford, Pyda Srisuresh, and Dan Kegel called Peer-to-Peer Communication Across Network Address Translators.
As answered, a peer-to-peer connection requires establishment of a connection between two (presumably) residential computers, which will necessitate punching holes through both of their firewalls. For a concrete example of hole punching, see pwnat: "The only tool to punch holes through firewalls/NATs without a third party". The process, put simply, goes like this:
The "server" (who doesn't know the client's IP address, but the client knows the server's) pings a very specific ICMP Echo Request packet to 1.2.3.4 every 30 seconds. The NAT, during translation, takes note of this packet in case it gets a response.
The client sends an ICMP Time Exceeded packet to the server, which is a type of packet that usually contains the packet that failed to deliver. The client, knowing in advance the exact packet that the server has been sending to 1.2.3.4, embeds that whole packet in the Data field.
The NAT recognizes the Echo Request packet and happily relays the whole Time Exceeded packet, source IP and all, to the correct user, i.e. the server. Voila, now the server knows the client's IP and port number.
Now that the server knows the address, it begins to continually send UDP packets to the client, despite the fact that the client's NAT did not expect them and will therefore ignore them all.
The client begins sending UDP packets to the server, which will be recognized by the server's NAT as a response to the server's packets and route them appropriately.
Now that the client is sending UDP packets to the server, the server's stream of UDP packets starts getting properly routed by the client's NAT.
And, in 6 easy steps, you have established a UDP connection between a client and a server penetrating two residential firewalls. Take that, ISP!
I'm trying to understand how can a magnetic link work, as I've read they use DHT and PEX to get the peers, but if I'm a new node in the network how can I find peers with only the hash of the file?! Doesn't it always require a link to a known host?
Thanks
The bittorrent DHT can be bootstrapped in many ways. It just needs the IP and Port of any other reachable DHT node out there.
Current clients generally use several of the following strategies:
bootstrap from a cache of long-lived nodes from a previous session
use a DNS A/AAAA record mapping to a known node (e.g. router.bittorrent.com or dht.transmissionbt.com) with a known port
use a node embedded in a .torrent file
retrieve the DHT port from a bittorrent client over a bittorrent connection established through other means, e.g. a conventional tracker.
If a peer is embedded in a magnet link one can also piggyback a DHT bootstrap on that through the port message
multicast neighbor discovery via LSD
cross-chatter from the IPv4 to the IPv6 DHTs and vice versa (if needed)
Other ways such as user-configurable bootstrap lists, DNS SRV records round-robin mapping to live nodes or - should everything else fail - adding the IP of your friend(s) manually work.
Once a node has joined the network the first strategy mentioned above will kick in and it is unlikely that it will have to bootstrap again.
So while most implementations rely on a single/few points of entry into the network for convenience, the protocol itself is flexible enough to decentralize the points of entry too.
Just for emphasis: Any node in the DHT can be used to join the network. Dedicated bootstrap nodes are an implementation detail, not part of the protocol, and could be replaced by other discovery mechanisms if necessary.
In BitTorrent, client connects to the tracker specified in .torrent file. Tracker is a kind of centralized server and it is the starting point. So BitTorrent is not pure p2p.
If we want to develop pure p2p system, we should design routing overlay network. All nodes will have routing table like routers do. But even in routing overlay network, each node should know at least one existing node(GUID, IP address) initially. So how can we determine this? Should we keep 'one existing node to connect initially' forever like fixed centralized server? If so, I think this is not fully decentralized method.
The solution you describe (defining a central peer wit well-know ip address) is not the only one.
The other solution is to post an html page (or json file) in a well-know URL on the net, and make sure this item contains an updated list of peers this peer can initialy connect. This list can be updated if a peer goes down. Eventually, you can use multiple URLs.
Pure P2P system is a theoretical concept which cannot be implemented fully in reality.
You could use an anycast. So the first other client will answer and may send such an initial "client list". Where your client can connect to them to get more lists.
Classically I would implement a multicast to a adress and wait for an answer of other clients.
Firstly, a true peer to peer network is not necessarily decentralized. Secondly, decentralization does not necessarily mean that the network doesn't make use of secondary services which may themselves be centralized.
The main question in both of these issues is wheather the primary resources of the network solution are distributed through correlated peers.
For example, peer-to-peer video conferencing may use a central contacts service but still be pure peer-to-peer as long as the peers resolve such issues before entering a true peer-to-peer scope. This would also be decentralized.
What it comes down to is what your trying to solve by using peer-to-peer. A video conference is a video conference - it starts with a video being recorded on one peer and ends with the video being viewed on another. As long as each byte of this data is transferred directly between the peers (even if there's hundreds of peers in the conference, and regardless of how these peers found each other) it is a true peer-to-peer video conference.
Note that the video peers will still be in your typical ring, and that the contacts lists may still use the node key for location information rather than an IP. This will still be a network overlay as it will still be built over IP, replacing it's addressing scheme on the peer level to facilitate true peer-to-peer networking.
What it realy comes down to is the concepts of a network connection. IP just pushes packets to unspecified routers until it gets to a specific address. 'connections' between each endpoint only exist within the higher software levels (including when dealing with TCP/IP). A connection is just the data used within software to understand who is who and how each point can handle data etc. Peer-to-peer network overlays effectively distributes this data, eliminating the need for each peer to create massive amounts of connections to communicate on a massive scope. Decentralization is not required for this (as long as peer to peer communication is not centralized), and a secondary service within the system wont necessarily limit a network's scope or otherwise centralize actual peer-to-peer networking.
So to answer your question, it doesn't matter where it initially connects in order to be considered peer-to-peer, and different peer-to-peer services will handle this based on their service design.
Ok so I am thinking about writing a p2p protocol for a number of different services for an AI project, and I thought I'd come here to see if i could get some ideas on how to get the initial connection.
I have come across several ways to establish the initial connection:
1) You have a static ip address on the internet that distributes information on other peers. This isn't good, because:
a) it's a single point of failure, the service could go offline, preventing any new connections from creating an initial connection to peers,
b) the IP address could change. This could be mitigated by using a domain name which is maintained to point to the current ip address of the location of a service which provides data on peers, however this can be subverted in theory by hackers by spoofing or arp poisoning, dns attacks etc.
2) You could force the user to provide an initial ip address or hostname for another peer, and it's up to the user to find the hostname / ip address / port number. This is good, but if someone posts disinformation or they cannot find a peer on google or some other search site then obviously it's fallable.
3) You could leave it to the peer to publish their own existence in a central location - for example a group of IRC channels or a group of websites. Again, unless it's going through a central trusted domain, it's hard to determine the authenticity of the peer.
4) You could use some kind of nmap style discovery algorithm that searches through subnets for appropriate protocols. The problem with this approach is it's slow and it's likely to attract attention from things like firewalls etc.
5) This is a variation of 3) you could allow the peers to advertise their own information on a website, then instead of having to look for the information in a suitable location (a specific website, or group of websites), you can let google's search algorithm find it, and do the discovery for you, however you could imagine that this may take a few days for google to cache the website data with information on the peers. Also again, it would be upto you to provide some way to verify the authenticity of the advertised data.
6) If you are interested in an exclusive p2p network that locks out certain people (for example, you might want to have a file sharing network and you don't want law enforcement to be able to access it, or MPIAA), then you could use 2) and then have a referral system where you require that the initial connection provide the referrer's ip address, and then the service could connect to the referrers ip address and ask the referrer if they did indeed refer the referee.
That's all I can think of currently, but if anyone comes up with any other ways to do this, i would be very interested.