Typically, you would need to choose a protocol with strong guarantees on whether the client will receive any packets/messages, in which order, and whether duplication is permitted.
For a network of IoT devices sending small- to moderately-sized messages to each other, using MQTT with Quality of Service 2 would seem to fit your use case well. As stated in the HiveMQ link:
The highest QoS is 2, it guarantees that each message is received only once by the counterpart. It is the safest and also the slowest quality of service level. The guarantee is provided by two flows there and back between sender and receiver.
Note that QoS 2 does preserve order of messages, and, as stated, prevents duplicated messages.
There is a substantial overhead in using MQTT QoS 2 compared to the standard QoS 0 (which is akin to a fire-and-forget message; if it doesn't reach the broker, then the message doesn't get resent and it's gone forever) — QoS 2 requires 4 messages (PUBLISH from sender, PUBREC from broker, PUBREL from client, PUBCOMP from broker), so it'll generally take longer to process, take more resources (hence longer radio transmissions and more power usage on any constrained endpoints).
An MQTT QoS 2 message will just be resent from the sender repeatedly until it receives acknowledgement from the broker, so eventually your message should get through, even if your connection is imperfect.
Whether a topic-based publish-subscribe protocol is appropriate for your use case is up to you to determine; the Wikipedia article might help you to get an idea.
