2 ms·
> protection from duplicate packets was never a requirement.. Nope. This is what "at-most-one" means. Either zero or one. Not two. Three is right out. > you
by trelane 1y ago
> protection from duplicate packets was never a requirement..
Nope. This is what "at-most-one" means. Either zero or one. Not two.
Three is right out.
> you also assume there is no other identifying info inside the packets that might provide an inherent protection anyways
Yes, but then if we're positing a system on top of UDP, then it doesn't matter what the protocol is, TCP or UDP. We can also assume the underlying system we're relying on can also detect missing requests, or even ensure we have exactly one.
- ranger_danger 1y ago> Nope. This is what "at-most-one" means. Either zero or one. Not two. But "is at-most-one ok?" doesn't necessarily mean that more is also unacceptable. All the valid and invalid conditions are not completely specified IMO.
- dragonwriter 1y ago> But "is at-most-one ok?" doesn't necessarily mean that more is also unacceptable. If you propose delivering an at-most-once solution, the customer agrees that that is an acceptable parameter, and then you deliver a solution that has no at-most-once guarantee, you haven't delivered what you proposed, and you certainly have no reason to believe you've met the customer's needs.
- ranger_danger 1y agoThe way OP framed it IMO sounded like a very informal conversation, not a written contract with formal specifications... I think it's possible the person agreeing at-most-one was "ok" quite possibly didn't care either way, and might even view supporting duplicates as a positive extra feature... but I don't think this is something either of us can speak to authoritatively. > if we're positing a system on top of UDP, then it doesn't matter what the protocol is And this is still true, and neither of us know if they would have designed it this way or not, but they could.