On May 22, 2013, at 8:50 PM, Peter Waher <[email protected]> wrote:
> Hello Matt (again) and Council members. > > Seems I sent the last mail (below) too quickly, and started to think a > little, with regards to IBB. I have a set of questions/reflections: > > The IBB requires an open iq-stanza (with response and possible handshake) and > a closing iq-stanza (with response) for each transfer. For streamBase64 I see > no problem in converting to IBB for transport. I agree that IBB is better > suited for this, as it is already defined. > > But for normal chunked transfer, this seems very impractical. This may result > in hundreds of additional messages that needs to be sent for a simple > API-transaction, invoking a set of calls, etc. Or a normal web page > (containing links to much embedded content). > > Note that chunked transfer is often used when content size (Content-Length) > is not known, and the server decides to start transmitting anyway to maintain > buffers small. This is often the case as I mentioned for dynamic content, not > necessarily large, for instance in results to API calls. To add such a large > extent of messages for each response will decrease performance radically > without much gain. > > I therefore wanted to ask if it is possible to leave the chunkedBase64 > encoding as it is, and only convert streamBase64 to IBB? I believe the > overhead of messages merits a separate handling in this case. > > The chunk message contains a last attribute also that is a convenient way to > avoid the last close iq stanza in IBB. This saves a lot during small > transfers. Consider a relatively small HTTP GET with a response of 3 chunks. > Using IBB it would require at least 2+2+3+2=9 messages (http get+reponse+ibb > open+ibb open response+3 chunks+close+close response), while as it is now, > only 5 messages are required. > > The streamBase64 part is different however, as it is probable that very few > (probably at most one) stream is active from a client at a given time. Having > the additional open and close commands here gives no visible additional cost > in terms of messages. > > What is the opinion of the council: > > Is the use of IBB so important in this case that a performance degradation is > preferred in the chunked case? > > Or is it sufficient to use IBB only in the streamBase64 case, and leave the > chunkedBase64 case as is? > One of the things IBB worked through is data loss. The current definition just assumes the HTTP/XMPP "client" is there and ready to receive the <message/> stanzas containing the data chunk. While it should be, networks and software is not 100% reliable and that "client" could have lost their connection just after sending the <iq type='set'/>. The HTTP/XMPP "server" is not going to have any clue things aren't going where it expects unless it's receiving presence for the HTTP/XMPP "client". You could build this into HTTP/XMPP, but at some point you will get to the point where it duplicates much of IBB (which is awfully small to begin with) ... so why not use IBB in the first place? - m&m Matthew A. Miller < http://goo.gl/LK55L > [AMP] XEP-0079: Advanced Message Processing < http://xmpp.org/extensions/xep-0079.html >
smime.p7s
Description: S/MIME cryptographic signature
