Re: Developing PLATOTerm64, Flow Control woes.

From: Mike Stein <mhs.stein_at_gmail.com>
Date: Fri, 6 Jul 2018 15:56:23 -0400
Message-ID: <78B2180A4231496B97F85EE0017EB1C2@310e2>
----- Original Message ----- 
From: "smf" <smf@null.net>
To: <cbm-hackers@musoftware.de>
Sent: Thursday, July 05, 2018 3:10 AM
Subject: Re: Developing PLATOTerm64, Flow Control woes.

> I think you misunderstand what I mean by end to end xon/xoff.
-
Perhaps. I take it to mean that if I send an XOFF then the other end receives an XOFF, whether it is actually sent as a character in the data stream or regenerated locally; I assume you mean the latter.
---
> If you want to use end to end xon/xoff then the bridge wouldn't need to advertise it because all they would do is pass through the xon/xoff like any other character. Instead xon/xoff is handled locally, like rts/cts is.
-
If you really need to send the characters to the other end then as I said before most bridges have an 'XON/XOFF with pass-through' option. 

Maybe it'd help if you read the docs for a typical bridge, especially the configuration options for XON/XOFF with pass-through, send XOFF immediately, packet size, high/low water marks etc.

Either you had a bad experience with software flow control in your youth or you just like to argue, but I obviously can't persuade you that *properly configured*, XON/XOFF 'just works' over a network,  the only real issue usually being the receive buffer size vs. the packet size as I said in my original post.

That's about all I've got to say.

Re the OP's question(s): sounds like his issue didn't really get solved very well if he ended up just throttling the data instead of any real flow control.

m
Received on 2018-07-06 22:00:05

Archive generated by hypermail 2.2.0.