GPT4 的回答：
在您描述的场景中，如果接收端不能处理重复的消息或保证消息的幂等性，同时保证消息的可靠性（不丢失消息）和及时性（快速送达）确实是一个挑战。这主要是因为在大多数消息队列系统中，为了保证消息的可靠性，通常会采用至少一次（ at-least-once ）或者精确一次（ exactly-once ）的消息传递语义：

1. **至少一次（ At-least-once ）**：保证消息至少被传递一次，但可能会导致消息重复。在这种情况下，接收端需要能够处理重复消息或实现消息的幂等性。

2. **精确一次（ Exactly-once ）**：保证每个消息只被传递一次。这是最理想的，但也是最难实现的，因为它需要在发送端、消息队列系统和接收端之间进行复杂的协调。

3. **最多一次（ At-most-once ）**：消息可能会丢失，但不会重复传递。

在您的情况下，由于接收端不能处理重复的消息或实现幂等性，您可能需要采用以下策略：

- **使用可靠的消息传递机制**：选择一个支持至少一次或精确一次传递语义的消息队列系统，如 Kafka 的精确一次语义或 RabbitMQ 的消息确认机制。

- **减少消息重复的可能性**：虽然接收端不能处理重复消息，但可以通过减少网络问题、提高发送端和消息队列系统的可靠性来降低消息重复的风险。

- **使用超时和重试机制**：在发送端实现超时和重试逻辑，如果在预定时间内未收到确认，可以重发消息。这提高了消息送达的可靠性，但可能增加重复消息的风险。

- **外部协调**：如果可能，可以在系统外部实现一种机制来跟踪消息的状态，并在消息重复时协助接收端处理。

- **消息唯一标识**：在消息中包含唯一标识符，并在接收端实现一定程度的逻辑来检测重复的消息，即使不能完全处理它们，也能至少识别出它们。

需要注意的是，即便采用了上述策略，如果接收端完全无法处理重复消息，那么在网络不稳定或系统出现故障时，仍然可能面临挑战。在这种情况下，可能需要重新考虑系统的设计，或者在接收端实现一些基本的幂等性处理逻辑。

@sujin190 不是在公网或弱网下啊。就是本地内网，但是可靠性要求实在是太高了。

@kuanat "接收端只接收，不响应"？ 是有回令的。但是回令其实是个单独的信号，还有可能是总线的。指令执行的结果到是不用太管，正确错误都无所谓。
所以我要保证的是，这条指令发了，然后收到了。

@Chinsung 意思是重复问题交给协议栈解决，业务只要发一次就可以了么

@julyclyde 被控端类型太多，而且由不同供应商组成。没办法做统一约束

@laminux29 同意你的看法。

@affmans ack 没收到，不代表接收端没收到，然后不能处理重复消息。。

仔细看我说的，iptv 是 dhcp 拿到的地址，这个不是问题，北京联通这点非常开放，本来内网内是可以直接访问的。所以模仿的真不是机顶盒的拨号，而是获取加入组播组的 rtp 流。rtp 地址网上有很多，但是都不能播放~