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.
Related
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.
so I'm making an iOS app, but this is more of a general networking question.
So what I have is one phone that acts as the server and then a bunch of phones connect to the phone as the client. Basically it's a game/music sharer.
It's kind of hard to really get into the semantics of it, but that isn't important.
What is important is that the server and client are repeatedly sending each other commands and positions rapidly over a TCP connection, and sometimes the client wants to send the server a music file (4MB usually) to play as the music.
The problem I initially encountered was that when sending the large file, it would hang the sending of commands from the client to the server.
My naive solution was to create another socket to connect to the server to send the file to the server, the server would check the IP of the new socket, and if it has the IP of an existing connection then it would just tie it to that connection, receive the file, and then disconnect the socket.
But the problem with this is that it takes a 1-2 second delay for the socket to connect, and I'm aware that there are man-in-the-middle attacks that can occur.
Is there a more elegant solution to this problem?
I would not call your solution naive, this is largely how FTP works, separating data and control paths is a good design pattern in my view.
I wouldn't worry about the man in the middle thing. If you wanted, you could add a command to the client that it responds to over the data connection with a secret the server supplies, this would let you associate the connections without using the ip addressing.
If the delay is a problem then why not establish both connections at the start, the overhead of a few tcp connections on an operating system is not usually significant.
You could also use the two connections for both commands and data, alternating between them. Since both the server and client know when a connection is busy they can choose to use the idle one. The advantage of this is that it will keep both connections busy to ensure they are both known to be working.
You probably should also use a different thread for each socket but I suspect you are doing this since it won't work too well without it.
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'm want to design a ruby / rails solution to send out to several listening sockets on a local lan at the exact same time. I want the receiving servers to receive the message at exact same time / or millisecond second level.
What is the best strategy that I can use that will effectively allow the receiving socket to receive it at the exact same time. Naturally my requirements are extremely time sensitive.
I'm basing some of my research / design on the two following articles:
http://onestepback.org/index.cgi/Tech/Ruby/MulticastingInRuby.red
http://www.tutorialspoint.com/ruby/ruby_socket_programming.htm
Now currently I'm working on a TCP solution and not UDP because of it's guaranteed delivery. Also, was going to stand up ready connected connections to all outbound ports. Then iterate over each connection and send the minimal packet of data.
Recently, I'm looking at multicasting now and possibly reverting back to a UDP approach with a return a passive response, but ensure the message was sent back either via UDP / TCP.
Note - The new guy syndrome here with sockets.
Is it better to just use UDP and send a broad packet spam to the entire subnet without guaranteed immediate delivery?
Is this really a time sensitive component? If it's truly down to the microsecond level then you may want to ensure its implemented close to native functions on the hardware. That being said a TCP ACK should be faster than a UDP send and software response.
I am using UDP network protocol to send message from various clients to a root server.
The message from client to server may not be sent directly and may be sent via other clients.
I want to know the clients via which the message is sent by looking at the message received at the root server. How to do this?
UDP does not include this information. You'll need to include something in your protocol if you want to keep track of servers through which the message has passed.
The traceroute program uses a trick to get bounced packets by setting the TTL to an increasing number. It starts with a TTL of 1 so that the first bounce comes from the closest server to the source. It then tries a TTL of 2 to get a bounce from the second server on the path, and so on.
traceroute is client-side and heuristic, i.e. works only for stable connections. Since you are essentially constructing an overlay network, the only ways to get information about the route is reconstructing the routing according to your routing algorithm (hard, and probably infeasible in a distributed network) or having each relay add a note (typically consisting of the relay's name, and the previous IP address) to the message.