Re: [colorforth] bulk transfer protocol

["Robert Patten" <pattenre@xxxxxxxxxxx>]

----- Original Message ----- 
From: "Mark Slicker" <maslicke@xxxxxxxxxxx>
To: <colorforth@xxxxxxxxxxxxxxxxxx>
Sent: Monday, May 03, 2004 12:33 PM
Subject: Re: [colorforth] bulk transfer protocol


> On Sat, 1 May 2004, Robert Patten wrote:
>
> > Mark , This is from my notes. I have not made time to impliment.
> >
> >          A "device" may take a IP address and port number to set up.
> > All block I/O is then from or to that device and local memory
> > on this device.
> >     These words take a block number. A device can be anything
> > that can accept or send a block.
> >
> > "get" block from that device.
> >
> > "put" block to that device.( actually a request for that device to
> >     get the block from this device. Put is repeated until block
> >      is sent in response to the get request from device.
> >      This allows the device to allocate  block
> >      and to request block until received.)
>
> Chuck has "get" and "put", however they are implemented somewhat
> differently.
>
> "get" sends a block number to a host, the host replies with the block
> number and the block from its archive (an offset of 300 blocks). The
reply
> from the host is actually the "put" message. The reciever of the "put"
> message, will write the incoming block to its archive.
>
 The "put" I was talking about is not the response to a "get"  but a
request  for that device to prepair a block buffer to retrive the block
from me and then get it when needed or when  channel is idel.   The
recieving device requests blocks when needed or when it's internet
recieve connection is idel. Congestion  usally happons when the
recieving address is reciving other trafic.

> My proposal is a multiple "get". It seems the bit array would allow
for a
> very simple way to keep track of the blocks that are received
properly. An
> additional request would simply send the current state of the bit
array.
>
> The point of this, might be to increase the efficiency of bulk
transfers
> over the Internet, and also provide a simpler protocol with a simpler
> implementation. I think with this method you still need good
stratagies
> of when to send data and when to request retransmission.
>
> Mark
>
"annex" ( blocks- )

    Form: <red> groupName <yellow>6 annex ( exiting block to next group)
    may be placed at beginning of  first or second block of group.

This is a word that can be used to mark blocks in your block bit array
that needs to be updated from transmiting device before they are used.
The flow control should be handled by the receiving device by requesting
blocks at a rate that the receiving device can accept.  The
transmitting device  will  respond  to request for block when transmit
channel  is available.  If there is traffic congestion,  the time
between request and reception will increase then double the delay to
send the next request.  When receive time falls then  half  request
time.  This will handle flow control. Do not let  request delay time
fall below 1/2 the time nessary to recieve a block.


Robert


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com