jdev - 2020-06-07


  1. lovetox

    so anybody can help regarding my last question for jingle

  2. lovetox

    a session can have multiple contents

  3. lovetox

    how do i know when a content is finished transfering

  4. lovetox

    and the next begins

  5. lovetox

    do i need to negotiate transports for every content again?

  6. flow

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

  7. flow

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

  8. flow

    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

  9. flow

    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

  10. lovetox

    but you should not put both in one session

  11. lovetox

    so thats not really a supported usecase

  12. flow

    both what?

  13. lovetox

    filetransfer and realtime audio

  14. flow

    dunno

  15. flow

    it certainly is unusual

  16. lovetox

    lets think about something simpler

  17. lovetox

    i want to transfer 5 files to you

  18. flow

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

  19. flow

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

  20. lovetox

    i send a session with 5 content elements

  21. lovetox

    and then the first problem already begins

  22. flow

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

  23. lovetox

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

  24. flow

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

  25. lovetox

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

  26. lovetox

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

  27. flow

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

  28. lovetox

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

  29. lovetox

    sounds already like a workaround, and hashes are not mandatory

  30. lovetox

    i think..

  31. lovetox

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

  32. lovetox

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

  33. lovetox

    so again not really good

  34. lovetox

    weird that this is so underspecified for a file transfer protocol

  35. flow

    yep

  36. flow

    ahh wait

  37. flow

    the quoted text above says multiple *content* elements

  38. lovetox

    yeah i know

  39. flow

    so you identify the file via the sid attribute

  40. lovetox

    so, say i receive 5 contents

  41. flow

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

  42. lovetox

    that means i start in parallel 5 negotiations for candidates

  43. lovetox

    then transfer all files at the same time

  44. flow

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

  45. flow

    potentially, sounds correct

  46. lovetox

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

  47. flow

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

  48. lovetox

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

  49. lovetox

    yeah but i can still do that

  50. flow

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

  51. lovetox

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

  52. lovetox

    but then the connection breaks down after some time i guess

  53. lovetox

    ah i simply could stall the candidate-use info

  54. lovetox

    hm no thats also not optimal

  55. lovetox

    i could do sequentially with conent-add action

  56. lovetox

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

  57. lovetox

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

  58. flow

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

  59. lovetox

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

  60. flow

    not if size if provided for all files

  61. lovetox

    there is no "end of file" signal in jingle

  62. lovetox

    thats also not enough

  63. flow

    why not?

  64. lovetox

    you would need to specify the order also then

  65. flow

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

  66. lovetox

    yes one could do that

  67. lovetox

    yeah that seems an easy extension

  68. flow

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

  69. flow

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

  70. lovetox

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

  71. lovetox

    so we dont have to do all in parallel

  72. lovetox

    start-negotiation sid=12313

  73. flow

    that sounds like a more fundamental change to jingle

  74. lovetox

    yeah not really backwards compatible

  75. lovetox

    ah wait i think i have it

  76. lovetox

    you start an empty file transfer session without content

  77. lovetox

    then issue content-add action 5 times instantly

  78. lovetox

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

  79. flow

    yep, or you start an empty file transfer with one content and 4x content-add

  80. flow

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

  81. lovetox

    yes exactly

  82. flow

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

  83. flow

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

  84. lovetox

    yes

  85. lovetox

    hm but do we have a benefit here?

  86. lovetox

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

  87. lovetox

    but after he accepts, still all are transfered in parallel

  88. lovetox

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

  89. lovetox

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

  90. lovetox

    not sure what this tells me

  91. lovetox

    ok all actions are allowed in pending session state

  92. lovetox

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

  93. lovetox

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

  94. lovetox

    he should just not accept all at the same time