Met stijgende verwondering, uitmondend in afgrijzen, heb ik de column ‘Asynchroon versus synchroon’ van Martin Healy in Computable van 15 september gelezen. De titel riep associaties op met discussies uit het begin van mijn ICT-carrière, toen IBM en DEC de twee grote spelers waren, laat Herman Kempers verontwaardigd weten.
IBM stond gelijk met ‘synchrone wereld’ en Digital met de ‘asynchrone wereld’. De reden hiervoor was een puur technische. Voor een terminalsessie in de synchrone wereld werd op datalink/fysiek-niveau een verbindingssessie opgezet, die ook onderhouden werd indien er geen sprake was van reële datacommunicatie. Door middel van ‘polling’ werd de lijnverbinding in stand gehouden totdat de terminal/host de verbinding verbrak. Dit basisprincipe is een van de fundamentele eigenschappen die SNA niet routeerbaar maakt. Digital maakte gebruik van een datacommunicatiesysteem dat, indien er aan de terminal- en/of host-zijde data te versturen was er op datalink/fysiek-niveau opnieuw een verbinding werd opgebouwd. Indien beide niets te vertellen hadden, werd de sessie beëindigd.
Asynchroon of ‘verbindingsloos’
De refererentie aan zijn elektronica- en communicatie-achtergrond bevestigde mij in de veronderstelling dat de heer Healey bovenstaande discussie weer zou aanhalen. Dan staat er te lezen dat een asynchroon systeem ook wel ‘verbindingsloos’ systeem genoemd wordt. Asynchrone communicatie heeft echter wel degelijk een verbinding nodig tussen de partijen. Vervolgens wordt aan asynchrone communicatie ook nog de eigenschap toegekend, dat het data kan blijven sturen zonder dat de communicatiepartner actief is. Reken er maar niet op dat je op een asynchrone DEC-terminal een sessie met een VAX kon opzetten als die VAX niet bereikbaar of uitgezet was. Als de heer Healey vervolgens stelt dat er dan ook een store and forward-techniek toegepast moet worden, vraag ik me echt af waar we het over hebben.
E-mailberichten zullen op weg naar de ontvanger regelmatig over synchrone lijnverbindingen gestuurd worden. Met dit soort verbindingen worden de wan-interfaces van routers met elkaar verbonden en vaak moet een e-mailtje toch wel één of meer routers passeren.
Vervolgens wordt er een redenering opgezet waarbij er dusdanig allerlei zaken gerelateerd worden aan ‘sync/async’ dat zelfs XML er onderdeel van moet gaan uitmaken. SNA was het protocol voor robuuste transactiegeoriënteerde communicatie vanwege ondersteuning van synchrone en asynchrone concepten. Eh…, SNA is een typisch geval van synchrone communicatie. Willen we dat asynchroon versturen, moeten we de SNA-pakketten in een voor asynchrone communicatie geschikt protocol verpakken, zoals TCP/IP. Via een SNA-server wordt dit weer uitgepakt en vervolgens via synchrone communicatie aangeboden aan een S390 of iets dergelijks. Vanaf dat moment praten we dan weer over SNA-verkeer. En dit is slechts één van de manieren om SNA-data asynchroon te versturen, maar er moet altijd aan gesleuteld worden.
SNA, TCP en UDP
Een tweede reden om SNA te gebruiken was de robuustheid, foutherstel, beveiliging en performance. Een paar alinea’s eerder werd gesteld dat asynchrone systemen gebruikt werden juist daar waar een sterke nadruk op betrouwbaarheid van transacties werd gelegd. Als dan ook nog eens TCP als de synchrone poot en UDP als asynchrone poot van het TCP/IP protocol voorgesteld worden, weet ik zeker dat ik geen gedachtekronkel heb, maar dat meneer Healey gewoon echt niet weet waar hij het over heeft.
TCP is een reliable connection-oriënted protocol, hetgeen inhoudt, dat er inderdaad een sessie tussen beide partijen opgebouwd wordt waarbinnen de integriteit van de te communiceren data bewaakt wordt. UDP daarentegen is een connectionless protocol, hetgeen inhoudt dat er geen sessie tussen twee communicerende partners opgebouwd wordt. UDP wordt dan ook voornamelijk in broadcast-systemen gebruikt. TCP is ten enenmale ongeschikt om concurrent sessies op te bouwen met een onbekend aantal partners. Kennis van het aloude OSI-model van zeven lagen en basale protocol-kennis zijn voldoende om na lezing van deze column te concluderen: Hij heeft de klok horen luiden, maar heeft de klepel nog niet gevonden.
Misschien is er nog een andere mogelijkheid: de heer Healey is ongetwijfeld Engelstalig en heeft z’n column in het engels geschreven. Engelse computertermen krijgen vaak een vreemde Nederlandse vertaling. Bijvoorbeeld ‘regelomhaaltoets’ voor Enter, waarbij in het engels de functie ‘voer uit’ wel in het woord besloten ligt en in de Nederlandse vertaling niet. Maar ook met dat in het achterhoofd maak ik er met geen mogelijkheid een logisch en juist verhaal van en blijf ik bij mijn verbastering van het spreekwoord over de klok en de klepel.
Herman Kempers
Senior Netwerk-Architect
Centennium Detachering
