Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!wiml
From: wiml@milton.u.washington.edu (William Lewis)
Newsgroups: alt.sources.d
Subject: Re: v11i020: Idle demon
Summary: SEAlink
Message-ID: <6772@milton.u.washington.edu>
Date: 28 Aug 90 01:39:51 GMT
References: <1138@mpirbn.mpifr-bonn.mpg.de> <L3VFo1w162w@cybrspc>
Organization: University of Washington, Seattle
Lines: 25

In article <L3VFo1w162w@cybrspc> cybrspc!roy@cs.umn.edu (Roy M. Silvernail) writes:
>Now, the question in my mind (and this really has nothing to do with the
>original thread :-) is... which type is SEAlink? I have used it on
>several systems, and had varying results. In some cases, it has behaved
>as a streamer (with no activity seen on the alternate-channel modem
>light), and sometimes it's acted like a sliding-window, if not downright
>packetized.

   Well, last I checked, SEAlink was a very lightly modified XMODEM (CRC)
and sliding window. Basically, the ACK/NAK byte was expanded to a 
very small (3 or 5 byte) packet containing the last valid packet received.
The window size defaulted to something on the order of 6 XMODEM packets.
I have no idea why it wouldn't show activity on the return channel; maybe
the modem light flickered too briefly for a packet only 5 bytes long?
Or maybe the protocol has been updated since I looked at it, though
I doubt it.

  [Note also that using SEA products is sometimes considered politically
incorrect, after SEA sued PKWare ... though, SEAlink *is* a nice clean
protocol .. and this doesn't belong in this group anyway.]


-- 
wiml@blake.acs.washington.edu       Seattle, Washington  | No sig under
(William Lewis)  |  47 41' 15" N   122 42' 58" W  |||||||| construction