jdev - 2020-06-07

so anybody can help regarding my last question for jingle

a session can have multiple contents

how do i know when a content is finished transfering

and the next begins

do i need to negotiate transports for every content again?

since the transports are a child element of content, i'd say yes

also the available (or suited) transports may depend on the content

for example, for real-time audio you may want to use a unreliable transport, which you certainly do not want to use for file transfer ✏

but you should not put both in one session

so thats not really a supported usecase

both what?

filetransfer and realtime audio

dunno

it certainly is unusual

lets think about something simpler

i want to transfer 5 files to you

but can't a jingle session be modified at any point? ✏

i send a session with 5 content elements

and then the first problem already begins

A Jingle negotiation MAY result in the establishment of multiple file transfers by including multiple <content/> elements.

my contact cant send me a candidate used, because he doesnt even know which content i want to transfer first

so it looks like you can add 5 <descriptions> here

that does also not work, because you have no way to signal the contact what file you are transfering of the 5

he receives bytes, but does not know to which description they belong

hmm reading xep234 i'd expect that the hash of the file is used to identify it in the transport

he could try and match with size and hash afterwards, but i doubt that was intended

sounds already like a workaround, and hashes are not mandatory

i think..

my next idea would be to add only one content, then if its finished i send a content-add action and send the next

but then the contact can no approve all files before the transfer starts

so again not really good

weird that this is so underspecified for a file transfer protocol

yep

ahh wait

the quoted text above says multiple *content* elements

yeah i know

so you identify the file via the sid attribute

so, say i receive 5 contents

that means that for multiple files jingle ft, <transport/> is usually duplicated, not nice, but works for me

that means i start in parallel 5 negotiations for candidates

then transfer all files at the same time

right, then you have one session ID and multiple stream IDs

potentially, sounds correct

yeah would work, for some reason i thought its better to use one connection for all files

but ideally you would send the files sequencially and not in parallel

but actually thats not really better or worse, it does not really matter how many connections i use

yeah but i can still do that

and somehow re-use information obtained about which transport works both for subsequent files

only cause i have negotiated candidates does not mean i have to send?

but then the connection breaks down after some time i guess

ah i simply could stall the candidate-use info

hm no thats also not optimal

i could do sequentially with conent-add action

but this would trigger a needed content-accept on any new content

it would work though if the other client has some auto-accept functionality

we could add an optional feature to xep234 that allows multiple <file> elements in <description>

the problem with that is, that you dont know when one file begins and the other ends

not if size if provided for all files

there is no "end of file" signal in jingle

thats also not enough

why not?

you would need to specify the order also then

sure, simply the order the <file> elements appear in <description>

yes one could do that

yeah that seems an easy extension

of course the disadvantage would be, that the recipient can not select files to receive individually ✏

we would just need a signal between that tells the other part which content should be negotiated

so we dont have to do all in parallel

start-negotiation sid=12313

that sounds like a more fundamental change to jingle

yeah not really backwards compatible

ah wait i think i have it

you start an empty file transfer session without content

then issue content-add action 5 times instantly

each content needs a content-accept, before anything can happen

yes exactly

yep, or you start a file transfer with one content and 4x content-add ✏

I mean the first file transfer does not need to be empty

yes

hm but do we have a benefit here?

now the user can instantly accept all files or reject single files

but after he accepts, still all are transfered in parallel

hm and its undefined if a content-add is valid on a not yet accepted session

hm there is a flowchart https://xmpp.org/extensions/xep-0166.html#def-action-content-add

not sure what this tells me

ok all actions are allowed in pending session state

but for filetransfer i see no benefit in doing content-add compared to just session-initiate

i think i just do 5 sessions, and if the user does not want to download all in parallel

he should just not accept all at the same time