Network Layer: All about routingIP协议的传输是尽力而为(best-effort)的，因此是可以丢包的 与之对应的是guaranteed-delivery network，需要一个缓存队列，但会导致延时，进而导致超时重发。需要由上层来实现 这一层有network_send和network_handle，后者可能处理，也可能转发 路由有很多网口，实现了跨子网之间的访问

Introduction to Networklayers in network最常见的为四层架构分层，这是根据TCP/IP系统分层的： Application Transport Network Link OSI标准定义的则是七层架构，但TCP/IP四层架构更加实用 Link Layer只处理线段端点间的数据搬运，Network Layer则负责寻找起始节点到目标节点

Consistency under partial failure: 2PC & replicated state machine2PC and CAPCAP认为consistency(linearizability, all-or-nothing, before-or-after, …), availability（响应时间短，规避重启）, partition tolerance（在网络

Transaction & Multi-site Transactiontransaction with high-performance在读多写少的情况下，即大部分事务只读，且单个事务中读远多于写，OCC和2PL能实现很快的性能，但原生的OCC和2PL还不行 对于OCC来说，如果中途有数据被修改了，读修改前的状态就好了。因此引入versionedData，即snapshot 123456

Serializability, OCC & TransactionOCC: optimistic concurrency control死锁难以解决，因此需要避免，可以引入乐观并发控制(OCC)，其认为数据不会被race condition，因此不用拿锁，检查结果，如果真的发生race condition就放弃并重试 OCC执行事务分为以下三个阶段： 并发本地控制：不上锁，读数据放入r

Before-or-after atomicity and Serializability并发能提升吞吐量，但是会危害正确性，因此需要引入before-or-after模型 假设有一个单线程的银行系统，此时请求响应的时间不会仅由RPC和请求处理时间的时间决定，而是由吞吐量决定的。当有多个请求发过来时，请求会陷入排队，出队后才会处理，因此当request arrival rate大于system t

lab2: Distributed FileSystem在lab1中，我们已经实现了基本的inode filesystem，并能够操作directory；而在lab2中，我们需要实现一个分布式的文件系统，该系统分为以下三部分，它们通过rpc进行通信： filesystem client: 文件系统服务器，向metadata server发送请求获取元数据，再向各个data server发送请求修

Realizing atomicity: Logging + Checkpointlogging for atomicitylogging是journaling的扩展，更加通用 log entry是一个原子性的单元，维护能恢复用户数据的修改 transaction用于标记哪些操作是原子性的；commit point为一行代码，经过commit point说明transaction已经是all，此时

Consistency under failure: The requirement of atomicity即使不考虑分布式，故障的发生也可能引发不一致性 fail-stop发生时，整个系统的所有部分都出现failure 以下面的代码为例，必须保证bank(a) + bank(b)不变： 123456transfer(bank, a, b, amt): record = mmap(bank

Consistency when executing operations concurrentlyimplement ChatAPP最简单的方法就是使用一个中心化的服务器，但实际上使用的很少，原因为： 每次post都要网络通信，都要等待response 每次read都要等待RPC 断网时无法访问 服务器挂了就无法处理了 因此系统是需要备份的，不仅备份在server上，也要备份在各个设备上(r