Re: Developing PLATOTerm64, Flow Control woes.

I currently have the following code running in production right now, acting
as a forwarding proxy, with some throttling, which will buy me some time,
while I try to figure out how to implement handshaking for these different
devices.

https://gist.github.com/tschak909/a4d5ca88454c1996bcf31a3e06df348d

Pretty much, it seems up2400 is next to useless, as it doesn't implement
any RTS/CTS handshaking, and XON/XOFF doesn't get processed fast enough...

UP9600 has handshaking, but am having difficulty grafting this into a
framework for CC65's serial kernel.

Swiftlink-232 cartridges don't seem to have much of a problem, except at
higher data rates, but need to implement RTS/CTS to stop the damned cart.

And IP65 has its own problems, where it simply doesn't resize the TCP
send/receive window, making any sort of flow control meaningless at present.

sigh.

-Thom

On Sat, Jul 7, 2018 at 8:40 PM Mike Stein <mhs.stein@gmail.com> wrote:

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