The Two Generals’ Problem

Pubblicato il 12 ago 2019
Time to tell a story about idempotency, computer science, and the Night of the Multiple Orders. • Sponsored by Dashlane -try 30 days for free at: www.dashlane.com/tomscott
MORE BASICS: it-tvs.com/plid-PL96C35uN7xGLLeET0dOWaKHkAlPsrkcha
Written by Sean M Elliott and Tom Scott
Directed by Tomek
Graphics by Mooviemakers www.mooviemakers.co.uk/
Audio mix by Haerther Productions haerther.net/
Thanks to Dashlane for sponsoring the video! If you're techie enough to watch this video, you should be using a password manager. Get a 30-day free trial at dashlane.com/tomscott
I'm at tomscott.com
on Twitter at twitter.com/tomscott
on Facebook at facebook.com/tomscott
and on Instagram as tomscottgo

Commenti

  • Yes, I had help with the graphics for this series. There's no way I'd have animated that myself! On that note, thanks to Dashlane for sponsoring and helping me hire an animator: their free trial link is www.dashlane.com/tomscott

    • I have thought about dashlane I want to know the advantage over Google chrome random password generator and manager that is synced with one master password. they don't know any of the passwords either.

    • As glad as I am that you're getting sponsored, I feel I should tell people that Firefox is starting to offer this password security option for free, though before anyone gets angry at me, I don't know what level of security it is, comparatively, I just want to make people aware of options!

    • Why not send a person from each army to the middle of the valley. Then both discuss a time and go back to their army. That way they will know if the message was received by the other army. As the Danger of the route lies in the middle of the valley they will get back safely.

    • Hey there is a way to solve the 2 genrals problem and it's a horne or war drums because they are loud enugh to hear

    • Now you know the issues protocol standards committees have to 'foresee' when designing a communication protocol.

  • It's 2 am and I regret nothing

  • Or maybe both general could send dozen more message until it hit certain threshold and that will confirm it.

  • 2:35 why not let them meet in the middle, so if they perish, they perish together and no message is received, but if they manage to meet, they can return and there are no threats on the way back to the generals.

  • Well, after both the teams have received confirmation of the other party that they know that you know and will go at 8PM, I don't see any further need of sending messengers. Can someone explain, please?

  • How come this problem exists at all, if the proposed time is 8 pm, and both of them acknowledged the acknowledgments, then why would A and B need to keep sending acknowledgments? They both acknowledged the proposal and acknowledgment, so it's already planned? They both already know that it made it to the other side at least twice, so what's the problem? This just feels like it's not really a problem.... How is this line of reasoning incorrect?

  • I should be asleep but general B didn’t give me a confirmation

  • Simply. General A sends a messenger which returns after delivery of the message. If the messenger does not return after a suitable time span. It is safe to assume something happend and another messenger needs to be sent

  • but wouldn't a and b know they've received the message by the third message?

  • £7.74 word.

  • 2:55 starts sweating.....

  • Just tell them to make a fire signal after they do, as confirmation. Not that hard.

  • for the two generals, couldnt one side send a messenger with the message telling them to attack at a certain time (sundown) but to ensure they both know they both have to shoot a cannon ball to the west of the other general at sunrise) if they both observe the cannon ball west of them then they know they will attack at sundown

  • I wonder how the generals problem is unsolvable. Please correct me whats the mistake of the solution below, Step1: General A sends message saying attack at 6pm (Here, A establishes the time) Step 2: General B gets the message, sends back an acknowledgement 1 for the message 'we go the time' (B gets the time) Step 3: General A gets the ACK 1 (now, A knows that B got the time of attack. But B won't attack because B don't know that ACK 1 is reached at A. so..) A sends a confirmation ACK 2 back Step 4: General B gets the ACK 2 (now, B knows that both A and B establishes the time. Also B got the ACK 2, meaning B knows that ACK 1 reached A. But B knows that A won't attack until A confirm that B got the ACK 2. so...) B sends a confirmation ACK 3 back Ahhhh this trend continues and no one will attack since they cannot make sure that the previous ACK sent by them is reached at the other end!!! I am sorry (T_T)

  • Have generals send messagers at set periods of time even when there is nothing to send. If there is no messager, ask about it in the next message.

    • @Ivan farlenkov You really do not get it. Oh well, nevermind. Stick to flipping burgers.

    • @Gareth H Why not? If messagee is lost, request to resend will be eventualy get to the other side.

    • That is the ping approximation that is used. But it is not a solution to the problem, there is no solution.

  • My bank card would’ve texted me to confirm charge after being pinged to debit my account identical amount of money. It’s kind of stupid that nobody selling the food didn’t notice.

  • 😂 these damn apps!

  • This is a classic lack of dev testing prior to sending it for testing prior to deploying it to the end user, and QA testing.

  • Even your paid promotions are interesting to listen to!

  • Why dont the say just to fire a cannon if they recieve the message

  • 2:57 umm...

  • 1:38 What are you talking about? Of course they made it to the other side. Just not the side they intended.

  • Surely after the 4 messengers they wouldn't need confirmation any further confirmation because both would have already known that it's agreed upon

  • You didn’t solve the two generals problem, you solved another problem created by it being unsolvable, which arguably is more dangerous than the two generals problem

  • per your ad... there is *always* the possibility of brute force getting through. It could take years, or decades on average, but there is always a chance someone gets lucky.

  • TCP/IP

  • You could just send the original guy back.

  • I'd say that if B received two verifications then do it

  • Proposition for the two generals problem: instead of sending one messenger, send a pair of messengers. One messenger stays at camp B and the other returns to camp A. If no messengers return to camp A, then it's obvious that the message was intercepted on one of the two trips, so you send another pair

  • What they should have done is just starve the castle out like they most commonly did

  • Honestly, the red army would automatically assume the blue army got the message and would attack on that time

  • Atleast once invocation solves this issue as well. I.e. let the client keep spamming the same request until one confirm has been recieved.

  • I'd definitely not like having a master password that, if lost, renders my entire online life unrecoverable. How can you possibly make your one password unforgettable? Chisel it into an immovable rock?

  • Send the entire army as the messenger

  • I was watching a video about Morgoth from Lord of the Rings, why am I here. Also your video is great and informative.

  • But the generals would know after a few acknowledgements? What am I missing here

  • Good grief, a Hewlett-Packard computer I can do component level repairs and maintenance on!

  • I may have double paid for Nandos last night

  • We solved this problem for banking application at work. The app is designed to work offline and synchronize when online. The acknowledgment problem is that you do not know if a message did not reach the server or it reached the server, but the confirmation was lost. As a result each message is uniquely identified in the client and safe to repeat. You can resend a message to the server a million times, but it will result in one transaction only for both client and the server.

  • This sort of thing happened to me 3 years ago through Amazon. The progress wheel after clicking "Buy Now" kept freezing when I hit it. I foolishly kept refreshing and hitting "Buy Now" again until getting to the confirmation screen. This was why, two weeks later, I had to ship back 15 identical USB phone chargers.