BitTorrent Local Service Discovery Receive

After you have edited the source code, post your patch here.
Forum rules
Home | Wiki | Rules

BitTorrent Local Service Discovery Receive

Postby ivan386 » 13 Mar 2017 16:21

Code: Select all
Index: Datagrams.cpp
===================================================================
--- Datagrams.cpp   (revision 9668)
+++ Datagrams.cpp   (working copy)
@@ -28,6 +28,8 @@
 #include "Datagrams.h"
 #include "Datagram.h"
 #include "DatagramPart.h"
+#include "Download.h"
+#include "Downloads.h"
 #include "BTPacket.h"
 #include "BTTrackerRequest.h"
 #include "G1Packet.h"
@@ -36,6 +38,7 @@
 #include "DCPacket.h"
 #include "BENode.h"
 #include "Security.h"
+#include "Transfers.h"
 
 #ifdef _DEBUG
 #undef THIS_FILE
@@ -850,6 +853,89 @@
       }
    }
 
+   // Detect BitTorrent Local Service Discovery
+   if ( nLength > 22 &&
+       memcmp( pBuffer, "BT-SEARCH * HTTP/1.1\r\n", 22 ) == 0 )
+   {
+      // BitTorrent Local Service Discovery
+      // http://bittorrent.org/beps/bep_0014.html
+
+      CString   sPacket( (char*) pBuffer, nLength );
+      
+      /*
+         As with any HTTP request to ensure forwards-compatibility any additional
+         headers that not understood by a client should be ignored.
+      */
+      
+      /*
+         BT-SEARCH * HTTP/1.1\r\n
+         Host: <host>\r\n
+         Port: <port>\r\n
+         Infohash: <infohash>\r\n
+         cookie: <cookie (optional)>\r\n
+         \r\n
+         \r\n
+      */
+
+      /*
+         host:
+            RFC 2616 section 14.23 and RFC 2732 compliant Host header specifying the
+            multicast group to which the announce is sent. In other words, strings
+            A) 239.192.152.143:6771 (org-local) or B) [ff15::efc0:988f]:6771 (site-local),
+            as appropriate.
+      */
+
+      /*
+         cookie:
+            opaque value, allowing the sending client to filter out its own announces
+            if it receives them via multicast loopback
+      */
+      
+      /*
+         port:
+            port on which the bittorrent client is listening in base-10, ascii
+      */
+
+      if ( LPCTSTR pszPortStart = _tcsnistr( sPacket, _T("\r\nport:"), 7 )  )
+      {
+         short nPort = 0;
+         if ( _stscanf( pszPortStart + 7, _T("%hd"), &nPort ) == 1 && nPort > 0 )
+         {
+            /*
+               infohash:
+
+                  hex-encoded (40 character) infohash
+
+                  An announce may contain multiple, consecutive Infohash headers to announce
+                  the participation in more than one torrent. This may not be supported by
+                  older implementations. When sending multiple infohashes the packet length
+                  should not exceed 1400 bytes to avoid MTU/fragmentation problems.
+            */
+
+            for ( LPCTSTR pszHashStart = _tcsnistr( sPacket, _T("\r\ninfohash:"), 11 );
+                       pszHashStart != NULL ;
+                       pszHashStart = _tcsnistr( pszHashStart, _T("\r\ninfohash:"), 11 ) )
+            {
+               pszHashStart += 11;
+               for(; *pszHashStart == _T(' ') ||
+                    *pszHashStart == _T('\t')   ;)
+                  pszHashStart++;
+
+               Hashes::BtHash oHash;
+               if ( oHash.fromString< Hashes::base16Encoding >( pszHashStart ) )
+               {
+                  CSingleLock oLock( &Transfers.m_pSection, FALSE );
+                  if ( oLock.Lock( 250 ) )
+                     if ( CDownload* pDownload = Downloads.FindByBTH( oHash ) )
+                        if ( ! pDownload->m_pTorrent.m_bPrivate ) // Do not share private torrents
+                           pDownload->AddSourceBT( Hashes::BtGuid(), &pHost->sin_addr,  nPort );
+               }
+            }
+            return TRUE;
+         }
+      }
+   }
+
    // Detect BitTorrent UDP tracker packets
    if ( nLength > 7 )
    {
Attachments
Datagrams (local peer discovery receive) .zip
(9.54 KiB) Downloaded 9 times
Last edited by ivan386 on 13 Mar 2017 21:41, edited 2 times in total.
data:application/exe,%B4%09%BA%0D%01%CD%21%B4%08%CD%21%CD%20Hello,World!$
ivan386
 
Posts: 257
Joined: 17 Jun 2009 14:08

Re: BitTorrent Local Service Discovery Receive

Postby raspopov » 13 Mar 2017 17:05

1) You can use CString::Tokenize() for message parsing if you want a whole string duplication, or you can use _tcsnistr() to find substrings in place;
2) OnDatagram() already has filtered host address inside TryRead().
User avatar
raspopov
Project Admin
 
Posts: 941
Joined: 13 Jun 2009 12:30
Location: Russian Federation

Re: BitTorrent Local Service Discovery Receive

Postby ivan386 » 13 Mar 2017 21:42

Updated
data:application/exe,%B4%09%BA%0D%01%CD%21%B4%08%CD%21%CD%20Hello,World!$
ivan386
 
Posts: 257
Joined: 17 Jun 2009 14:08

Re: BitTorrent Local Service Discovery Receive

Postby raspopov » 15 Mar 2017 21:17

IMHO Shareaza filter out any local traffic and LSD is based on local traffic.
User avatar
raspopov
Project Admin
 
Posts: 941
Joined: 13 Jun 2009 12:30
Location: Russian Federation

Re: BitTorrent Local Service Discovery Receive

Postby ivan386 » 16 Mar 2017 08:25

Пользователь может выключить "Ignore private/local IP addresses"

GT: The user can turn off "Ignore private/local IP addresses"
data:application/exe,%B4%09%BA%0D%01%CD%21%B4%08%CD%21%CD%20Hello,World!$
ivan386
 
Posts: 257
Joined: 17 Jun 2009 14:08

Re: BitTorrent Local Service Discovery Receive

Postby raspopov » 16 Mar 2017 16:25

При чём тут пользователь? LSD подразумевает локальные адреса, поэтому шареаза должна обрабатывать такие пакеты отличным от интернета образом. Вообще кажется, что параноя шареаза относительно локальных адресов избыточна...
User avatar
raspopov
Project Admin
 
Posts: 941
Joined: 13 Jun 2009 12:30
Location: Russian Federation

Re: BitTorrent Local Service Discovery Receive

Postby ivan386 » 16 Mar 2017 20:15

Раньше наверно не было столько народу заперто в локальных сетях поэтому её просто вырубили в Shareaza. А теперь надо учитывать что множество пользователей находятся за NAT в локальной сети провайдера где трафик обычно не ограничивают.

Нужно разделять от кого приходит информация и кому мы её отправляем. Если мы получаем источники в локальной сети с локальной сети то всё норм. Если мы получаем источники в локальной сети с хоста в нитернете то скорей всего это не рабочие адреса.

Соответственно и Shareaza должна отправлять локальные и глобальные источники только тем кто соединён с ней по локальной сети. Локальную сеть тоже нужно разделить на два уровня 192.168.0.0/16 это обычно домашняя сеть и остальные локальные адреса это сеть провайдера.

В домашней сети можно шарить источники: в домашней сети, в сети провайдера, в интернете.
В сети провайдера можно шарить источники: в сети провайдера, в интернете.
В интернете можно шарить источники: в интернете.

Так же нельзя отдавать другим источники не проверенные нами. То есть у нас с ними не было двустороннего прямого общения.

Но это всё не относится к Local Service Discovery так как в ней мы можем расшарить только свой адрес и получить только адрес источника пакета.
------------------------------------------------------------------------------------------------------------------------------------------------------------------
GT:
Previously, probably there were so many people locked in local networks so it was simply cut down in Shareaza. And now you have to take into account that a lot of users are behind NAT in the local network of the provider where traffic is usually not limited.

It is necessary to separate from whom information comes and to whom we send it. If we get sources in the local network from the local network, then all the rules. If we get sources in the local network from the host in the network, then most likely these are not work addresses.

Accordingly, Shareaza should send local and global sources only to those who are connected to it on the local network. The local network also needs to be divided into two levels 192.168.0.0/16 this is usually a home network and other local addresses are the provider network.

In the home network, sources can be fumbled: in the home network, in the provider's network, on the Internet.
In the network of the provider you can fumble sources: in the provider's network, on the Internet.
On the Internet you can search sources: on the Internet.

It is also impossible to give to others sources not checked by us. That is, we did not have a bilateral direct communication with them.

But this all does not apply to Local Service Discovery because in it we can only share our address and get only the source address of the package.
data:application/exe,%B4%09%BA%0D%01%CD%21%B4%08%CD%21%CD%20Hello,World!$
ivan386
 
Posts: 257
Joined: 17 Jun 2009 14:08

Re: BitTorrent Local Service Discovery Receive

Postby raspopov » 19 Mar 2017 10:54

Added in r9671 with some re-factoring.

Also I enabled datagrams from local addresses, but we need more investigation safe it or not since packets content still filtered out for unreachable sources in many places.

ivan386, Когда я говорил про _tcsnistr() я имел в виду что-то типа этого.

Я проверил BitTorrent 7.9.9, теперь, получив LSD-пакет по локалке, шареаза добавляет источник к текущему торренту, и рано или поздно пробует его в режиме пуша, что приводит к успшной закачки по локальной сети.
User avatar
raspopov
Project Admin
 
Posts: 941
Joined: 13 Jun 2009 12:30
Location: Russian Federation


Return to Code Submission

Who is online

Users browsing this forum: No registered users and 1 guest

cron