server

application-level

each new application must implement its own protocol logic, leading to higher development effort and less reuse.

middleware-level

promotes code reuse, interoperability, and simplifies development by abstracting network details from the application.

x-window system

1. The client app (on a remote machine) uses _lib to communicate.

2. It sends GUI commands over the _ protocol to the _ server.

3. The _ server renders graphics and sends back user input (keyboard/mouse) events.

application

the _ acts as a client to the X-kernel, the latter running as a server on the client’s machine.

separation

in x window systems, there is often no clear _ between application logic and user-interface commands (mixed)

synchronous

in x-window systems, applications tend to operate in a tightly _ manner with an X kernel (affects performance – waits for responses)

access transparency

conceal resource access using client-side stubs for RPCs

location or migration transparency

conceal resource location and let client-side software keep track of the actual location

replication transparency

multiple invocations handled by the client stub

failure transparency

can often be placed only at the client (mask server and communication _).

sever basic model

process implementing a specific service on behalf of a collection of clients. It waits for an incoming request from a client and subsequently ensures that the request is taken care of, after which it waits for the next incoming request.

iterative server

server handles the request before attending the next request

concurrent server

uses a dispatcher, which picks up an incoming request that is then passed on to a separate thread/process. It can handle multiple requests in parallel (at the same time).

multiple

concurrent servers are the norm: they can easily handle multiple _, notably in the presence of blocking operations (to disks or other servers).

daemon registry

server is always running and clients request endpoints dynamically; persistent services

1. The client asks the _ on the server machine for an available endpoint.

2. The _ provides the client with the endpoint and the client uses it to request service from the appropriate server.

3. The server registers its endpoint with the _ (which maintains an endpoint table).

super-server model

spawns a specific server only when a client request arrives; on-demand environments

1. The client sends a request for service to a _ server.

2. The _ server dynamically creates or activates a specific server.

3. The specific server takes over and continues servicing the client directly.

stateless servers

never keep accurate information about the status of a client after having handled a request; independent and produce state inconsistencies; easier to manage, and fault-tolerant—ideal for RESTful APIs and services like DNS

stateful servers

keeps track of the status of its clients; high performance but harder scalability; useful for more personalized and context-aware interactions, such as in online banking, shopping carts, or gaming

request dispatching

the first tier is generally responsible for passing requests to an appropriate server

bottleneck

having the first tier handle all communication from/to the cluster may lead to a _. Imagine only having one load balancer.

tcp handoff

selected server takes over the connection and continues communication with the client; the server processes the request and sends a response directly to the client; from the client’s perspective, it feels like a

single continuous connection.

transport-layer switching

front end simply passes the TCP request to one of the servers, taking some performance metric into account.

content-aware distribution

front end reads the content of the request and then selects the best server.

single cloud provider

spreading servers across the Internet may introduce administrative problems; can be largely circumvented by using data centers from a _.

route optimization

can be used to make different clients believe they are communicating with a single server, where, in fact, each client is communicating with a different member node of the distributed server

collaborative distributed systems

Origin server maintains a home address, but hands off connections to the address of collaborating peer ⇒ origin server and peer appear as one server.

vserver

independent and protected environment with its own libraries, server versions, and so on.