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 [1] 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. > > > > [1] 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 > files"; 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 advertised sizes)." > 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 complete. 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 described below.
> If there is a single file involved, then the receiver can terminate > the > session after it has received that single file. > > But, what if the sender has advertised only a single file (in the > Jingle > session-initiate message) yet has more to send? In that case, the > ideal > flow would be: > > (1) the receiver acknowledges receipt by sending a <received/> > message > 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 > session, > 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 > seems > 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. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
