NetworkTransport.Send() completes without errors but data is not delivered

Hello,
I'm using the Transport Layer API of UNET to develop an online multiplayer mobile game (for 2 players) using a dedicated server architecture.
On client side, I have developed a mechanism to put important network messages that fails to be delivered (e.g. because connection is temporarily lost) into a queue, so that they can be resent when the client reconnects to the server. Such "important" messages are sent via a channel of QosType.ReliableSequenced.

To test the game, I simply run the server on my PC, and run the clients on two phones connected to the same WLAN as the PC. To test my "queue of undelivered messages" mechanism, I simply do the following steps on a client while the game is running:
1. Temporarily deactivate Wi-Fi.
2. AFTER FEW SECONDS, try to send a message while the device is offline (using NetworkTransport.Send() method).
3. I see (by logging debug strings to screen) that the NetworkTransport.Send() method failed: it returned true but the out error variable is equal to NetworkError.WrongChannel. In fact, the server hasn't received the message.
4. Reactivate Wi-Fi.
5. After few seconds I see (by logging debug strings to screen) that the message is resent, this time correctly: NetworkTransport.Send() returned true and the out error variable is 0. In fact, the server received the message.

So far, so good... The problem occurs if, at step 2, I don't wait few seconds before trying to send a message, but I do it immediately after disabling Wi-Fi (after less than a second). In this case, the flow is the following:
1. Temporarily deactivate Wi-Fi.
2. IMMEDIATELY after deactivating Wi-Fi (after less than a second) try to send a message (using NetworkTransport.Send()).
3. I see (by logging debug strings to screen) that the NetworkTransport.Send() method has completed successfully: it returned true and the out error variable is 0. But the server hasn't received the message!
4. Reactivate Wi-Fi.
5. The message is not resent, because it hasn't been put into the queue, since the call to NetworkTransport.Send() was considered successful, even if the message was not correctly delivered to the server.

Since I am using a channel of QosType.ReliableSequenced, I thought that it waited for a server acknowledgment before considering the NetworkTransport.Send() successful, but it seems not to be the case. Should I manually add acknowledgment messages to my protocol to ensure that a message has been actually delivered? Or is it a Unity bug?

If necessary, I can make a small project just to reproduce this issue. If something in this post is not clear, please ask me and I'll try to explain better. Thank you in advance for any answer.

 

Well I'm pretty sure it is correct that NetworkTransport.Send() is returning true when it successfully send off the message to the transport layer. After that the transport layer should take over.. where your application can continue running, and your app should not hang waiting RTT + resend if lost before it returns an possible send error.. So that is fine.. the Transport in theory will send the message or, keep trying, untill either the connection timed out (disconnection) or it finally gets a ACK from the other side.

However I'm surprised that when you send a message over the transport layer and you screw around with wifi that the message is not resend and eventually arriving at the other side.. sounds like some network transport bug? though It could be because your screwing with hardware here, your disabling wifi, which actually really unplugs the hardware for the application and possibly its borking things, which could be the reason you get randomly a wrong channel error there, maybe instead try to test lost connection issues in a more realistic way that does not involve disabling wifi adapters on your device.