En dum protokol
Jeg sidder og kigger på en leverandørs protokolbeskrivelse. Hvem og hvad er sådan set ligegyldigt men vi vil nok alle sammen sætte pris på at det er lavet ordentligt i dette tilfælde.
Protokollen er langt fra det værste jeg har set og den har en vis indre elegance der sikkert betyder at ophavsmanden har følt sig rigtigt smart da han var færdig.
Men som protokol set er det noget makværk, f.eks bruger den en simpel byte-sum som integritetscheck af data bytes, hvilket er galt nok, men der er slet ikke noget check på adressen og længden.
Det har allerede krævet et slagsmål i det hele taget at få leverandøren til at udlevere protokollen, de ville naturligvis meget hellere sælge deres eget overvågningsudstyr (en PC der kan pibe og vise røde felter på skærmen) men kunden har overhovedet ikke brug for at have den slags underlige maskiner stående for man har allerede investeret stort i integreret overvågning.
Så hvis de ville sælge så måtte de udlevere protokollen. Sådan skal det være.
Nu forventer nogle af jer nok et brok om åbne data formater og det kunne på sin vis også være på sin plads, men det gemmer jeg lige til senere.
Protokol historie
Tilbage i tresserne, det vil sige for rundt regnet 40 år siden, havde IBM en protokol der hed Binary Synchronous Communications, oftest blot BiSync eller BSC. Den blev brugt til at sende data imellem mainframes.
BSC protokollen brugte oprindeligt en byte-sum som checksum og det var utilstrækkeligt opdagede man. Der er simpelthen for mange ting den ikke opdager, indsatte nul-bytes f.eks. Derfor skiftede man til CRC-16 integritetscheck.
I begyndelsen af halvfjerdserne sendte IBM Systems Network Architecture på markedet og brugte nu SDLC fordi det virkede bedre end BSC.
I firserne blev SDLC standardiseret som HDLC og forbandt alverdens teleselskaber med X.25, X.75 og SS7.
I halvfemserne blev HDLC adopteret til PPP og blev brugt til vores alle sammens dial-up internet forbindelser.
For dem af jer der startede i bulletin board verdenen kan jeg nævne at man ikke har brugt byte check sum siden den originale XMODEM protokol. Chuck Forsberg fandt på XMODEM-1K protokollen i 1980 og den og alt senere har brugt CRC koder som fejl check.
Hvordan kunne han gøre det ?
Protokollen jeg sidder med er fra slutningen af halvfemserne og at en formodentlig kompetent udvikler kunne finde på at hjemmestrikke en protokol på det tidspunkt, når der findes en så gennemanalyseret og velfungerende protokol som HDLC er mig desværre ikke en gåde.
Det kan ikke have været uvidenhed. Hvis man i 1998 ikke havde hørt om PPP eller HDLC så burde man ikke kunne få lov til at komme nær et RS-232 interface.
Det kan heller ikke have været deadline problemer, for PPP standarden er fra 1994 og indeholder endda kildetekst der er lige til at sakse.
I bedste fald skyldes kundens problemer med at få protokollen udleveret at leverandøren skammede sig over den.
Mere sandsynligt er at leverandøren anser det for en salgsmæssig fordel at have sin egen hemmelige protokol.
Mest sandsynligt er desværre at en og anden programmør var ramt af "Not Invented Here Syndrome" og derfor ikke kunne få sit ego overtalt til at genbruge HDLC protokollen.
Herregud, der sker jo nok ikke noget...
Lige nøjargtigt i det her tilfælde sker der nok ikke nogen ulykker fordi protokollen er noget makværk. Udstyret har så mange indbyggede fejlcheck og de professionelle brugere er så meget på vagt at selv hvis der skulle ske noget underligt kommer der næppe kvæg på isen.
Men alligevel, når man tænker på hvor tit problemer og ulykker skyldes "computerproblemer" som man aldrig nogensinde kommer til bunds i, burde vi så ikke som programmører holde op med at opfinde vores egen varme tallerken og dybe vand hele tiden ?
Inden nogen af læserne siger noget om at vi er blevet meget klogere siden 1998 og at den slags slet ikke sker mere, så overvej lige at vi endnu ikke har hørt hvad problemet er med computerne i IC4 toget...
/phk
