The In-Band Bytestreams (IBB) enables two entities to establish a virtual bytestream over which they can exchange Base64-encoded chunks of data over XMPP itself. It is the fall-back mechanism in case the Socks5 bytestream method of transferring data is not available.
There are two ways to send data over an In-Band Bytestream. It could either use IQ stanzas to send data packets or message stanzas. If IQ stanzas are used every data packet is acknowledged by the receiver. This is the recommended way to avoid possible rate-limiting penalties. Message stanzas are not acknowledged because most XMPP server implementation don't support stanza flow-control method like Advanced Message Processing. To set the stanza that should be used invoke {@link #setStanza(StanzaType)}.
To establish an In-Band Bytestream invoke the {@link #establishSession(String)} method. This willnegotiate an in-band bytestream with the given target JID and return a session.
If a session ID for the In-Band Bytestream was already negotiated (e.g. while negotiating a file transfer) invoke {@link #establishSession(String,String)}.
To handle incoming In-Band Bytestream requests add an {@link InBandBytestreamListener} to themanager. There are two ways to add this listener. If you want to be informed about incoming In-Band Bytestreams from a specific user add the listener by invoking {@link #addIncomingBytestreamListener(BytestreamListener,String)}. If the listener should respond to all In-Band Bytestream requests invoke {@link #addIncomingBytestreamListener(BytestreamListener)}.
Note that the registered {@link InBandBytestreamListener} will NOT be notified on incomingIn-Band bytestream requests sent in the context of XEP-0096 file transfer. (See {@link FileTransferManager})
If no {@link InBandBytestreamListener}s are registered, all incoming In-Band bytestream requests will be rejected by returning a <not-acceptable/> error to the initiator. @author Henning Staib
|
|
|
|
|
|