Re: Developing PLATOTerm64, Flow Control woes.

> The other end may be using RTS/CTS, or not even be connected via RS232 and so it would be extra work to cope with the XON/XOFF.
--
We may be talking about different scenarios; I assumed that we had control over the protocols used at both ends and could configure them however necessary in order to let two RS-232 devices, at least one of which could *only* use XON/XOFF flow control, communicate over a LAN or WAN.

There are certainly fewer problems when the bridges at both ends are identical and designed to work with each other.

And as I said, *if* hardware flow control is available, that's the way to go for several reasons.

m

----- Original Message ----- 
From: "smf" <smf@null.net>
To: <cbm-hackers@musoftware.de>
Sent: Wednesday, July 04, 2018 5:23 PM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


> On 04/07/2018 21:01, Mike Stein wrote:
>> But there's no reason why it can't send the XON/XOFF back to the sending system to tell it to pause after the next packet *as well as* using it for local handshaking with small enough frames to prevent overflow of the receiving RS232 device.
> 
> The other end may be using RTS/CTS, or not even be connected via RS232 
> and so it would be extra work to cope with the XON/XOFF.
> 
> With the extra effort you don't gain any benefit at all.
> 
> If the other end is using XON/XOFF between it and it's bridge, then your 
> XON/XOFF being sent throug are either benign or dangerous.
> 
>> The vendors of these devices promise that XON/XOFF works,
> 
> Right, if you configure it to use XON/XOFF locally and that filters it out.
> 
> As for whether they lie, at least some of them did. I used a lot of them 
> in the 90's. One of them couldn't cope with sending two 0xff characters 
> after each other, only one turned up. We had to change the protocol so 
> that this couldn't happen.
> 
>> ..." 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. "
> Unless your UART supports XON/XOFF itself, or has some way of inserting 
> characters at the head of the FIFO then it's always going to go at the 
> end of the queue. It's just more latency because XON/XOFF is in band.
>> Anyway, is any of this relevant to the OP's flow control issues?
> 
> Difficult to say for sure, because he was light on the details on his 
> hardware so I've had to make some assumptions. Then made assumptions 
> about what kind of problems I've seen when people use XON/XOFF 
> incorrectly which could explain it.
> 
> 
>