0

Using broadcast and UDP with ack (we have to use it because it is supporting existing system).

When A sends a msg to B, A's timer will start running, before the timeout it will send B the same msg again. B being the coordinator of many systems, may be late in replying A. Furthermore the reply may be lost in the process. A can send B any msg at any time.

How do we reduce the danger (I guess solve is impossible) of A resend B msg again before B's ack reaches A, such that A may register the msg as failed (after resending twice) then B's ack reach A?

halfer
  • 19,824
  • 17
  • 99
  • 186
yeeen
  • 4,911
  • 11
  • 52
  • 73

2 Answers2

0

Is this actually broadcast, ie one-to-many transmission? It doesn't sound like it's pure broadcast, because you mention retransmission decisions per receiver. So I'll answer assuming you can send packets to each receiver independently.

You can build a good reliability mechanism by borrowing concepts from TCP. TCP has the most general and well-worn solution - it handles out-of-order reassembly, and can scale to high bandwidths with high latency (using ACK windows), and has some adaptivity to channel conditions.

Depending on what you're doing, that may be overkill. You could, instead, borrow from USB, which also has reliability and disambiguation mechanisms in packet delivery and acknowledgments. But it can only handle one packet outstanding at a time (e.g. window size == 1), and can't handle out-of-order delivery, which become major performance limiters if you have a high-bandwidth or high latency requirement.

In either case, your overall timeout (for signaling a delivery failure to the application layer) should be long that you don't ever expect to hit it during normal operation. TCP implementations, for example, will wait 15+ seconds to give up on delivery and signal a problem to the application layer.

Designing anything beyond basic one-packet-at-a-time delivery requires serious protocol design and QA to get right. The corner cases are hard to hit. If your requirements are non-trivial, you need to hire some solid network protocol engineers, or figure out a way to use an existing solution like TCP!

See also related discussions at What do you use when you need reliable UDP? .

Community
  • 1
  • 1
Nils
  • 5,612
  • 4
  • 34
  • 37
0

Application B needs to written such that a high priority, preferable real time scheduled, thread is sitting waiting for packets from application A. When B receives a packet, copy the payload into a memory locked circular buffer and immediately return to polling the socket. Then have the business level logic in application B read from the circular buffer for actual processing.

Steve-o
  • 12,678
  • 2
  • 41
  • 60