Transdono de dosieroj

THIS PAGE IS DEPRECATED: READ File transfer

Kiel uzi ĝin?

Android

Kiam vi parolas kun iu en Android, vi havas la eblecon sendi foton sur via aparato aŭ foti per ĉi tiuj butonoj:

! Android_file_butons

Note

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

! Android_waiting_peer

Kiel ĝi funkcias?

Kiel ĝi funkcias

Enkonduko

Jami estas distribuita aplikaĵo kaj devas funkcii sen interreta konekto. Do, ankaŭ transdono de dosieroj! Esence, ni uzas la saman metodon por fari dosiertransferon kaj vokojn, sed en TCP. Por resumi kiel ĝi funkcias, ni povas imagi situacion kie Alice (A) volas transdoni dosieron al 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.

Nun, ĉar la du-direkta TCP-ligo estas ĉi tie, la venonta paŝo estos negoci TLS 1.3 (ĝenerale (TLS1.3)-DHE-FFDHE8192)-RSA-PSS-RSAE-SHA384)-AES-256-GCM) kiam mi skribas ĉi tiujn liniojn) inter Alice kaj Bob, tiam Alice komencos transdoni la dosieron.

La unua parto estos malgranda ĉefpaĝo por priskribi la enhavon de la dosiero. Poste, post kiam Bob akceptas la translokigon, la plena dosiero estos sendita.

Procezo

Sendante dosieron

La sekva metodo estas uzata:

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

Alvenanta dosiero

La sama strukturo estas uzata por ricevi dosierojn, sed la metodo iomete ŝanĝiĝas:

1. La JamiAccount klaso estas uzata por ricevi mesaĝojn de la DHT, ĉar la unua afero ricevita estos la DHT-peto.

2. Poste, tiu mesaĝo estas donita al DhtPeerConnector: onRequestMessage() tra la eventLoop.

3. La DhtPeerConnector::Impl::answerToRequest provos konektiĝi al la servilo TURN (se ne konektita) kaj iniciati la ICE-transporton. Tiu metodo malfermos 2 kontrolkonektojn al servilo TURN (unu por rajtigi IPv4-kampanjojn, alia por IPv6-kampanjojn, pro RFC 6156) se ĝi ne estas jam malfermita kaj permesas al la publikadresojn de la kampanjo konektiĝi. Tiam, se la SDP ricevita ne enhavas ICE-kandidatojn, uzos la TURN kaj kreos la SDP-respondon por atendi la kampanjon. Se la SDP enhavas ICE-kandidatojn, la metodo provos intertraktadi la ligon (aŭ retropaĝi sur la TURN) kaj tiam respondi al la SDP (kun ICE-kandidatoj aŭ ne).

4. Post kiam la ligiloj estas pretaj, kiel la sendanto, TLS-ligilo estas negociita kaj donita al la PeerConnection donita al la IncomingFileTransfer kiel enigaĵo. La intrigoj de la dosiero venos kaj la kliento nun povas akcepti aŭ nuligi la translokigon.

Re-peti por antaŭa dosiero transdono

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.

Por fari tion, la aparato sendos json kun la mime-tipo: application/data-transfer-request+json enhavanta conversation (la id de la konversacio), interaction (rilata interagado), deviceId la aparato ricevanta la dosieron.

La sendanto nun kontrolas ĉu la aparato estas aparato de la anoncita kunulo kaj ke la aparato estas membro de la konversacio, kaj povas sendi la dosieron per klasika dosiera transdono.

La ricevanto nun povas akcepti la unuan alvenantan translokon, elŝuti la dosieron kaj kontroli, ke la sha3sum estas ĝusta.

Schema

! [Diagramo: ĉefa skemo diagramo](imagoj/dosiero-transdono-ĉefa skemo-diagramo.png)

SDP sendis tra la 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).

PJSIP-rilataj patĉoj.

3 parencoj estos inkluditaj en la projekto PJSIP:

1. RFC 6062, uzita por fari TURN super TCP (fuĝita suprenriveran: pjproject - fa6616c43c7e19797084f4e02a67d1fb6fd99473)

2. RFC 6544, uzita por fari ICE super TCP

3. Fix por pj_activesock

Atentu, ke la stack por la dosiero transdono estas:

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

Multaj aparatoj

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.

Unua aliro

La unua aliro estis sendi peton tra la DHT al ĉiuj aparatoj kaj la unuaj aparatoj kiuj respondas ricevas la dosieron por transdoni. Tio estas malbona por via kontakto ĉar ili ne scios kiu aparato ricevos ricevos la transdonon.

Aktuala aliro

Nun, ni ankoraŭ sendas peton al ĉiuj aparatoj. La diferenco estas, ke ĉiuj aparatoj havos la sciigon por ricevi dosieron kaj povas akcepti / rifuzi la translokigon. La plej granda parto de la kodo por tio estas 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 ni difinas la OptimisticMetaOutgoingInfo klason kiuj reprezentas la optimisman vidon por montri al la kliento. Ĝi estas optimisma ĉar se kontakto akceptas translokigon sur unu aparato kaj rifuzas sur aliaj, tiu klaso montros la daŭrantaj dosiertranslokigo. Kaj ĝi montros nur eraron se ĉiuj aparatoj rifuzas la translokigon.

Tiu klaso estas ligita al SubOutgoingFileTransfer kiuj reprezentas la staton de transdono per unu aparato. Klientoj havos la kapablon montri subtransdonon anstataŭe la optimisman poste (vidu TODO-liston).

Uzante alian servilo 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 uzanto: pasvorto -r "registaro"

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

Note

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

Ĉiu listo

1. Use libtorrent?

2. Montru la staton de subtransferoj por elirantaj dosieroj