I'm trying to get my head around the wording of a protocol which infers apps were once able to receive TCP packet data out of sequence. That's applications receiving data out of sequence not the IP packets showing up at the host out of sequence.
This is curious. I'm unaware of any implementation of TCP that could ever allow this to happen. I think that would always have violated a core principle of TCP.
Can anyone explain this passage in the MQTT 3.1.1 standard:
When a Client reconnects with CleanSession set to 0, both the Client and Server MUST re-send any unacknowledged PUBLISH Packets (where QoS > 0) and PUBREL Packets using their original Packet Identifiers [MQTT-4.4.0-1]. This is the only circumstance where a Client or Server is REQUIRED to redeliver messages.
Non normative comment Historically retransmission of Control Packets was required to overcome data loss on some older TCP networks. This might remain a concern where MQTT 3.1.1 implementations are to be deployed in such environments.
MQTT is connection orientated so resending at any other time would explicitly mean sending the same "control packet" down the same TCP connection twice. If the data didn't arrive the first time, surely the receiving host would block the application from receiving any further data. Resending it would be futile.
Indeed, this is in complete contrast to the later MQTT 5.0 standard:
When a Client reconnects with Clean Start set to 0 and a session is present, both the Client and Server MUST resend any unacknowledged PUBLISH packets (where QoS > 0) and PUBREL packets using their original Packet Identifiers. This is the only circumstance where a Client or Server is REQUIRED to resend messages. Clients and Servers MUST NOT resend messages at any other time [MQTT-4.4.0-1].
Were the authors originally mistaken? Was re-transmitting data (by the application) through the same TCP connection ever required to handle data loss? Or was this passage in the standard simply misleading and not what the authors intended?
Note that this is not just my inference of this wording. I have seen mainstream implementations of this protocol periodically re-transmitting the same packets down the same TCP connection.
As mentioned in the comments, this is about packet loss, not out of order delivery.
A very early (may be even the first) deployment of MQTT was on a network that used a form of satellite back haul where the satellite modem would respond with ack packets before the actual packet was transmitted to the satellite so it was possible for the client to believe that the packet had been received by the broker when it had in fact been lost (either on the way up to satellite or the way back down) on route.