"ataylor" wrote : | could do, but i don't think the Packet should care about how messages are broken up. | I think it's the packet's responsibility to know how to encode itself, whether it encodes itself into one messagingbuffer (normal packet) or many (large message) is behaviour of the packet. anonymous wrote : | yes, at the minute they do. this still needs changing. Doing it this way tho' means that every message is still split up into 2 messages since the body is always written before the packet headers etc. I was thinking about changing it so the body is encoded at the time of sending the message. | For large messages it's important we don't re-encode since that's a lot of copying. If the logic for encoding is inside the packet, then it can make the decision at send time whether to just use the message's current buffers as is (for large messages) or re-encode them into another buffer (e.g. small messages). Again, this is up to the packet how it wants to encode itself. anonymous wrote : | we need somewhere to hold the fragment info, ie packet id, correlation id etc. | packet id is already written to the buffer, all we need to write is a boolean flag saying "lastPacket", if true then the server knows it's received all fragments. I don't think we need another class to do that, it's just an extra writeBoolean/readBoolean when encoding/decoding. anonymous wrote : | we need to reassemble them as we need to know which packet they belong to, and need to wait for all the fragments to arrive before decoding. remember there may be fragments from many packets interleaved in a buffer. | I don't think that is true. The decoded message can just maintain a list of messagingbuffers and a pointer (int) to a position in the first buffer where the data starts. Different messges can point to the same buffers if there are many messages in the same buffer. I don't think there is any need for re-assembling there. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167873#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...