Browse Prior Art Database

Request/Reply Loss Detection

IP.com Disclosure Number: IPCOM000123501D
Original Publication Date: 1998-Dec-01
Included in the Prior Art Database: 2005-Apr-04
Document File: 2 page(s) / 67K

Publishing Venue

IBM

Related People

Case, RB: AUTHOR [+3]

Abstract

To respond to known limitations and generally improve the operational characteristics of ARB in HPR networks, enhancements have been made in several areas. Although these enhancements were developed for HPR, many of the ideas may also apply to other types of networks using rate-based flow control.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Request/Reply Loss Detection

   To respond to known limitations and generally improve the
operational characteristics of ARB in HPR networks, enhancements
have been made in several areas.  Although these enhancements were
developed for HPR, many of the ideas may also apply to other types of
networks using rate-based flow control.

   Round trip request/reply messages are often used in
networking systems to provide feedback.  If a reply is not received,
the request sender generally cannot tell whether the request or reply
was lost.  In some cases (such as ARB), it may be important to keep
state information in sync between the sender and receiver.  In case
of a lost message, a recovery protocol is needed to resychronize the
sender and receiver since it is not known whether a request or reply
was lost.  A new, very efficient, recovery protocol is included in
the Responsive mode ARB specification.  The protocol uses a
"correlator" field and a "parity" bit that are sent on each message.
If the sender does not receive a reply to a request, it assumes the
request was lost.  State changes from the lost request are backed
out.  A new request is sent, incrementing the correlator field and
inverting the parity bit.  If the receiver receives a request with an
unexpected correlator, it knows a previous request was lost, but the
sender has already backed out state changes from the lost request and
the new request received is processed normally.  If the receiver
receives a request with the expected correlator but a different
parity indicator from the previous request, the receiver knows the...