Browse Prior Art Database

Client/Server-based File Transmission Checkpoint/Restart Protocol

IP.com Disclosure Number: IPCOM000116409D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2005-Mar-30
Document File: 4 page(s) / 108K

Publishing Venue

IBM

Related People

Black, BA: AUTHOR [+6]

Abstract

Proposed is a protocol for performing checkpoint/restart during file transmission (the underlying data transfer mechanism is TCP/IP sockets). Reference Fig. 1 for an overview of a normal file transmission. Fig. 2 illustrates the protocol for file transmission checkpoint/restart.

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

Client/Server-based File Transmission Checkpoint/Restart Protocol

      Proposed is a protocol for performing checkpoint/restart during
file transmission (the underlying data transfer mechanism is TCP/IP
sockets).  Reference Fig. 1 for an overview of a normal file
transmission.  Fig. 2 illustrates the protocol for file transmission
checkpoint/restart.

      The following bullets describe the details of the protocol and
the bullet numbers correspond to the matching numbers in the figures.
  1.  Before a file transmission starts, a client sends the length of
       the file name including the indicator whether the file has a
       checkpoint or not and the length of all the print options.
For
       example,
      o  filename**-opagedef=P1A06462 -oformdef=F1010101
             Where "**" is the separator between a file name and the
              print options.
      o  filename..**-opagedef=P1A06462 -oformdef=F1010101
             Where ".." indicates that the file has a checkpoint
              associated with it.
      A buffer of the file name and print options data follows.
  2.  The client sends a length (size) of a data buffer to the server
       then follows up with the data buffer itself.  The server uses
the
       buffer length to determine if all the buffer data is received.
  3.  When the checkpoint interval expires, the client sends a
       checkpoint flag to the server and follows with the total
number
       of bytes transmitted during this checkpoint period.
  4.  The server reconciles the client total byte count with its own
       total byte count.  If the two counts do not match, the server
       sends a negative acknowledgement to the client and goes
waiting
       for the client to send the next file or the same file (with or
       without a checkpoint).  Upon receiving the negative
       acknowledgement, the client then goes to process the next file
or
       reprocess the current file if retry is needed.
  5.  If the total byte counts match, the server updates the
checkpoint
       control file.  Each file being transmitted has a separate
       checkpoint file where the latest checkpoint position (byte
count
       from the beginning of file) is registered.  The server...