Re: [colorforth] bulk transfer protocol

[Mark Slicker <maslicke@xxxxxxxxxxx>]

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.


> "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.

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