Computer Networking Lecture Notes

2014 September 15 • Presentation & Session Layers

---

Outline

• Problems remaining.
  • Data representation.
  • Communication patterns.
• The Presentation Layer.
• The Session Layer.

Where We Are

Presentation: data format and representation. Session: The syntax and semantics of the end-points’ communication.

The Territory

Wind Tunnels

Virtual Wind Tunnels

Virtual Wind Tunnel

• A virtual windtunnel is a software simulation of a windtunnel.
  • It produces 100s mbytes of data per run.
• Visualizing the data would provide a quick check on a run’s outcome.
• There is a visualization server on the network.
  • It accepts data and returns a picture, or a movie.

Problems

• There are some problems, though:
  • Does the server use the same floating-point numbers representation as the client?
  • Does the data matrix have the same representation on both sides?
  • A half terabyte is a lot of data to move around.

Spelling Checker

• A spelling-checker server
  • accepts a word from a client, and
  • returns a list of dictionary entries that most closely match the given word.

  

Problems

• Does the server and client agree on string representation?
  • Length + data, or data + delimiter?
• Do the two ends use the same character representation?
  • ASCII vs Unicode.
• Does the server and client agree on a list representation?

Heterogeneity

• Hardware architectures represent basic data types differently.
  • Default integer sizes, floating-point representations.
• Compilers may layout records (structs, classes) differently.
  • Java class fields can be re-arranged for performance.
• Networks are rife with hererogeneity.
• Dealing with hererogeneity is necessary.

Data Sizes

• Shipping around large amounts of data can be inconvienent or expensive.
• Shipping around small amounts of data can be inefficient.
  • Telnet (terminal emulators) sending single-character messages.
• Massage the data to be better behaved in the network.

Security

• Data in transit is not inviolate.
  • It can be observed, stolen, modified, or denied.
• Protecting data in the network (protecting the network) entails responsiblity along the chain.
• Cryptography, a data transformation, is one of the key tools used to provide security.
  • But not the only one.

Data Transformations

• System architectures represent data differently.
  • Different character encodings, for example.
• Data layout may differ.
  • For example, cultural differences.
  • 1.2 vs 1,2 or money denominations ($1 vs £1).
• Data transformations may be required or optional.

Application Solution

• An application could implement its own data transformations.
  • Necessary for special-purpose or rare patterns.
  • Wasteful for common patterns.
• Implementing a transformation can be tedious.
  • Many possible target transformations.
  • Lots of details in each transformation.

Presentation Layer

• Data transformation ubiquity suggests a common facility.
  • That is, make transformations a service.
• The presentation layer offers data transformations to higher layers.
  • Can be thought of as a specialization of the application layer.
• Networks differ in the presentation-layer services offered.

Comparison

• Application-implemented transformations can be exact and optimized.
  • Optimization may be a problem in the long term.
• Presentation-layer services simplify tasks and amortize costs.
  • Particularly true when standards are involved.
• But no need to decide which, use both.

Implementation

• Two general implementation techniques:
  • At the presentation layer (that is, in the network).
  • In libraries (that is, not in the network).
• In general, it’s all libraries, and the presentation layer is more of a fiction than other layers.
• There is limited interaction with lower-layer network services.

Homogeneity

• Define common formats for basic data.
• Define common representations for structured data (arrays, records, …).
• Library procedures translates host data to and from the common representation.
  • Marshalling the basic data.
• Auxiliary programs build custom procedures to marshal structured data.

Examples

• There are a huge number of data interchange formats: XML, ASN.1, IDL, …
• The eXternal Data Representation (XDR, rfc 4560) was defined by Sun Microsystems.

  struct gnumbers {
    long g_assets;
    long g_liabilities;
    }
  
  bool_t xdr_gnumbers(XDR * xdrs, struct gnumbers * gp) {
    if (xdr_long(xdrs, &gp->g_assets) &&
        xdr_long(xdrs, &gp->g_liabilities))
      return TRUE
    return FALSE
    }

Compression

• Compression algorithms reduce data size on one side, and re-expand it on the other.
• There are lots of general purpose compression algorithms
  • Run-length encoding, Huffman encoding, …
• And special-purpose algorithms tailored to the data being compressed.

Remote Procedure Calls

• Client-server interaction looks like a function call.

  Functions are easier to use than are networks.

• Can using a network be as easy as calling a function?

Exceptions

• A server, working in behalf of a client, may throw an exception.
  • Illegal argument values, unexpected computational occurrence, …
• What should happen to the exception?
  • Either ignore it or pass it back to the client.
• How can an exception be brought back to the client?

Group Communication

• Chat groups are a frequent and useful structure.

  A B C msgB msgC msgA msgC msgA msgB

• Each group member may see a different message sequence.
• Can each group member see a consistent message sequence?

Synchronization

• Often group members synchronize over an event.
  • All agree to perform an event.
  • All do an event “at the same time.”
  • The ISO OSI defines synchronization too.
• For example: distributed databases and the two-phase commit or transactions.
• How can group members synchronize?

Communication Patterns

• These communication patterns are common.
  • They occur frequently in applications.
  • They provide a useful core for application design.
• Providing these patterns is a deep and subtle problem.
  • Pattern implementations are sensitive to the underlying network too.
• Sounds like a job for abstraction and encapsulation.

Connections vs Patterns

• Connections and patterns are different but related concepts.
  • A connection is a means for sending a message from one place to another.
  • A communication pattern is a way of sending a sequence of messages.
• The difference is mechanism vs policy.
  • The connection is mechanism, the pattern is policy.
• Patterns use connections.

Application-Based Solutions

• An application could implement its own communication pattern.
  • Necessary for special-purpose or rare patterns.
  • Wasteful for common patterns.
• Implementing a pattern is difficult.
  • Complex and subtle concepts and design.
  • The failure modes are large and varied.
  • Verifying and debugging is a swamp.

Session Layer

• Pattern design and implementation difficulty suggests amortizing cost.
  • That is, make particular communication patterns a service.
• The session layer offers communication patterns to higher layers.
  • Using the services offered by the transport layer.
• Networks differ in the session-layer services offered.

Session-Layer Services

• Provide appropriate communication styles between (or among) end-points.
  • RPC, group communication, broadcast, multicast, …
• Handle transport problems.
  • Disconnection, performance, …
  • Possibly report to application.
• Manage associated resources.
  • Bandwidth, buffering, …

Trade-Offs

• Application-implemented session services can be exact and optimized.
  • But can be expensive to design and implement.
• Session-layer services simplify tasks and amortize costs.
  • But are general-purpose and unoptimized.
• Eventually network knowledge creeps in regardless.

Implementation

• Session-layer services can be implemented in the protocol stack or as a library.
  • In-stack implementations are integrated but inflexible.
  • Libraries adopt to change but are arms-length to the stack.
• Both approaches are useful, and services may move between them.
• Application implementation is still available too.

RPC Libraries

• There’s lots of RPC implementations.
  • Sun (ONC) RPC (rfc 5531), DCE RPC, Java RMI, Web RPC, …
• Almost all RCP systems rely on presentation-layer services to marshal arguments and results.
• RPC is moderately successful.
  • Less painful then using a network directly.
  • Function calls are less flexible in networks.

Horus Group Communications

• The Horus group communication framework from Cornell.
• Many related services provided:
  • Group management.
  • Reliable group communications.
  • Consistent communication delivery.
• Provides a basis for distributed and coordinated applications.

Mahalo Transaction Manager

• The Jini system is a Java-based network space.
  • It is a proto peer-to-peer system.
• Groups may need to interact under a transaction model.
• The Mahalo Jini service allows groups establish transaction-based communication.
  • A group can assemble, interact, and dissolve under transactions dynamically.

Summary

• Application communication may need various data translations and particular communication patterns.
• These needs can be provided by the application, or by a common collection related services.
• The presentation layer provides data translation services.
• The session layer provides communication patterns and related services.

Credits

• Wind Tunnel from Cushing Memorial Library and Archives under a Creative Commons 2.0 BY license.
• Wind Tunnel from Cushing Memorial Library and Archives under a Creative Commons 2.0 BY license.
• CFD Orbiter Model from NASA in the public domain.

---

This page last modified on 2014 September 15.