How to set up and tear down an IBB session using and elements sent within IQ stanzas.
and in 2.3 Closing the Bytestream
it mentions that: To close the bytestream, either party sends an IQ-set containing a <close/> element.
During aTalk system testing for both legacy and jingle file transfer via In-Band ByteStreams protocol;
it was found that the <close/> element are sent by both the file sender and recipient. This leads to the file sender returns an <item-not-found/> stanza error by the CloseListener(); as the sessionId had already been removed in InBandBytestreamSession#closeByLocal() i.e. InBandBytestreamManager.getByteStreamManager(this.connection).getSessions().remove(byteStreamRequest.getSessionID());
When testing with Conversations xmpp client in JingleFileTransfer protocol, the <close/> element is only sent by the sender, but not the file recipient.
I believe that in smack IBB implementation, since the sender has already closed the IBB Bytestream, the file recipient should not again send the <close/>; also as per recommended by XEP-0047
To close the bytestream, either party sends an IQ-set containing a <close/> element.
What you wrote seems sensible (haven’t look at the specification nor the implementation, though). The next step would be to submit a change proposal that can be discussed.
That said, I believe that closing (and this something like this) will always be racy. You never know if the other party may already put a close on the wire that just has not yet arrived when you want to close the session.
The proposed fix has been implemented in aTalk. It is tested working for the legacy InBandByteStream file transferring.
However when tested with Jingle File Transfer, there appear a race condition occurred in both the Jingle Initiator and Responder. With the network delay, the sending and receiving of <close/> elements are too close to each other for either parties to act according. In both cases, neither of them trigger an error.
I do not have a good proposal for fixing this problem.