[Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing
Ruslan N. Marchenko
me at ruff.mobi
Wed Feb 28 18:53:11 UTC 2018
Am Dienstag, den 27.02.2018, 15:37 -0700 schrieb Peter Saint-Andre:
> On 2/27/18 10:33 AM, Ruslan N. Marchenko wrote:
> > That actually touches a point which is nagging me each time I'm
> > looking
> > into implementation. Who is responsible for closing the session?
> > According to this  it is recommended that receiving party closes
> > the
> > session as soon as it receives complete file.
> > But that doesn't leave the space for adding files into the session,
> > as
> > it relies on concurrency - eg whether receiving party receives (or
> > actually processes) complete transfer sooner than 'content-add'
> > stanza.
> >  https://xmpp.org/extensions/xep-0234.html#sect-idm1399045441849
> > 76
> Actually, that says "Once all file content in the session has been
> transfered, either party MAY acknowledge receipt of the received
Yes, it may, but recommendation is
"Preferably, sending the session-terminate is done by the last entity
to finish receiving a file to ensure that all offered or requested
files by either party have been completely received (up to the
> note that "all file content" might include multiple files if XEP-0358
> (Publishing Available Jingle Sessions) is used.
Which receiving party has no ability to know in advance.
> So unfortunately I think the answer is: "it depends".
Right, so that's the point of the question. I think it should be
clearly specified. Otherwise there might be session leaking.
Basically this session leaking (initiator does not close it) forced me
to follow recommendation and send session-terminate on transfer
In current definition ack is voluntary, which means in absence of ack
initiator has no idea when transfer is complete by the target and it is
safe to close the session.
So let say - either party MAY close the session but it is recommended
(or even required) that the initiator to be responsible for closing it
to ensure proper session cleanup - after receiving confirmation as
> If there is a single file involved, then the receiver can terminate
> session after it has received that single file.
> But, what if the sender has advertised only a single file (in the
> session-initiate message) yet has more to send? In that case, the
> flow would be:
> (1) the receiver acknowledges receipt by sending a <received/>
> as in §8.1
> (2) the initiator sends a Jingle content-add action as in §6.3
> (3) the receiver acks the content-add request
> (4) the initiator sends the next file
> After the receiver acknowledges receipt of the last file in the
> the initiator would terminate the session.
precisely. but that's almost a new protocol, would need a bump to
ensure implementation follows new guidelines/semantic.
> That is the "push" scenario. In the "pull" scenario (XEP-0358), it
> best for the receiver to terminate the session.
I didn't yet digest pull scenario so cannot comment, but the idea is
that the party which knows exactly what is to be sent (active or
passive initiator so to say) is to be responsible for closure.
Counterparty may implement idle-timeouts to avoid abandoned
sessions (crashed subsystem) leakage.
More information about the Standards