Re: [colorforth] bulk transfer protocol

["Robert Patten" <pattenre@xxxxxxxxxxx>]

----- Original Message ----- 
From: "Mark Slicker" <maslicke@xxxxxxxxxxx>
To: <colorforth@xxxxxxxxxxxxxxxxxx>
Sent: Tuesday, May 04, 2004 10:27 PM
Subject: Re: [colorforth] bulk transfer protocol


> On Sun, 2 May 2004, Robert Patten wrote:
> >  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.
>
> That is one form of congestion. An example might be an overloaded
server.
> The routers can drop packets as well, since they only have a finite
queue
> and the the outgoing capacity can be less than the incomming capacity.

All examples of the next device busey with other packets.
>
>
> > "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.
>
> My scheme is multiple request, it is not a block by block scheme. A
block
> by block scheme may not perform favorable compared to TCP. You would
have
> add the round trip time for each new block tranfered. TCP has a window
> which allows multiple segments to be sent unaknowledged.
>
> Without any response from the reciever, the sender is blind. For this
> scheme to succesfully avoid congestion and avoid causing congestion,
some
> of the techniques from the advanced TCP implementations must be
adopted.
> This implies some form of sender/reciever interaction.

Please impliment tcp/ip  and its complexity of sending blindly hoping
that it is sending packets at the right rate.
 I am sugesting a simpler way of achiving reliable delivery, where  the
reciever has absoute control over the packets not the sender.  Where
your bit array is used to mark blocks that need to be requested when the
reciever needs them or when the reciver can accept them.  The
application on the recieving device will automaticaly priatize which
blocks are requested  next.  The transmiting device does not need to
keep track of what has ben sent but not acknologed,or even retranmiting
packets that were lost.
The  reciever asks for a block when it has the compasity to recieve it.
If there is congestion the delay is longer and the time between requests
is doubled.  When the time decreases, half the delay time for the next
request.
The reciver asks for blocks fast enough to keep its recive channel full.
May even ask from multiple mirrored sources if the reciver is wider then
the transmiters.  The  reciever stops asking for a block when it is
recieved.

Mirrored devices can pass this array around so each can know which
blocks need to be updated before they are used or transmited in responce
to a request.




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