From: geoff@zswamp.UUCP (Geoffrey Welsh)
Newsgroups: comp.dcom.modems
Subject: Re: Where is doc on Sealink protocol?
Keywords: SeaLink
Date: Wed, 15 Apr 92 21:15:27 EDT
Organization: Izot's Swamp

dhoerl@cbnewsm.cb.att.com (david.f.hoerl) writes:

> Would some kind person point me to a site (and a path) to a document
> describing the Sealink protocol? Please reply directly to me. Thanks.

   I was going to mail this to David and post an offer to send a copy to 
anyone who wanted it, but the doc is very short (less than 200 lines; less 
than 10K) so I thought that I'd just post it.  There is also some 'C' code, 
but it amounts to 21K at 560 lines, so I'll leave that for requests only.

--- cut here --- excerpt from sealink.doc ---

                                     SEALINK

                             File Transfer Protocol

                                 9 February 1987



          (C) COPYRIGHT 1986,87 by System Enhancement Associates, Inc.



     This document describes briefly the  SEAlink  file  transfer  protocol
     developers' package.  SEAlink is a sliding  window  protocol  that  is
     fully  backwards compatible with XMODEM in all tested implementations.

     The intent of SEAlink is to provide a file transfer protocol that does
     not  suffer  from  propagation  delays,  such  as  are  introduced  by
     satellite relays or packet switched  networks.  Actual  tests  of  the
     enclosed  routines  has  shown  that  SEAlink  is capable of virtually
     eliminating propagation delays and turnaround delays.  File  transfers
     between New Jersey and Hawaii,  which normally suffer a degradation of
     50% or more  due  to  satellite  relays,  proceed  as  fast  as  local
     transfers.  Even transfers within the local exchange are speeded up by
     up to 20% at 2400 baud by the elimination of turnaround delays.  Large
     volume  tests  show  that SEAlink is capable of coming to within 2% of
     the theoretical minimum time for data transfer.



     The developers' package contains the following files:

         SEALINK.DOC    This document.
         SEALINK.C      A set of C routines for implementing SEAlink.
         CLINK.EXE      A sample TTY program that implements SEAlink.



     You are granted a license to use this code in your  programs,  and  to
     adapt  it to your particular situation and needs,  subject only to the
     following conditions:

     1) You must refer to it as the SEAlink protocol,  and  you  must  give
        credit to System Enhancement Associates.

     2) If  you  modify  it in such a way that your version cannot converse
        with the original code as supplied by us,  then you should refer to
        it as "SEAlink derived",  or as a "variation of SEAlink",  or words
        to that effect.

     In short,  we're not asking for any money,  but we'd like to get  some
     credit for our work.


     This  document  is  not  meant  to  be  a  rigorous  definition of the
     protocol.  The code provided should serve to document the details  and
     fine  points  of  implementing SEAlink.  We will,  however,  present a
     brief synopsis of how SEAlink adds sliding windows to XMODEM,  and why
     XMODEM doesn't mind.

     First of all,  SEAlink adds a block number to the ACK and NAK used  in
     XMODEM.(1)  We  thus  create  "ACK/NAK  packets",  with  the following
     structure:

         Byte 0:   ACK, NAK, or C
         Byte 1:   Block number
         Byte 2:   One's compliment of block number

     This is identical in form to the first three bytes of a  data  packet,
     except that the SOH has been replaced with an ACK or NAK.(2)

     From the receiver's point of view,  it does not matter if  the  trans-
     mitter  is using sliding window or not.  The receiver simply sends ACK
     and NAK packets as appropriate.  Any XMODEM driver tested to date will
     simply ignore this excess data behind the ACK or NAK.

     From the transmitter's point of view,  it just barely matters  if  the
     receiver can handle sliding window.  The transmitter always acts as if
     it  is  sending sliding window,  but varies the window size.  If it is
     seeing valid block numbers and check values behind the  received  ACKs
     and NAKs,  it sets the window size to six blocks.  Otherwise,  it sets
     the  window  size  to  one  block.  The  result is that it only "sends
     ahead" if the receiver can handle it.

     It  should  be  a fairly simple matter to apply the underlying SEAlink
     logic to almost any variant of XMODEM.


     The  SEAlink  routines  provided  in  this package are also capable of
     passing system dependent information,  such as true file size and time
     of  last modification.  This data is passed in a special header block.
     The header block looks exactly like any other block, except that it is
     block number zero.

     This is still backwards compatible with XMODEM,  as a SEAlink receiver
     does  not  mind if block zero is missing,  and any XMODEM receiver yet
     tested will regard block zero as a duplicate block and ACK it.

     The data portion of block zero contains the following fields:


         Offset    Size      Contents
         ======    ====      ========

            0        4       Original file length.
            4        4       Date  and  time  file  was  last mofified,  in
                             seconds since 1979.
            8       17       Original  file  name,  as  a  null  terminated
                             string.
           25       15       Name  of  transmitting  program,   as  a  null
                             terminated string.
           40       88       Null filler and expansion area.


     (1) XMODEM/CRC uses a "C" in place of  a  NAK  to  indicate  CRC  error
         detection.  SEAlink  follows  this convention,  and supports either
         checksum or CRC.  For brevity,  this document will use the term NAK
         to mean either a true NAK (hex 15) or a C (hex 43).
     (2) See previous footnote.

     Any field which the transmitter cannot support should be  set  to  all
     zeros.  Conversly,  the  receiver  should ignore any null fields.  The
     receiver may ignore any field which he cannot support.

--- cut here ---

   The rest of the doc talks about the example code.

   NOTE: (1) above suggests that a 'C' and a NAK are interchangeable in XMODEM 
CRC; this is not, as far as I know, true.  XMODEM CRC uses a 'C' in stead of a 
NAK to *initiate* the transfer, but uses the normal NAK character to indicate 
an incorrectly received block.

Geoffrey Welsh, 412-305 Margaret Avenue, Kitchener Ontario, N2H 6S4 Canada
geoff@zswamp.uucp, { watmath!xenitec | m2xenix }!zswamp!geoff (519)742-1228
"Show us your sig." "Seeg?  I don't need no steenking seeg!"
Newsgroups: comp.dcom.modems,comp.protocols.misc,comp.sys.amiga.datacomm