Distributed Systems

Message loss
– Networks are in general unreliable
– Messages can be lost (never been delivered even if sent)
– Examples:
– A server receives too many requests simultaneously so it cannot treat all
– A router drops the message because its queue is full

TCP flow control

– receiver “advertises” free
buffer space by including
rwnd value in TCP header of
receiver-to-sender segments

– RcvBuffer size set via
socket options (typical default is
4096 bytes)

– many operating systems
autoadjust RcvBuffer

– sender limits amount of
unacked (“in-flight”) data to
receiver’s rwnd value

– guarantees receive buffer will
not overflow

TCP congestion control
§ approach: sender increases transmission rate (window
size), probing for usable bandwidth, until loss occurs
• additive increase: increase cwnd by 1 MSS (Maximum
Segment Size) every RTT until loss detected
• multiplicative decrease: cut cwnd in half after loss

TCP slow start is one of the first steps in the congestion control process. It balances the amount of data a sender can transmit (known as the congestion window) with the amount of data the receiver can accept (known as the receiver window). The lower of the two values becomes the maximum amount of data that the sender is allowed to transmit before receiving an acknowledgment from the receiver.

Step-by-step, here’s how slow start works:

A sender attempts to communicate to a receiver. The sender’s initial packet contains a small congestion window, which is determined based on the sender’s maximum window.
The receiver acknowledges the packet and responds with its own window size. If the receiver fails to respond, the sender knows not to continue sending data.
After receiving the acknowledgement, the sender increases the next packet’s window size. The window size gradually increases until the receiver can no longer acknowledge each packet, or until either the sender or the receiver’s window limit is reached.
Once a limit has been determined, slow start’s job is done. Other congestion control algorithms take over to maintain the speed of the connection.

远程过程调用是一种进程间通信技术，用于基于客户端-服务器的应用程序。也称为子例程调用或函数调用。

客户端具有RPC转换并发送到服务器的请求消息。该请求可以是对远程服务器的过程或函数调用。服务器收到请求后，会将所需的响应发送回客户端。服务器正在处理调用时，客户端被阻止，并且仅在服务器完成后才恢复执行。

远程过程调用中的事件顺序如下：

客户端存根由客户端调用。
客户端存根进行系统调用以将消息发送到服务器，并将参数放入消息中。
该消息由客户端的操作系统从客户端发送到服务器。
该消息由服务器操作系统传递到服务器存根。
服务器存根将从消息中删除参数。
然后，服务器存根调用服务器过程。

RPC的一些优点如下：

远程过程调用支持面向过程和面向线程的模型。
RPC的内部消息传递机制对用户隐藏。
在远程过程调用中，重写和重新开发代码的工作最少。
远程过程调用可以在分布式环境以及本地环境中使用。
RPC省略了许多协议层以提高性能。
远程过程调用的缺点
RPC的一些缺点如下：

远程过程调用是可以以不同方式实现的概念。这不是标准。
RPC对于硬件体系结构没有灵活性。它仅基于交互。
由于远程过程调用，导致成本增加。

Related terminology
– Broadcast: one-to-all communication
– Action of sending a message to all nodes of the system
– Typically used for relatively small systems, like IP broadcast as part of Ethernet in
LANs
– Unicast: one-to-one communication
– In contrast with broadcast, describe a special form of distribution to a single receiver
– Used generally in the context of multimedia or streaming applications
– Anycast: one-to-random-one communication
– Send a message to an IP address range from to obtain a response from any
potential receiver, whose IP address belongs to this range
– Used with UDP and TCP
– Geocast: one-to-geographical-neighbors communication
– Send a message to the closest nodes
– Used in mobile ad-hoc networks where communicating with further nodes may be
impossible (e.g., limited transmission range, limited energy)
– Multicast: one-to-many communication
– Action of sending a message to multiple nodes of the system (not necessarily all
nodes)
– This term is used in many contexts (network, algorithm)
– Note: we will use the general term multicast in the following