Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!bellcore!ka9q.bellcore.com!karn
From: karn@ka9q.bellcore.com (Phil Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Dial up access to Internet facilities
Message-ID: <23827@bellcore.bellcore.com>
Date: 3 Jun 90 00:24:36 GMT
References: <1990May25.163528.14300@ameristar> <9005270423.AA19852@psi.com> <1990May29.191125.9800@portia.Stanford.EDU> <56756@bbn.BBN.COM>
Sender: news@bellcore.bellcore.com
Reply-To: karn@ka9q.bellcore.com (Phil Karn)
Organization: Secular Humanists for No-Code
Lines: 28

In article <1990May29.191125.9800@portia.Stanford.EDU> morgan@jessica.stanford.edu (RL "Bob" Morgan) writes:
>
>Indeed, SMTP's assumption that everybody's connected all the time
>>doesn't work well with occasionally-connected hosts.  [...]

I'm also very interested in making the Internet protocols work well over
non-full-time paths. 

Here's an idea that I put into my KA9Q TCP/IP package a while ago.  It has a
UDP-based server that handles "kick" requests. These force retransmissions
on any TCP connections to the specified IP address (which defaults to the
sender of the kick message) and they also cause the remote SMTP daemon to
start sending any pending traffic to the destination.

This has turned out to be a useful feature when dealing with dialup links or
the long network outages that are characteristic of some experimental
amateur packet radio links. When the path is up, the person expecting mail
sends a kick request to the site(s) from which he expects his traffic, e.g.,
a mail exchanger. If there's any traffic waiting, it immediately starts to
flow. Also, because my TCP connections never time out (they just back way
off) the kick command lets you pick up a partial transfer right where you
left off when the path broke without having to restart it from the
beginning.

Perhaps it's time for an "intermittent connectivity" working group in the
IETF?

Phil