    Van:   Ries Vriend
    Aan:   Ramon van der Winkel
    Datum: 24 Juni 1991
    ======

    Betreft:  Reaktie op Concept definitie Modem drivers en Data 
	      communicatie Protocollen, 29 juni? 1991, door Ramon 
	      van der Winkel.


    Ik heb onder ieder kopje alleen mijn eigen opmerkingen gezet. 
    Zie de lijst DRIVERS.TXT van Ramon voor de origele inhoud van 
    iedere paragraaf.


    1)	Nummer bellen

    Een nul-string in plaats van een uitroepteken lijkt me meer voor 
    de hand liggen.


    3) Verbindingsstatus

    Het lijkt me beter om hier twee aparte functies van te maken. Er 
    moet worden voorkomen dat functies `overbodige' handelingen 
    uitvoeren. Dus wanneer je de verbindingsstatus wilt weten, moet 
    je niet ook nog eens de actieve snelheid terug krijgen.

    Dezelfde fout hebben we ook gemaakt bij MemMan: Als je de 
    `connected status' opvraagt, wordt ook het aantal vrije segmen 
    ten bepaald. Dit kost alleen maar extra tijd en heeft geen nut.

    Dus: Voor alle soorten info een aparte functie maken.

    Het is misschien mogelijk om de connected status aan te geven in 
    een byte op de heap. Tijdens de initialisatie kan het toepassin 
    gsprogramma het adres van het vlag-byte van iedere telefoonlijn 
    opvragen. Tijdens het draaien van de BBS kan dit status-byte 
    snel uitgelezen worden - er hoeft dan niet steeds een `trage' 
    TsrCall gedaan te worden.


    4) Teken versturen

    Bij een multi-lijns BBS lijkt het me voor de hand liggen om de 
    gegevens via de interrupt te verzenden. De driver kan via de 
    connected-status (een vlaggetje op de heap) aangeven of de gege 
    vens allemaal correct verzonden zijn.
    Het communicatieprogramma heeft dan zijn handen vrij om de bin 
    nenkomende en uitgaande tekens van de overige lijnen te verwer 
    ken.


    5) Ontvangen teken ophalen

    Er moet even goed bekeken worden hoe de foutvlaggen doorgegeven 
    worden. Als het bepalen van zaken als een verbroken verbinding 
    snel kan plaatsvinden, is het makkelijk om deze functie altijd 
    een foutvlag terug te laten geven. Als zoiets - bij een bepaald 
    modem - echter moeilijk te bepalen is is een aparte functie 
    misschien beter. Dit lijkt me trouwens onwaarschijnlijk, zo'n 
    modem zal waarschijnlijk altijd in de "alles Ok" stand staan.


    6) Aantal tekens vrij in het verzend buffer opvragen

    Ook deze info kan vrij eenvoudig op de heap geplaatst worden. De 
    driver hoeft alleen maar een tellertje te verlagen als er een 
    teken verzonden wordt.


    7) Aantal tekens aanwezig in het ontvangst buffer opvragen

    Deze routine heeft wel degelijk nut. De drivers van het NMS 1250 
    modem gebruiken hem na de ontvangst van een teken. Als de buffer 
    bijna vol blijkt te zitten wordt er een XOFF verstuurd. Dit om 
    te voorkomen dat de buffer overstroomt als hij een tijdje niet 
    geleegd wordt.


    9) Blok tekens ontvangen

    Stel dat je een datablok van 1024 bytes verwacht, bijvoorbeeld 
    tijdens een download. Je krijgt dan een probleem als door een 
    storing op de lijn er maar 1023 tekens binnen komen. Het commu 
    nicatie programma blijft dan eeuwig wachten op dat laatste byte.

    Ook hier zou een status-byte op de heap handig kunnen zijn. Het 
    protocol kan dan een time-out vlaggetje zetten als er een 
    bepaalde maximumtijd verstreken is, sinds de ontvangst van het 
    laatste byte.

    Dan even wat anders:

    Een multi-lijns BBS moet een lijst bijhouden van de momentele 
    status van iedere lijn. Bij iedere status hoort een bepaalde 
    "check-list". Nadat die check-list is doorlopen gaat de lijn 
    eventueel over op een andere status.

    Het BBS-programma is in een feite een eindeloze lus, waarin n 
    voor n alle lijnen afgehandeld worden.

    Voorbeeld van de status-lijst van een 3-lijns BBS:

    - Lijn 1
      Status:	 Download - "verzend 128 byte datablok".
      Checklist: Test "time-out" en "blok verzonden"
		 Indien blok verzonden is, overgaan op de status 
		 "wacht op ontvangst bevestiging". Indien "time-out" 
		 overgaan naar "command-mode".
		 Indien geen van beide: Niets doen.

    - Lijn 2
      Status:	 Command mode.
      Checklist: Scan keyboard en echo ontvangen teken(s).
		 Kijk of return ontvangen is en decodeer commando. 
		 Ga vervolgens over naar de status die bij het 
		 betreffende commando hoort.

    - Lijn 3
      Status:	 Niet bezet.
      Checklist: Luister of de bel rinkelt. Indien ja: Overgaan op 
		 "verstuur login-tekst".
		 Indien geen beller: Niets doen.

    Een check-list is dus niets anders dan een bepaalde subroutine. 
    Eventeel kan je van iedere check-list een apart programma maken. 
    Niet erg snel waarschijnlijk, maar zo'n modelaire opbouw pro 
    grammeert wel lekker.


    10) Buffer leeg maken

    Ook hier: Gebruik aparte functies - of verschillende invoerpara 
    meters - om te bepalen welke buffer je leeg wilt hebben.


    PROTOCOLLEN
    ===========

    1) Verzend een file / meerdere files (batch transmission)

    Ik denk dat je er niet zo makkelijk vanuit kunt gaan dat je een 
    complete file `intern' door je protocol-TSR kunt laten verzen 
    den. Onder Basic gaat dat nog wel, maar onder DOS krijg je waar 
    schijnlijk slot-, interrupt- en andere problemen. Onder DOS2 is 
    het bijvoorbeeld onmogelijk om vanuit een interrupt routine iets 
    van disk te laden.

    Het is misschien beter om een soort vraag- en antwoordspelletje 
    te spelen tussen het toepassingsprogramma en het protocol. Zo'n 
    gesprek loopt dan via TsrCall's en status-vlaggen.

    Een voorbeeldje van een converstatie tussen een BBS programma en 
    een XMODEM protocol:

    BBS> Ik wil de file "A:\BBS\WELCOME.TXT" versturen.
    XM > Prima! Ik heb het initialisatieblok verstuurd. Ik wil graag 
	 de eerste 128 bytes in mijn verzendbuffer.
    BBS> Hier heb je ze.
    XM > Blok verstuurd. Ik wil nog een blok
    BBS> Alstublieft, nog n
    XM > Blok verstuurd. Ik wil nog een blok
    BBS> Er is niet meer.
    XM > File perfect verzonden.

    Wanneer je dit concept in een aantal standaard functieaanroepen 
    weet te definieren, zou je het voor ieder willekeurig protocol 
    moeten kunnen gebruiken.
    Voordeel van deze aanpak is dat de BBS zelf de disk-handelingen 
    verricht. Dat is ook van belang voor de overige lijnen, want 
    tijdens het lezen en beschrijven van floppy staan de interrupts 
    behoorlijk lang uit. Doordat het BBS programma precies weet waar 
    iedere lijn mee bezig is, kan hij bijvoorbeeld even wachten met 
    de floppy totdat een datablok van een andere lijn binnen gekomen 
    is - of een XOFF sturen. Dit om te voorkomen dat er tekens 
    gemist worden omdat de interrupts te lang uit blijven staan.
     

    3) Status

    RWI> Misschien dat er een aparte status funktie voor het ontvan 
	 gen en zenden moet komen.

    Dat lijkt me ook. Mijn ideen over de statusbytes op de heap heb 
    ik hierboven al uitgebreid opgeschreven.


    Succes ermee,

		Ries.
                                                                                                                 