Відео

Oh no it isn't!

Hi Martin, thank you for the lecture. One question regarding quorum and linearizability. In your example of non-linearizable quorum, the write was asynchronously replicated, which can technically violate the quorum safety condition, as the write wasn't acknowledgement by a quorum of nodes. What if the quorum is used with synchronous replication, such that the write is not committed before receving such acknowledgement from the quorum. In that case, a read quorum will always find the most recent write. Any thougts?

Bizantine as the name come from bizantin (Greek and east europe).

this aged well

Wow, I didn't know Martin has a YT channel. Instance subscribe.

Great theme tune for distributed systems

Great theme tune for distributed systems

Big thanks

Excellent lectures but ads are really annoying

Thank you

You're not only a great author but also an amazing teacher. Thanks Martin.

u are the GOAT of DS!

Where Can I find first half of the course ?

Woow what a gem I found! Living in this day and age is amazing and gorgeous, thank you so much for uploading!

Thank you very much.

6:25 ua-cam.com/video/_2By2ane2I4/v-deo.html

Glock. Genuinely meant block

Did you glock😢

I am sl confused rn

Something

Haha lol i made a funny

Honestly this is a really bad analogy to describe this problem.

I don't understand why at 09:41 you mentioned idempotencenl only for best-effort algo? All other algorithms have reliable network system model which can only be achieved with retry pattern. And if retry isnin place, then idempotence also should be, no?

Thank you so much for the perfect explanation

so interesting! thank you so much for posting this series : )

Sir, where is part one?

brilliant! thanks a lot for the content Martin!

Awesome video!

I don't understand why I am paying 2000 for a uni course as an international student when I get to learn all this sh🎉 here with much better quality

Great series for distributed systems.

how do we handle obtaining commit timestamp in a raft database without physical clock? just two phase commit?

why on slide 9 the leader need qurom to deliver while on slide 7 the follower can just commit?

is it possible if a leader commits a change say [1,2] given qurom, then goes down, a follower who has yet to commit the change or even voted yes to the commit becomes the new leader, having the log as [2,1], it now advocate to commit [2,1] while [1,2] has already been committed by some nodes?

what if a node advocating itself as a candidate only has log older than half, or even a handful of nodes, since node only gets to vote once each term, a relatively old node could be elected as the leader as long as it has votes from some older nodes and other candidate unfortunately have fewer votes (prob due to that they initiated themselves as candidate later)

Vielen Dank! Thanks Martin! Very clear explanation on Lamport and Vector logical clocks, inspired my lectures for CS from your explanation.

bro you rocked it

so, there is no solution for this problem? we can only put checks in place to prevent it in a real life scenario ?

Thank you so much for the series. They really are great and simple to follow. You are the best :))

Thanks for putting these lectures on youtube--education should be accessible to all

thank you, very informative and explantory

If we assume that clocks for user A and B have been synchronized via NTP, how can there be any skew/time difference b/w them?

11:40 you tube

What happens if one of the nodes has sent ok for prepare but while waiting for all the oks it crashes ? The transaction will go forward in all the other nodes.

super well made, thank you!

If you look at the Bank balance and assets of all those three general and how they earned it then you can learn a lot about those general before you appointed them.

hast du discord?

bestes video was ich gefunden habe. alles andere hat mega genervt.

Thank you, Professor Kleppmann, for this wonderful series and for making it publicly available. This is gold for understanding distributed systems concepts! I have one question, though, regarding this lecture. I don't understand how vector clocks solve the original problem presented at the start of this lecture, i.e., resolving the correct order for the messages m1 and m2 received at User C. Since, by definition, logical clocks at a particular process are monotonic in nature, the vector clock for the event representing "m2 received at C" should be greater than the vector clock for the event representing "m1 received at C"; as we take the maximum of each vector-element to merge both the recipient and local vectors, as explained at 15:30. Therefore, I am not exactly sure how computing the vector clock for these two events at C helps to resolve the correct order. One way I can think of resolving the order would be to compare the vector clocks sent as part of the message instead (before merging the recipient and local vectors). But this requires storing the vector clocks for all the events (for message received events, we would need to store the recipient vector clock instead) and then comparing the recipient vector clock (whenever a message arrives) with that of all the earlier events for a particular process or user, and then rearranging the events and possibly reassigning the vector clocks for the rearranged events. I'm not exactly sure about this approach as it may cause some other effects that needs to be handled; I couldn't really find much regarding this elsewhere.

Hope you can make a video to explain three phase commit and how it improves fault tolerance.

7:00: what happens if node B sends a message at the same time as Node A? Seems to me Node B will attach the timestamp 1 to the message because it was at 0 and did not yet receive message A. So now we have a message with a lower timestamp than the highest one so far. The only way this can work I think is when nodes take turn sending messages. Also, what if one of the nodes is malicious and chooses Number.MAX_SAFE_INTEGER as the timestamp? What mechanism is there to prevent unbounded growth?