> Remember that TCP is just a stream of bytes. There are no packets, at least > not from the application's point of view. If you send a chunk of data, there > is no guarantee it will arrive "all at once" on the other side. The only > guarantee is that the bytes will be in order. It is not the Jabber server > that is breaking up the stanzas into parts, but more likely the TCP subsystem > of either the Jabber server or your client's computer. Solid TCP > applications should be able to operate even at 1-byte granularity. Never > expect "packets" from TCP!
Sorry, it was not my intention to imply that I'm processing "packets". Jabber does, however, work over the TCP/IP protocol, which sends information out in discrete "packets", and like you said, the TCP subsystem takes care of this, so all we're concerned about at a higher level is reading from the socket stream. In this case, I was simply responding to a post regarding TCP packets and MTU size, and the point he was trying to make was that my code would not work in the event that I would need multiple socket.reads. I was pointing out that I had already taken this into account and that my code was not expecting a complete stanza in one socket.read call. > Since TCP is just a stream of bytes, and XMPP transmits a fully conforming XML > document as-is, then one way to look at XMPP is as if you were parsing a > really long XML file. > > You should now have enough information to decide if Jabber would ever send > jumbled XML fragments. > > -Justin Thanks Justin, I figured out as much since that was the only method that made any sense... I just never saw it implicitly written anywhere, but maybe that's because it's so obvious lol! Anthony _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
