LLAPI QoS questions

I have a project where I am using one channel for communication back and forth from a server to a client. The QoS for the channel used was "ReliableSequenced" which I understand the description per the docs is "Each message is guaranteed to be delivered and in order."

This was fine. My messages were of a limited size where I didn't need to do any type of fragmentation. So I assumed that I was getting one packet per message and those packets were always being received on the other end and in order that they were sent. (My understanding maybe wrong here but this isn't the question).

The project has developed to where some messages are now larger than the QoS of ReliableSequenced can handle (without me doing some sort of programmatic intervention). I found I can use the QoS of "ReliableFragmented". I know I could potentially use "ReliableFragmentedSequenced" but in the current released version it isn't available.

The question is the QoS not being sequenced does that affect the fragmented packets? Am I not guaranteed to have my large message I send from the host to the client to be assembled correctly on the client? At this point in my development I don't care if message X is received prior or after message Y. I am worried that when I fragment that I have a chance that the re-assembly of the fragments is not going to be correct. Can anyone confirm my worry or set me straight?

As a side question would having a channel for fragmented messages and one for smaller messages be something worthwhile? I am pretty sure that now even my smaller messages are being fragmented due to just having one channel.

Thanks

 

ReliableFragmentedSequenced is for Unity 2017+ AFAIK. So Unity 2017 and Unity 2018 has it. Unity 5 does not. At least not 5.6.

Anyways. The packets will be reasembled correctly. It's just that if you send two fragmented messages they might not come in the same order, but their fragments will be properly reconstructed.

And FYI. This is wrong: "So I assumed that I was getting one packet per message and those packets were always being received on the other end and in order that they were sent. (My understanding maybe wrong here but this isn't the question)."

UNET Transport tries to combine the messages before sending. Thus there is a delay as specified in the transport configuration where packets can stack up and then be combined for sending.

 

Appreciate the response thanks!!