Application Layer Framing

ApplicationLayerFraming is a design principle for protocols for DistributedComputing. Here it is in a pattern form...

Application Layer Framing

Identifying protocol data units using identifiers allocated by the protocol itself leads to inefficiencies.

Therefore: use application level identifiers to identify protocol data units and take advantage of application level semantics to improve performance.

Example

Consider a multiplayer game protocol. If a player fires a missile, a message must be sent to other processes informing them of the existence of the missile and its location, heading etc. The other processes can then create a proxy for the missile in their address spaces. As the missile moves, the controlling process sends out updates and other processes update their proxy.

Imagine what would happen if the packet containing the "create" message got discarded between the controlling process and another process...

If the create messages were transmitted over a reliable transport protocol, the transport protocol would identify each packet using some transport-level identifier (e.g. a sequence number) and use these identifiers in acknowledgement messages. The sender would store the packet containing the create message until it had received an acknowledgement for the message. If the packet was not acknowledged within some time period it would retransmit the packet.

However, when the packet was retransmitted, it would contain out of date information, because the missile would had moved during the timeout period! Therefore the receiving process would see an awkward "jitter" in the animation of the missile.

Alternatively, one can use application-layer information to implement reliability. Each actor in the game already has a system wide identity so that received updates are applied to the appropriate proxies. When the create message for the missile gets lost between the controlling process and the receiving process, the receiving process detects that loss by receiving an update for an object for which it has not yet created a proxy. It can then request retransmission of the create message for that object. The controller of the missile will receive the retransmission request and can reply with a new create message that contains the latest position and heading information for the missile. When the receiving process receives the new create message it can create a missile proxy at the correct position in virtual space such that update messages cause smooth animation rather than an awkward jump.

Known Uses

RTP is designed according to the principles of ApplicationLayerFraming and IntegratedLayerProcessing.

The FSP file-transfer protocol uses ALF and ILP principles in its design.

Related Patterns

ApplicationLayerFraming implies the use of IntegratedLayerProcessing.

I don't see this implication. I first came across this concept with DavidTennenhouse? 's work on digital video at MIT (similar problem, whether a frame is worth repeating depends on whether the client thinks it's gone out of date). Anyway, another approach is to use some kind of meta-technique -- pass an object to the communications layer that implements the decision-making about what to do with the next frame. The application gets to make the choices but you don't need to expose (or rewrite) the communications layer. --SteveFreeman

The implication is that the application layer protocol is integrated with mechanisms usually implemented by the transport layer protocol.

The ability to configure the transport layer with application-layer Strategies is an interesting approach (are there any papers available about it?). It sounds similar to the "exo-kernel" operating-system approach. You would still need to provide ApplicationLayerFraming information in the messages to allow strategies to make decisions based on application information, unless the Strategies could also change the information send in transport headers.

--NatPryce

The point about the meta/exo/whatever approach is that integrating the two layers is not the only approach to this problem. Of course, the transport layer has to define an API for strategy objects but (if you're lucky and good) that shouldn't be specific to a single application. Of course, doing something generic would probably be enough for a second PhD. As for papers, one reference is:

David D. Clark, David L. Tennenhouse. Architectural Considerations for a New Generation Protocols. Computer Communication Review, Vol. 20, No. 4, SIGCOMM '90, September 1990, pp. 200-208.

I haven't found a copy on the web. -- SteveFreeman