Adatátviteli átvitel

THIS PAGE IS DEPRECATED: READ File transfer

Hogy használjuk?

Android

Amikor Android-on beszélsz valakivel, lehetősége van egy képet küldeni a készüléken, vagy fényképet venni ezekvel a gombokkal:

Megjegyzés

When you send a file, the other has to accept it. At this moment you will see «awaiting peer»:

A „Szükséges” programot a „Szükséges” programra kell felvennünk.

Hogyan működik (műszaki)

Hogy működik?

Bevezetés

Jami egy elosztott alkalmazás, és internetkapcsolat nélkül kell működnie. Tehát a fájlátvitel is! Alapvetően ugyanazt a módszert használjuk a fájlátvitel és a hívások végrehajtására, de TCP-ben. Hogy összefoglaljuk, hogyan működik, elképzelhetjük egy olyan helyzetet, amikor Alice (A) egy fájlt szeretne átadni Bob (B).

First, Alice will request a connection to Bob. To do that, Jami is using ICE (RFC 6544), a protocol used to negotiate links between peers. Alice will send, into an encrypted packet via the DHT the IP address of its device. So, when Bob receives the IP addresses of Alice, they will be able to negotiate a transport where Bob will be able to send packets to Alice. The negotiation can be successful, but if it fails, a TURN server will be used (the one configured into the settings) to perform the transfer. If the negotiation succeeds, Bob will send its IP addresses to Alice to perform the negotiation in the other direction. Note that the link is still not secure, so Bob will send the IP addresses through the DHT network in an encrypted message. If the second negotiation fails, the TURN will be used as a fallback.

Most, hogy a kétirányú TCP link itt van, a következő lépés az lesz, hogy tárgyalni egy TLS 1.3 (általában egy (TLS1.3)-(DHE-FFDHE8192)-(RSA-PSS-RSAE-SHA384)-(AES-256-GCM) amikor írom ezeket a vonalakat) között Alice és Bob, akkor Alice kezd el átadni a fájlt.

Az első rész egy kis fejlevet tartalmaz, amely leírja a fájl tartalmát, majd miután Bob elfogadja a átadást, az egész fájlt továbbítják.

A folyamat

Adatokat küldek

A következő eljárás alkalmazható:

1. A client will call DataTransferFacade::sendFile(). DataTransferFacade is the class corresponding to the API exposed for the clients. It is used to manage a view of the file transfers (the corresponding classes are DataTransfer, IncomingFileTransfer, OutgoingFileTransfer and SubOutgoingFileTransfer). This method will ask the linked JamiAccount to request a connection.

2. The method DhtPeerConnector: requestConnection() is triggered and creates a connection between all connected devices of the peer (found on the DHT). DhtPeerConnector is used to manage the main event loop which manage connections. When a device is found, the event loop will create a ClientConnector (which manage the connection for one device) and launch the process() method.

3. This method is used to initialize the ICE transport and put a PeerConnectionMsg (which contains the SDP message, see below) on the DHT and waits for a response (DhtPeerConnector::Impl::onResponseMsg).

4. Then a response is received from the DHT, which contains public addresses of the peer device. We can now negotiate a TLS link (directly via ICE, or via TURN as a fallback). This TlsSocketEndpoint is given to the PeerConnection object as an output and the transfer can start.

5. When the TLS socket is ready, the callback DataTransferFacade::Impl::onConnectionRequestReply is called, and a OutgoingFileTransfer is linked to the PeerConnection as an input. This OutgoingFileTransfer contains a list of SubOutgoingFileTransfer (one per device) where each sub transfer is a transfer to one device. We do that to be able to furnish the most optimistic view of the transfer (if a contact as 3 devices, where the contact cancel the transfer on one device, but accepted the transfer on the two others, the most advanced transfer will be shown).

6. The SubOutgoingFileTransfer will first transfer the header of the file, wait the peer acceptance (A „GO\n” message on the socket) and then will send the file.

7. If a cancel is received from the peer or the client or if the file transfer finish, the connection will be closed via a CANCEL message on the DhtPeerConnector::eventLoop() and the resources will be released.

! TLSsocketEndpoint

Adatérfogadás

Ugyanaz a szerkezetet használjuk a fájlok fogadására, de az eljárás kissé megváltozik:

1. A JamiAccount osztályot a DHT üzenetének fogadására használják, mivel az első dolog, amit kapnak, a DHT kérés lesz.

2. Ezt követően a DhtPeerConnector: onRequestMessage() üzenetet adják az eventLoop segítségével.

3. A DhtPeerConnector::Impl::answerToRequest megpróbálja csatlakozni a TURN szerverhez (ha nem kapcsolódik) és kezdeményezni az ICE szállítást. Ez a módszer 2 vezérlő kapcsolatot nyit egy TURN szerverhez (egy IPv4 párokat engedélyezni, egy másik IPv6 párokat, ** RFC 6156** miatt) ha még nem nyitva van és lehetővé teszi a társasszemélyt nyilvános címek csatlakoztatását.

4. Ha a linkek készen állnak, mint a küldő, egy TLS link kerül tárgyalásra, és a PeerConnection-nek adódik, a IncomingFileTransfer-nek adódik beadványként.

Újra kérje a korábbi fájlátviteli

As specified in Other mime types, the data-transfer interactions are now synced and stored into conversations. So, a device can easily detects if a file was downloaded or not. If not, it can asks all members in the conversation to transmits the file again.

Ennek érdekében a készülék egy mime-típusú jsonot küld: application/data-transfer-request+json tartalmazó conversation (a beszélgetés id), interaction (következő interakció), deviceId a fájlt fogadó készülék.

A küldő most ellenőrzi, hogy a készülék a bejelentett társától származó eszköz-e, és hogy a készülék a beszélgetés tagja-e, és klasszikus fájlátviteli úton küldheti a fájlt.

A kapó most elfogadhatja az első beérkező átadást, letöltheti a fájlt és ellenőrizheti, hogy a sha3sum helyes.

Számítás


A SDP-t a DHT-en küldték

0d04b932
7c33834e7cf944bf0e367b47
H6e6ca682 1 TCP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 50693 typ host tcptype passive
H6e6ca682 1 TCP 2130706431 2607:fad8:4:6:9eb6:d0ff:dead:c0de 9 typ host tcptype active
H42c1b577 1 TCP 2130706431 fe80::9eb6:d0ff:fee7:1412 50693 typ host tcptype passive
H42c1b577 1 TCP 2130706431 fe80::9eb6:d0ff:fee7:1412 9 typ host tcptype active
Hc0a8007e 1 TCP 2130706431 192.168.0.123 42751 typ host tcptype passive
Hc0a8007e 1 TCP 2130706431 192.168.0.123 9 typ host tcptype active
Sc0a8007e 1 TCP 1694498815 X.X.X.X 42751 typ srflx tcptype passive
Z.Z.Z.Z:YYYY
A.A.A.A:YYYY

Where 0d04b932 is the ufrag and 7c33834e7cf944bf0e367b47 the password of the ICE session. 2130706431 and 1694498815 are the priority of the candidates. 192.168.0.126 42751 typ host tcptype passive is a passive host candidate and 1694498815 X.X.X.X 42751 typ srflx tcptype passive a passive host reflecting the public IP address (mapped via UPnP for example).

PJSIP-hez kapcsolódó patchok.

A PJSIP-projektbe három oldalt be kell foglalni:

1. RFC 6062, a TCP-en keresztül végzett TURN-t (felvonult előre: pjproject - fa6616c43c7e19797084f4e02a67d1fb6fd99473)

2. RFC 6544, a TCP-en keresztül történő ICE végrehajtására használt

3. A pj_activesock javítása

Megjegyzés: A fájlátviteli rakomány:

+-----------+----------------+-----------------------+
+    STUN   +    TLS data    +          TLS data     +
+-----------+----------------+-----------------------+
+     RFC  4571 (RTP)        +  RFC  6062 (TURN TCP) +
+----------------------------+-----------------------+
+                           TCP                      +
+----------------------------------------------------+

Több készülék

Egy felhasználó több eszközhöz is kapcsolhatja fiókját. Tehát meg kell valósítanunk az átvitelt, amikor egy felhasználó fájlt küld egy olyan kapcsolattartónak, akinek több eszköze is kapcsolódik ehhez a fiókhoz.

Első megközelítés

Az első megközelítés az volt, hogy a DHT-en keresztül küldjünk kérelmet minden eszközre, és az első eszközök, amelyek válaszolnak, átadják a fájlt. Ez rossz a kapcsolatotokra, mert nem tudják, melyik eszköz fog megkapni a átadást.

A jelenlegi megközelítés

A különbség az, hogy minden eszköz rendelkezik a fájl befogadására vonatkozó értesítéssel, és elfogadhatja/megtagadhatja a továbbítást.

Mostantól (a https://review.jami.net/c/jami-daemon/+/9327 óta) amikor egy felhasználó fájlt küld, PeerConnection-t kér az összes társeszközzel. És minden kapcsolathoz csatolunk egy új bemeneti adatfolyamot, hogy minden egyes átvitelt külön-külön elfogadhassunk/elutasíthassunk/törölhessünk.

A data_transfer.cpp kategóriában a OptimisticMetaOutgoingInfo osztályot határozzuk meg, amely a kliensnek bemutatandó optimista nézetet képviseli. Ez optimista, mert ha egy kapcsolat elfogadja a transferet egy eszközön és visszautasítja a többieket, ez a osztály megmutatja a folyamatos fájlátvitel. És csak akkor mutat hiba, ha minden eszköz visszautasítja a transferet.

Ez az osztály a SubOutgoingFileTransfer-hoz kapcsolódik, amely az egy eszközzel történő átvitel állapotát jelzi. Az ügyfelek később az optimista helyett subtranszfert mutathatnak be (lásd a TEENDŐ-listát).

Egy másik TURN szerver használatával

Actually the default TURN server is turn.jami.net. But you can host your own TURN server. For example by running a coTURN server.

`sudo turnserver -a -v -n -u felhasználó: jelszó -r „örökség”

Ezután az alkalmazás speciális beállításaiban konfigurálhatja a TURN-kiszolgálót.

Megjegyzés

This needs some technical knowledge. Moreover, the TURN server should see the same IP address of your node as the destination node, or the peer connection will fail (because the authorization will be incorrect).

TEENDŐ listát

1. libtorrent-protokoll használata?

2. A kiadó fájlok alárendelései állapotát mutassa