Re: Developing PLATOTerm64, Flow Control woes.

From: smf <smf_at_null.net>
Date: Tue, 3 Jul 2018 14:17:18 +0100
Message-ID: <32101cf2-4ec3-f2cf-49e7-8d9811014a2d@null.net>
On 02/07/2018 18:47, Mike Stein wrote:

> I'm a little confused and don't quite understand what you're saying:
>
> "The problem is large transmit fifo's "... "If you also have a large dumb transmit fifo"..."
>
> Did you mean 'receive'?

No, if I've already queued 16 bytes to send to you and the transmit fifo 
is dumb then I can't send an xoff until you've received the other 16 
bytes. You therefore may need to start sending xoff 16 bytes earlier 
than you otherwise would.

The receive fifo's are only a problem if you're not reading from them, 
which you should do even if you're going to discard the data because 
your buffers are full.

> The bottom line IMO is that if it's available then RTS handshaking is the way to go; if not, and you can live with the 'no binary' restriction then end-to-end XON/XOFF flow control can work just fine over the internet
End to end xon/xoff will never be reliable over the internet. Both 
RTS/CTS and Xon/Xoff are local handshaking. The internet can deal with 
it's own flow control.
> With properly configured hard- and soft-ware, effective flow control is quite possible. Most of these devices are intended to transparently replace an RS-232 connection, so if it works over copper wire it should work just as well over USB, Ethernet, WiFi, whatever.

Depends on the latency, buffers and any packet drops. If the other end 
has 1k sitting in an output buffer waiting for a missing ack to restart 
sending, then any xoff you send will not help with data loss.

You might get lucky, but it won't be working properly in all circumstances.
Received on 2018-07-03 16:00:06

Archive generated by hypermail 2.2.0.