Transferència de fitxers

THIS PAGE IS DEPRECATED: READ File transfer

Com ho utilitzar?

Android

Quan parles amb algú a Android, tens la possibilitat d’enviar una foto al teu dispositiu o fer una foto amb aquests botons:

Nota

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

! Android_waiting_peer

Com funciona?

Com funciona

Introducció

Jami és una aplicació distribuïda i ha de funcionar sense cap connectivitat a Internet. Així, la transferència de fitxers també! Básicament, utilitzem el mateix mètode per realitzar transferències de fitxers i trucades, però en TCP. Per resumir com funciona, podem imaginar una situació en què Alice (A) vol transferir un fitxer a 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.

Ara que el enllaç TCP bidireccional és aquí, el següent pas serà negociar un TLS 1.3 (generalment un (TLS1.3)-(DHE-FFDHE8192)-(RSA-PSS-RSAE-SHA384)-(AES-256-GCM) quan escric aquestes línies) entre Alice i Bob, llavors Alice començarà a transferir el fitxer.

La primera part serà un petit cap de cap per descriure el contingut del fitxer.

Processos

Enviant un fitxer

Es fa servir el següent mètode:

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

Recepció d’un fitxer

La mateixa estructura s’utilitza per rebre fitxers, però el mètode es modifica un poc:

1. La classe JamiAccount s’utilitza per rebre missatges del DHT, perquè el primer que es recepirà serà la petició DHT.

2. Després, aquest missatge es dóna a DhtPeerConnector: onRequestMessage() a través de l’eventLoop.

3. El DhtPeerConnector::Impl::answerToRequest intentarà connectar-se al servidor TURN (si no està connectat) i iniciar el transport ICE. Aquest mètode obre 2 connexions de control a un servidor TURN (un per autoritzar pares IPv4, un altre per pares IPv6, a causa de RFC 6156) si ja no està obert i permet connectar adreces públiques de pares. Llavors, si el SDP rebut no conté candidats ICE, utilitzarà el TURN i elaborarà la resposta SDP per esperar el peer. Si el SDP conté candidats ICE, el mètode intentarà negociar el enllaç (o retroceder en el TURN) i després respondre al SDP (amb candidats ICE o no).

4. Un cop els enllaços estan preparats, com el remetent, es negocia un enllaç TLS i es dóna a la PeerConnection donada a la IncomingFileTransfer com a entrada.

Re-pedir una transferència de fitxer anterior

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.

Per fer-ho, el dispositiu enviarà un json amb el tipus de mime: application/data-transfer-request+json que conté conversation (id de la conversa), interaction (interacció relacionada), deviceId el dispositiu que rebeu el fitxer.

El remetent ara comprova si el dispositiu és un dispositiu del peer anunciat i que el dispositiu és membre de la conversa, i pot enviar el fitxer a través d’un transferiment de fitxer clàssic.

El receptor ara pot acceptar la primera transferència entrant, descarregar el fitxer i verificar que la sha3sum és correcta.

Esquèma

! Diagrama: principal diagrama esquema

SDP enviat per DHT

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).

Patches relacionats amb PJSIP.

3 patches s’incloureixen al projecte PJSIP:

1. RFC 6062, utilitzat per realitzar TURN sobre TCP (fusionada a nivell ascendent: pjproject - fa6616c43c7e19797084f4e02a67d1fb6fd99473)

2. RFC 6544, utilitzat per executar ICE sobre TCP

3. Una correcció per pj_activesock

Teniu en compte que l’estac per a la transferència de fitxers és:

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

Dispositius múltiples

A user can link its account to several devices. So, we need to implement the transfer when a user send a file to a contact who have multiple devices linked to this account.

Primer enfocament

El primer enfocament era enviar una petició a través del DHT a tots els dispositius i els primers dispositius que responen obtinguen el fitxer per transferir. Això és dolent per al seu contacte perquè no sabrà quin dispositiu rebut obtingui la transferència.

Aspecte actual

Ara, encara enviem una petició a tots els dispositius. La diferència és que tots els dispositius tindran la notificació per rebre un fitxer i poden acceptar/refusar la transferència. La major part del codi per a això és en data_transfer.cpp.

Now (since https://review.jami.net/c/jami-daemon/+/9327), when a user send a file, it will request a PeerConnection with all peer devices. And for all connections, we attach a new input stream to have the ability to accept/refuse/cancel each transfer separately.

En data_transfer.cpp definim la classe OptimisticMetaOutgoingInfo que representen la vista optimista per mostrar al client. És optimista perquè si un contacte accepta una transferència en un dispositiu i rebuix en altres, aquesta classe mostrarà la transferència de fitxer en curs. I només mostrarà un error si tots els dispositius rebuixen la transferència.

Aquesta classe està vinculada a SubOutgoingFileTransfer que representen l’estat d’una transferència amb un dispositiu. Els clients tindran la possibilitat de mostrar una subtransferència en lloc de l’optimista més tard (vegeu TODO llista).

Utilitzant un altre servidor TURN

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 usuari:password -r "realm"

Then, you can configure the TURN server in the advanced settings of the app.

Nota

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).

Llista TODO

1. Use libtorrent?

2. Mostre l’estat de subtransfers per a arxius sortents