From: karn@servo.qualcomm.com (Phil Karn)
Subject: Re: SLIP - What is (answer) - NOS versions, 'dialer', SLIP timeout., finger (questions) Thanks!
Organization: Qualcomm, Inc
Date: Wed, 6 Jan 1993 09:13:32 GMT

In article <C0E2nH.uqv@austin.ibm.com> miltonm@inetnode.austin.ibm.com (Milton Miller) writes:
>My understanding is Phil Karn has done it.  He released the code in June,
>although the initial release had a "peter waiting on paul waiting on peter"
>syndrome.   I don't rember the fix.  Phil also just released a new
>set of code today (yesterday?) on ucsd.  Since there were several problems
>with the June release (Phil called it beta code; it was somewhere between
>alpha and beta quality), none of the other enhancers picked up the code,
>opting to stick with the known 12/21/91 release.

Actually, other than adding the "answer" script, fixing a few minor
bugs and making some internal changes to allow dialing on media other
than asynch lines, I really haven't done anything to the dialer code
in quite some time. I use it constantly (right now, as a matter of
fact) and it is pretty solid.

>>1 - Keep a line up, ie dial a connection to another site and keep it  
>>going, redialing automatically if the link should drop.  The version  
>>of 'dialer' described in my docs seems like it is written  
>>specifically for this purpose.
>
>This is the code in the 12/21/91 release and derivatives (PA0GRI, 
>WG7J, etc).

Yes, this is what the original dialer did. I ran it for years when I
lived in New Jersey. Even though I never heard a peep from NJ Bell
about the continuous 1 Erlang load on my second phone line, I always
felt a little guilty about it. However, to get the free local call
into Bellcore I had to dial into a location other than the one where I
worked and hop back over a brain-damaged Micom terminal network. This
was such a slow and painful process (and one I could not easily initiate
in the other direction) that I opted to keep the line nailed up
continuously, with the call always placed from home.

However, now that I live in San Diego and am a local phone call away
from Qualcomm's netblazer, I decided to do the job right and bring
up the link only when it's needed.

>>2 - Demand dial a line, ie when I try to send a packet through that  
>>port, if the connection is down it dials.  If the connection should  
>>be terminated (ie ma bell gives up or the other side times out), my  
>>side does nothing unless another packet is sent.  I was also thinking  
>>another that a timeout on my end would be nice, ie set a maximum time  
>>that my end will keep the connection going in the absence of traffic.
>
>Phil has done the above.  According to his last post, the latest
>code is split into up, down, and ring scripts so he can share
>his modem line with his autoswitch fax!

Yup, this is exactly how the code works, even down to the single try
per packet. When you send a packet and the link is down, it is held.
If the dial attempt succeeds, the packet (and any others that have
arrived in the send queue) are sent. If the attempt fails, the packet
that caused it is dropped. If there's another packet waiting in
the queue, another attempt is immediately made. Otherwise it waits
for another packet to arrive before it does anything.

I do it this way to avoid any built-in "retry" timeouts in the dialer
code. I instead rely on TCP retransmission backoffs to time each
successive call attempt. I used to redial repeatedly from a single
packet with my own built-in backoff, but this was much less
satisfactory because once you got into that mode, there was no
external way to control it. With the new way I can manually force
continuous redialing by just starting up a repeating ping session
across the path.

I note that the internal hooks are now there to let you implement
"demand dialing" of AX.25 connections if you so desire, although I
don't see much point since an AX.25 "connection" doesn't really cost
anything but a little RAM at each end to keep open and idle.

>No, you can connect to a local socket.   For it to work without a
>domain.txt for the hostname, use the loopback address (127.0.0.1).

Right. This is a convention I picked up from BSD UNIX. You can always
talk to yourself by using IP address 127.0.0.1, regardless of any
other addresses you may have. There's a built-in "pseudo-interface"
called the "loopback" interface with this address.

Phil