🚀 go-pugleaf

In article <marlow.717842425@radon.sys.uea.ac.uk> marlow@sys.uea.ac.uk (K. Marlow PG) writes:
>  I just want to ask those in the known, is the timeout for an econet
>transmit an absolute stop point or just a point at which it says the
>transmission has failed? Say if I had my timeout set to 1 second and a repeat
>count of 10, would that mean the first transmission (which is queued due to
>the network being busy) be aborted after 1 second or does it just
>decrease the repeat count & keep on with the same queued transmission?  If
>it does the first then I could see situations where a transmission doesn't
>occur because it never reaches the top of the queue in time.  This is
>something which the PRM's aren't very clear on & might explain some strange
>behaviour I'm getting..

OK. The PRMs are NOT at all clear on network behavior.

Econet's protocol is based around a four-way handshake (ignoring
broadcasts, which are a special case). The sending machine sends a
scout frame, which is *IMMEDIATELY* followed by the recipient sending
an acknowledge (if it is willing to accept a transmission from that
machine on that port of that length), in turn *IMMEDIATELY* followed
by the sending machine sending the full data, which is then
*IMMEDIATELY* acknowledged by the receiving machine. Then the network
is sent idle, and someone else takes it.

If two people try transmitting at once, then one or both scout frames
will be lost, and one or both machines will perform a random back-off.
If the scout frame gets through, the transmission is then allowed to
run uninterrupted to completion, if the two machines negotiate
correctly.

The practical upshot of this is that if a transmission is marked, at a
given instant, as failed, then no scout frame has got through. This is
equivalent to the rest of the world to your never having tried to
send. SO - trying to send for ten seconds is the same as trying to
send for one second ten times in quick succession, apart from the
small periods in which you're not trying to send.

There is no network queue as such, as previously explained.

Why do you want to do several short timeouts instead of one long one,
though? If it's just so that you can continue processing in the
meantime, you ought to use background operations (i.e.
Econet_Transmit, Econet_PollTransmit, etc. rather than Econet_DoTransmit).

>  Also what do people reckon is a sensible length of timeout to have.. 5
>seconds, maybe 10?

I tend to use a timeout of 30 seconds, but let the user press Escape.

--Clive.

crj10@phx.cam.ac.uk (Clive Jones) writes:

>In article <marlow.717842425@radon.sys.uea.ac.uk> marlow@sys.uea.ac.uk (K. Marlow PG) writes:
>>  I just want to ask those in the known, is the timeout for an econet
>>transmit an absolute stop point or just a point at which it says the
>>transmission has failed? Say if I had my timeout set to 1 second and a repeat
>>[...]

>OK. The PRMs are NOT at all clear on network behavior.
  Ah, I'm glad someone else noticed.  :-)

[...]

>If two people try transmitting at once, then one or both scout frames
>will be lost, and one or both machines will perform a random back-off.
>If the scout frame gets through, the transmission is then allowed to
>run uninterrupted to completion, if the two machines negotiate
>correctly.

>The practical upshot of this is that if a transmission is marked, at a
>given instant, as failed, then no scout frame has got through. This is
>equivalent to the rest of the world to your never having tried to
>send. SO - trying to send for ten seconds is the same as trying to
>send for one second ten times in quick succession, apart from the
>small periods in which you're not trying to send.

>There is no network queue as such, as previously explained.
  Er, are you sure that there isn't a transmit queue?  What would happen if
I tried to start several transmits at once using Econet_Transmit?  or are you
saying that all the waiting transmits try to contend for the line at the
same time?

>Why do you want to do several short timeouts instead of one long one,
>though? If it's just so that you can continue processing in the
>meantime, you ought to use background operations (i.e.
>Econet_Transmit, Econet_PollTransmit, etc. rather than Econet_DoTransmit).

  I do do that via an EconetSupport module which implements a true event queue
which is read by the polling wimp application.  Handles all the rma &
control blocks.  This sits under an Econet C library which makes a connection
across econet look like a form of two way synchronous virtual link, gets rid
off the need for me to mess around with the econet specific bits in the
application code & allows me to write econet apps quite quickly.

  Also, you seem to imply that one long timeout is the same in effect as
several short timeouts, if that was the case I would thought that there
would have been only the one parameter?  There must be some difference in
effect.

>>  Also what do people reckon is a sensible length of timeout to have.. 5
>>seconds, maybe 10?

>I tend to use a timeout of 30 seconds, but let the user press Escape.
  Hmm, I suppose I'd better make the timeout & count parameters passed to my
Econet library, then my beta testers can play with the settings & see what
happens.

>--Clive.
--
 Keith Marlow,               *  Author of Archiboard BBS s/w, 
 Information Systems P/G,    * the only multiline fidonet BBS which operates
 University of East Anglia,  * across Econet.
 Norwich. Norfolk NR4 7TJ    *

Keith and Clive,

  I have spent some time studying the Econet code and what it does is this.

  When StartTransmit is called the data from registers is checked and copied
to an RMA block.  Included in this block are the delay time (as passed in),
the "start time" (initialised with the current time) and "finish time"
(initialised with the current time plus ten seconds).  The status is set to
TxReady.  This block is then stored as a part of a list

  Every centi-second the Econet code scans the list looking for TxCBs that
are TxReady and have a start time <= the current time, when such a TxCB is
found a pointer to it is passed to a standard routine for "starting" a
transmission this routine first tries to get "line access" i.e. it sees if
another station is transmitting.  If there is access to the line the scout
packet is sent.  If the scout packet fails (NotListening) then the count
value is decremented, if it becomes <= zero then the Not Listening status is
recorded on the TxCB and that is that.  If the count value has not yet
reached zero then the delay time is added to the start time to make the new
start time and ten seconds is added to that new start time to make the new
finish time, and the status is set to TxReady.  If there was no line access
then the status is set to TxReady and none of the times or the count value
are changed, however the current time is compared to the finish time and if
the finish time is <= to the current time the TxCB is marked LineJammed and
that is that.

  The PRM tries to explain this on pages 1339, 1340 and elaborates on page
1362.

  There isn't a queue as such there is a list (ordered by initial creation
time) and this list contains all active transmissions i.e. from
StartTransmit to AbandonTransmit.  The processing of the list is as
described above.

  As to the choice of count and delay times, this is a matter for the
programmer to decide.  The product of the count and delay values will give
the approximate time before a 'terminal' status like NotListening or
NetError will be returned (the exact time is (Count-1)*Delay).  It is usual
to set this to be between ten and forty seconds depending on the behaviour
of the receiving machine.  The actual delay value gives control over the
granularity of noticing the state of the receiving station.  For example if
the count and delay are set to 2001 and 1 and the receiving station is not
ready then the NotListening status will occur after 20 seconds, this would
be that same as the other extreme values 2 and 2000.  However in the former
case within a centi-second of the receiving machine opening an RxCB the
transmitter will succede, the latter case it will only 'notice' at the
expiration of the 20 seconds.  There is a drawback to always using a delay
of one centi-second and that is other processes and other machines will find
the world very hostile and difficult to use.  Most Acorn protocols use a 10
centi-second delay value.  This gives a nice balance to responsiveness and
fairness without overloading the network or the machine.  Note that if your
receiver is known to have particular characteristics e.g. a server which
always takes five seconds to process a request before accepting the next one
then turning up the delay to, say, 100 centi-seconds would be the right
thing to do.

  Hope that makes things a little clearer.

  Bruce.

Any views expressed are my own and are not necessarily those     _--_|\ 
of Acorn. Any factual information is given in good faith and    /      \
neither I, nor Acorn can accept liability for loss or damage    \_.--._/
resulting from its use.                                               v