On Tue, 16 Aug 2022 17:46:59 +0200, Krzysztof Halasa wrote:
> "J.F." <j...@p...onet.pl> writes:
>>> Natomiast mam wrażenie (być może mylne), że (w odróżnieniu od typowych
>>> Rockwelli) at&f oznaczało tam xon/xoff, i dopiero at&f1 było "normalne".
>>> Ale to było dawno, to tylko wrażenie.
>>
>> Moze w AT&T xon/xoff jest "normalny" :-)
>
> No wiesz, pierwsze modemy nie robiły żadnego buforowania, ale xon/xoff
> (^Q/^S i/lub scroll lock) służyły tam do wznowienia i zatrzymania
> przewijania ekranu - a wcześniej drukowania. Więc to _był_ normalny
> mechanizm. BTW ten mechanizm cały czas jest obecny np. w xtermie.

No wlasnie ... wiec powinien byc przeniesiony do nowoczesnych modemow?

>> Bo IMO - sam RS-232 nie ma nic do sterowania przeplywem.
>> Tzn nic przewidzianego.
>
> Oczywiście że RS-232 ma przewidziane "coś" do sterowania przepływem.
> Nawet wersja z 1960 roku (2.1.6 Clear-to-Send Circuit).
> Inną sprawą jest to, że wtedy to było używane z łączami half-duplex.

No wlasnie - do half duplexu. Modem ma powiadomic kiedy jest gotow
do nadawania ... i jakos nie napisali, ze moze przerwac swoją
gotowosc.

Choc juz w wersji 1988
https://www.itu.int/rec/T-REC-V.24/en

pojawil sie flow control przy pomocy tej linii.

Wczesniejsze wersje to chyba w bibliotece, ale
-stary modem w zasadzie nie ma po co przerywac transmisji,
dopiero przy kompresji sie pojawila potrzeba,

-w starych protokolach łacznosci modem-modem druga strona nie miala
jak zasygnalizowac niegotowosci. Nie bylo przewidziane.
Dopiero chyba gdzies przy korekcji błędow mogło sie cos pojawic.

-ale jak mialby drugi DTE powiadomic, ze chce przerwy?
sygnal DTR do czego innego sluzy.

J.