Re: Developing PLATOTerm64, Flow Control woes.

Whatever; I think we have a difference of opinion about who's the troll.

I must admit that I accidentally typed 'latter' instead of 'former' below; I corrected it but somehow the original was sent.

Other than that the kindest thing I can say is that I'm talking about specific scenarios whereas you seem to be talking about general commercial viability. 

e.g.
>> ...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....

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

Right; if that's the case then obviously I wouldn't configure this end to pass on XON/XOFF. It *can* pass it through; that doesn't mean it should if it makes no sense.

> If the other end is using XON/XOFF between it and it's (sic) bridge, then your XON/XOFF being sent throug are either benign or dangerous.

Right; again, "if...," then obviously I wouldn't needlessly send an XON/XOFF.

...And other 'yeah, but what if...' irrelevant scenarios...

That's what I consider 'trolling'...

> ...if you configure it to use XON/XOFF locally and that filters it out.

Once more: it is not either/or. You can use XON/XOFF locally and *not* filter it out, for the rare scenario where this is appropriate; that's the purpose of pass-through.

When I say 'properly configured' I thought it would be obvious that I mean configured to match the particular scenario in question.

Obviously your definition of 'end to end XON/XOFF' specifically means transparently sending the characters along with the data *without* any local handshaking at either end, as opposed to one end dropping RTS (for example) and the other end receiving an XOFF.

Running your version of 'end to end' without any local handshaking would certainly require fairly large receive buffers; I would suggest that packet size is actually crucially relevant, especially when you want to send an immediate XOFF and have to flush the transmit buffer first.

You think I'm trolling, I think you are. You define end to end XON/XOFF flow control as meaning 'no local handshaking' and not feasible over a network, I define it differently but even accepting your definition I believe it's feasible *if necessary*, with some caveats.

The bottom line is that most ethernet (and USB)  'bridges' can usually be configured to match any given situation, but it ain't always easy or straightforward; loosely defined terminology also doesn't help.

Can we finally leave it at that and let any readers still following this thread draw their own conclusions (I mean about the thread; I have a good idea what they've already concluded about you and me ;-)

m

----- Original Message ----- 
From: "smf" <smf@null.net>
To: <cbm-hackers@musoftware.de>
Sent: Saturday, July 07, 2018 6:49 PM
Subject: Re: Developing PLATOTerm64, Flow Control woes.


> On 06/07/2018 20:56, Mike Stein wrote:
>>
>> 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.
> 
> End to end flow control would be that you would send an xoff character, 
> the bridge would pass it through without acting on it, the receiving 
> bridge would pass it to the rs232 device on the other end, which would 
> then stop sending data, but any data already sent will be delivered.
> 
> If on the other hand the xoff stops your local bridge from sending data 
> to you, then it's not end to end. Instead it's local.
> 
> I've explained this multiple times, so I don't understand why you would 
> assume the opposite of what I meant. It seems like a troll.
> 
>> Either you had a bad experience with software flow control in your youth or you just like to argue,
> 
> I disageed that whether you are being sent packets or single characters 
> is irrelevant because the flow control should happen at a higher level & 
> then you seemed to start misunderstanding and disagreeing with 
> everything I said out of principle.
> 
>>   but I obviously can't persuade you that *properly configured*, XON/XOFF 'just works' over a network,
> I've not been discussing properly configured XOFF/XON, I've used it 
> enough to know what works and what doesn't. The whole point of this 
> thread was to point out improperly configured XOFF/XON to help the OP 
> with his problem.
>>    the only real issue usually being the receive buffer size vs. the packet size as I said in my original post.
> 
> Send fifo depth, receive buffer size, the threshold and the latency 
> between queuing an xoff and the data stopping are the only relevant 
> things. Packet size shouldn't affect it at all.
> 
> The only way for the latency to be low enough is if the local bridge 
> processes it and stops sending you data until you send it an xon.
> 
>> 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.
> 
> Right, which is why I was suggesting things that could have caused his 
> original problem. But you started saying that it would still work if 
> misconfigured the way I was describing.
> 
> 
>