Re: Developing PLATOTerm64, Flow Control woes.

> In my experience you have to configure the bridge to do xon/xoff and then it's just a local flow control, the characters are filtered out and not sent over the internet.
--------
Yes indeed; if you're going to use XON/XOFF then you have to configure the bridge to do XON/XOFF.

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 vendors of these devices promise that XON/XOFF works, experience says that it works, and that's good enough for me; otherwise systems that use RS-232 and only XON/XOFF would not be able to communicate over the network.

 But I still don't understand this scenario of yours:
..." 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. "

Anyway, is any of this relevant to the OP's flow control issues?

m

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


> On 04/07/2018 04:34, Mike Stein wrote:
>> If you say so; presumably the folks who have replaced RS-232 connections with Ethernet are liars, as are the companies that sell 'bridges' to replace both direct RS-232 and modem connections and advertise that no software changes will be necessary and XON/XOFF flow control is an option.
> 
> In my experience you have to configure the bridge to do xon/xoff and 
> then it's just a local flow control, the characters are filtered out and 
> not sent over the internet. When you send an xoff to the bridge it will 
> stop reading from the tcp buffer on the bridge and it will become full 
> so it will stop acking packets, the transmit buffers on the other 
> computer will fill up and it will then pause. RTS/CTS flow control is 
> handled in the same way.
> 
> If instead you have two bridges passing the xon/xoff through and you 
> expect a computer on the other end of the world to stop sending in time, 
> then it's not going to have the expected result.
> 
>> I'd say the receive FIFOs can indeed be the problem; if you're 
>> allowing the buffer to fill and are discarding data then I'd say 
>> you're not controlling the flow of data very effectively. Why on earth 
>> would I not read the data in the Rx FIFO, especially if it generates 
>> an interrupt?
> 
> I've seen people have the bright idea of when their buffers are full 
> because a resource they need to write to is unavailable, they will let 
> the RX FIFO fill up on the off chance that the resource will become 
> available allowing their buffer to clear before the RX fifo overflows. 
> Instead you have to pull the data out of the RX FIFO as soon as you can 
> and discard it if your buffer is full, because it might be an xoff/xon 
> which doesn't need to go into the buffer anyway.
> 
> 
>