EventHelix.com: CASE Tools; Real-time and Embedded System Design; Object Oriented Design
  Home  |  EventStudio System Designer 4.0  |  VisualEther Protocol Analyzer 1.0  Real-time Mantra  Contact Us

EventHelix Update Q2 2004

Dear Subscriber,
 
Here is a list of recent updates to EventHelix.com:
 

The Receive Protocol Handler Design Pattern provides a common framework for receive direction sliding window protocol implementation. This pattern is implemented by just one class, Receive Protocol Handler. This class receives the packets from the other end and performs the following operations:
  • Check validity of the received packet
  • Ask Transmit Protocol Handler to acknowledge the received packet
  • Check if the remote end has acknowledged that was sent by Transmit Protocol Handler.
  • Inform Transmit Protocol Handler about acknowledged packet.

Order your EventStudio license by June 15, 2004 and receive lifetime free support and upgrades.
 

This pattern provides a framework for implementing a sliding window protocol. The Transmit Protocol Handler receives a packet from the higher layer and transmits it to the lower layer after assigning a sequence number. The packet is also stored in an internal retransmission buffer. The packet is removed from the retransmission queue if the remote end acknowledges the packet. The Transmit Protocol Handler retransmits the packet if it times out for an acknowledgement.
 

A protocol stack generally handles multiple layers of a protocol. Each layer of the protocol adds its own headers and trailers. Due to these headers and trailers, the size of the buffer containing the message keeps changing. In most implementations this results in each layer allocating a new buffer to adjust to the changed buffer size. The Protocol Packet pattern addresses this issue with a simple and efficient buffering architecture.
 

The Dependency Inversion Principle has been proposed by Robert C. Martin. It states that:

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

This principle seeks to "invert" the conventional notion that high level modules in software should depend upon the lower level modules. The principle states that high level or low level modules should not depend upon each other, instead they should depend upon abstractions.

-- EventHelix.com Team
  Home  |  EventStudio System Designer 4.0  |  VisualEther Protocol Analyzer 1.0  Real-time Mantra  Contact Us
Copyright © 2000-2008 EventHelix.com Inc. All Rights Reserved.