Smack's IBB sends too much data in a packet

I tried to send a file from Smack to SleekXMPP.

SleekXMPP currently supports only IBB (In-band Bytestream), the negotiation works fine.

But when Smack sends its first data packet, SleekXMPP shows the following message:

Bad file transfer packet received! Terminating session with SENDER_JID

seq 0: expected seq: 0

packet size: 5400 Max Block size: 4096

I checked **org/jivesoftware/smackx/bytestreams/ibb/InBandBytestreamSession.java **class

It turns out to be Smack that use a wrong buffer size.

XEP-0047 said “The base64-encoded data to be sent, prior to any wrapping in the element and IQ or message stanza, MUST NOT be larger’ than the ‘block-size’ determined in the bytestream negotiation.”

I think that **block-size **should be the length of ‘base64-encoded data’, which is longer than the actual data itself.

So, if we let the **block-size=4096, **the buffer size should be (4096 / 4)*3 = 3072 bytes.

(3 bytes of data will be encoded as 4 characters in base64 encoding)

I’d like to submit a patch to org/jivesoftware/smackx/bytestreams/ibb/InBandBytestreamSession.java ** (Smack 3.2.1)**

with following buffer size calculation:

/* Old */

public IBBOutputStream() {

this.buffer = new byte[byteStreamRequest.getBlockSize()];

}

/* New */

public IBBOutputStream() {

int maximumBytesPerPacket = (byteStreamRequest.getBlockSize() / 4) *3;

this.buffer = new byte[maximumBytesPerPacket];

}
wrong_maximum_packet_size.patch.zip (480 Bytes)

Recorded as SMACK-349

great find. Thanks

I disagree.

XEP-0047 says: “The data to be sent, prior to base64-encoding and prior to any wrapping in XML, MUST NOT be larger than the ‘block-size’ determined in the bytestream negotiation.”

Maybe they changed that, when it became a final standard in 2012 ??

That is exactly what happened. From XEP-0047, Appendix H: Version History:

Version 2.0 (2012-06-22)

Per a vote of the XMPP Council, advanced to Final; in addition, specified that the ‘block-size’ attribute defines the size of the data chunk before instead of after base64-encoding, to accord with existing implementations.

Logged as SMACK-524