If your data is going through XBees, you should put the modules into API mode with escape characters, divide your data into logical packets, and take advantage of the fact that in API mode a packet which is given to an XBee will either arrive intact or not at all. Design your protocol around the transmission of chunks of 1-255 bytes, and let the XBee modules worry about how to deliver the data within each chunk. Don't worry about maintaining the integrity of individual packets or the subdivisions between them. The Digi modules will do a good job of taking care of that. The biggest thing you do need to worry about is the fact that even if the node that transmits a packet believes it wasn't delivered and sends a replacement, the recipient may end up getting it anyhow--possibly even after it gets the replacement. Things may be easiest if you design your protocol so that one side is the "master"; if the master asks for a piece of data, the slave should send it once and not worry about whether the master gets it. If the master doesn't get the data that it wants, it can request it again.
The slave should assign some sort of sequence numbers to data, and the master should assign sequence numbers to requests that the slave change state. If the master's request is of the form "send the first item whose sequence number is greater than XXX", and each piece of data item by the slave includes its own sequence number and that of the previous item (if they're not numbered consecutively), late-arriving packets may cause the slave to redundantly send data to the master, but the master will have no difficulty ignoring the consequent late-arriving responses. If the slave receives a state-change request whose sequence number is below that of an earlier request, it should ignore the that request, since it was superceded even before it was received.