Masterproef Automatic update and inventory application

Transcriptie

1

2 Masterproef Automatic update and inventory application Studiegebied Industriële wetenschappen en technologie Opleiding Master in de industriële wetenschappen: Elektronica-ICT Afstudeerrichting Informatie- en communicatietechnieken Academiejaar Frederick Grumieaux Howest departement Academische bachelor- en Masteropleidingen, Graaf Karel de Goedelaan 5, 8500 Kortrijk

3 I

4 WOORD VOORAF Toen we eind vorig jaar een thesis moesten uitkiezen, ging mijn persoonlijke voorkeur zeer sterk uit naar dit project. Hoewel er nog enkele andere interessante items waren zoals een sturing voor een mini onderzeeër, waren er maar weinig onderwerpen die mij zo zeer konden aanspreken door enkel maar hun beschrijving. Ik was dan ook erg tevreden toen ik een kleine week na de sollicitatie te horen kreeg dat ik deze materie mocht uitdiepen. Gezien de oprechte interesse voor de taak ben ik dan ook snel begonnen met verschillende pistes te onderzoeken om de thesis tot een goed einde te brengen. Hoewel ik al ruime ervaring had met.net, was het gedeelte rond de netwerk interfacing een nieuwe uitdaging. Ik hoop dan ook dat dit werk een hulp kan zijn voor anderen die met dezelfde uitdaging te kampen hebben en dat het lezen ervan leerrijk en aangenaam is. Ondanks mijn inzet moet het toch gezegd zijn dat deze thesis nooit zou kunnen slagen zonder de hulp van vele andere personen. Hoewel het niet mogelijk is om iedereen die heeft bijgedragen aan dit werk persoonlijk te vermelden, wil ik toch enkele mensen speciaal in de bloemetjes zetten: Mijn ouders voor hun steun bij het schrijven van de masterproef, de werknemers bij Psi Control en in het bijzonder J. Coulembier voor de aangename sfeer en de hulpvaardigheid die zij getoond hebben. Ook de heer F. De Pauw verdient een woord van dank voor de professionele begeleiding van dit eindwerk en ten slotte wil ik ook F. Lescouhier bedanken voor de initiatie tot het netwerk programmeren, welke uiteindelijk aan de basis van deze thesis ligt. II

5 ABSTRACT How to deal with the practical implementation of a client server application? The aim is to transfer files and folders over a private network. The purpose of the application is to automate the update process of Psi Control s test framework. The program is developed in C# and uses the System.Net.Sockets.TcpClient - class as main part of the network engine. This scription is divided into two parts, a first part covers the theoretical background such as the problems, chosen solutions, alternatives etcetera. The second part of the paper takes care of the practical implementation with some code and more information about the purposes of the more important classes. Even though the main purpose of the application is to distribute updates, the emphasis of this document lays on the network connectivity since this is the utmost difficult part. The end result is a program that can communicate over the network using multiple data formats. It is also possible to use the network class library for other applications without significant changes in its design. III

6 INHOUDOPGAVE Woord vooraf Abstract Afkortingen Figuren Code Tabellen II III VIII IX IX IX H1 Inleiding Picanol Weaving solutions Mechatronics Manufacturing Doel Werkwijze 2 H2 Omschrijving van de opdracht Achtergrond Psi Control Wat is een PCB? Wat kan er misgaan met een pcb? Hoe kunnen fouten opgespoord worden? Hoe werkt Psi Control? Ontwikkelen van de tests De opdracht Bijkomende eisen Extras 5 H3 Probleemstelling formuleren Analyse van de opdracht Huidige situatie Toekomstige situatie Moeilijkheden Samenvatting 10 IV

7 H4 Algemeen Eén of twee programma s Functionaliteit Volledige lijst met functionaliteiten: Verantwoordelijkheden Gedeelde verantwoordelijkheden Verantwoordelijkheden van de server Verantwoordelijkheden van de cliënt Nomenclatuur Root directory Relatief pad Kanaal Gesprek Structuur van de server en de cliënt Server Cliënt Object Oriented Design. 16 H5 Serializing theoretisch Praktisch Keuze van de serializer besluit 19 H6 Authenticatie Implementatie Mogelijkheid Mogelijkheid Keuze en praktisch. 21 H7 Connectie methode OSI model De lagen in het OSI model Verklaring van de lagen TCP/IP Voordelen van de gelaagde aanpak TCP versus UDP Keuze protocol 26 V

8 H8 Implementatie Sockets NET Remoting WCF Webservices Besluit 30 H9 Communicatie protocol Hoofdcommando s Beschrijving van de hoofdcommando s 34 H10 Multi threading Wat is (multi ) threading? Waarom multithreading? Problemen met threading Gedeelde data Beperkte resources Wachten op einde van een andere thread Locks DeadLock AssyncCallback Threadpool 43 H11 Uitwerking Algemene structuur Korte verklaring van de modules Mapstructuur 46 H12 De netwerkmodule Algemeen blokschema Werking van de Netwerk module Algemeen Verklaring blokschema Berichten Base Message Private berichten Publieke berichten Server Cliënt Socket Ontvangen verzenden 68 VI

9 Channel Netwerk Properties Authentification Encryption Monitor 75 H13 Database module Waarom een database Voordelen van een database Structuur van de database Omschrijving van de tabellen Implementatie Connector De Time Manager 83 H14 Update Module Manager Interface Initialisatie Indexeren Updaten 85 H15 RDB Module Werking Communicatie Commando s Bijhorende argumenten Protocol 89 H16 Verbeteringen 92 Besluit 93 Bibliography 94 VII

10 AFKORTINGEN.NET dot NET framework AM Authentification Message AS Authentification Service ASMX Active Server Methods (also Microsoft fillename extension) C# C SHARP (programmeertaal ) DB DataBase DLL Dynamically Linked Library DUT Device Under Test FTP File Transfer Protocol HTTP HyperText Transfer Protocol IP Internet Protocol MITM Man In The Middle (attack ) MSMQ Microsoft Message Queue OO Object Oriented OOP Object Oriented Programming OSI Open Systems Interconnection PCB Printed Circuit Board PrK PRivate Key PuK PUblic Key RDB Remote DataBase SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocol SOC Service Oriented Computing SQL Structured Query Language TCP Transmission Control Protocol UDP User Datagram Protocol UUT Unit Under Test VPN Virtual Private Network VS Visual Studio WCF Windows Communication Foundation WSE Web Service Enchancements XML extensible Markup Language VIII

11 FIGUREN FIGUUR 1: VOORBEELD VAN EEN PCB... 3 FIGUUR 2: AFBEELDING TESTPLATFORM... 4 FIGUUR 3: TESTPLATFORM - HUIDIGE SITUATIE... 6 FIGUUR 4: TESTPLATFORM - TOEKOMSTIGE SITUATIE... 7 FIGUUR 5: SCHEMATISCHE VOORSTELLING VAN DE TESTSYSTEMEN... 9 FIGUUR 6: HET OSI MODEL FIGUUR 7: HET TCP-IP MODEL FIGUUR 8: WCF FIGUUR 9: APPLICATIE - ALGEMEEN BLOKSCHEMA FIGUUR 10: MAP STRUCTUUR FIGUUR 11: BLOKSCHEMA VAN DE NETWERK MODULE FIGUUR 12: NETWORK - DATA FLOWS FIGUUR 13: PRIVATE BERICHTEN FIGUUR 14: PUBLIEKE BERICHTEN FIGUUR 15: BLOKSCHEMA POLLEN FIGUUR 16: BLOKSCHEMA START SENDING PROCEDURE FIGUUR 17: BLOKSCHEMA SENDING PROCEDURE FIGUUR 18: DATABASE SERVER FIGUUR 19: DATABASE CLIENT CODE CODE 1: BESCHRIJVING VAN EEN COMMANDO CODE 2: VERZENDEN VAN EEN COMMANDO CODE 3: COMMANDO BERICHT, XML GESERIALIZEERD CODE 4: VERWERKEN VAN ONTVANGEN COMMANDOS CODE 5: IMPLEMENTATIE VAN DE HANDSHAKE KLASSE CODE 6: ICLSMESSAGE CODE 7: POLL FUNCTION CODE 8: FUNCTION RECEIVEMESSAGE CODE 9: FUNCTION GETBYTES CODE 10: FUNCTION RETRIEVEDATA CODE 11: FUNCTION SENDMESSAGE CODE 12: FUNCTION CREATEMESSAGEHEADER CODE 13: GET SQL SELECT QUERY CODE 14: GET UPDATE, INSERT OR DELETE SQL QUERY CODE 15: FUNCTION - GETTABLENAMES CODE 16: FUNCTION - GETCOLUMNAMES CODE 17: FUNCTION - UNIC SORTABLE DATE TIME CODE 18: PROTOCOL IMPLEMENTATION EXAMPLE - REQUEST SQL CODE 19: PROTOCTOL IMPLEMENTATION EXAMPLE - MESSAGE HANDLER CODE 20: PROTOCOL IMPLEMENTATION EXAMPLE - EXECUTE SQL IX

12 TABELLEN TABEL 1: HOOFD COMMANDO'S TABEL 2: START UPDATE - SUBCOMMANDO S TABEL 3: THEORIE OPDATE MODULE - STATUS BERICHTEN TABEL 4: RDB COMMANDO'S X

13 THEORETISCHE STUDIE H1 INLEIDING 1.1 PICANOL Picanol is een wereldspeler die tot de top behoort in de markt van bouw en ontwikkeling van weefmachines. Picanol is daarentegen veel diverser in zijn activiteiten dan algemeen bekend. De firma is opgericht in 1936, is sindsdien geëvolueerd van een traditionele weefmachine bouwer tot een wereldwijde leverancier van totaaloplossingen voor de textielindustrie en andere sectoren. De weefmachines van vandaag zijn een samenstelling van top technologieën op vlak van mechanica, elektronica, mechatronische aansturingen, gietstukken,.... Al deze technologieën worden ontwikkeld en gerealiseerd door de Picanol Group en vinden niet alleen toepassingen in de eigen weefmachines, maar worden ook verkocht aan klanten uit zeer uiteenlopende sectoren. De kerndivisies van de groep richten zich op de volgende doelmarkten: - Weaving solutions - Mechatronics - Manufacturing WEAVING SOLUTIONS Ondanks de diverse activiteiten, zijn weefmachines nog steeds een belangrijke tak van de onderneming. Picanol produceert en verkoopt weefmachines op basis van lucht- en grijpertechnologie, maar levert ook diensten zoals opleidingen, upgradekits, wisselstukken en service contracten MECHATRONICS Deze afdeling legt zich toe op de ontwikkeling, de productie en ondersteuning van technologische componenten, diensten en mechatronische systeemoplossingen. Het is in deze tak dat PsiControl werd op gestart. Psi Control ontwerpt en produceert printed circuit boards (PCB s), dit zowel voor intern gebruik als (sinds enkele jaren) ook voor externe firma s MANUFACTURING De Manufacturing afdeling omvat de gieterijactiviteiten (Proferro) en de mechanische afwerkingactiviteiten van de groep. De ambitie van Manufacturing ligt in het aanbieden aan de klanten van enginered casting solutions voor middelgrote series. 1

14 1.2 DOEL Het doel van deze thesis is het creëren van een applicatie die semi automatische updates kan uitvoeren. Hoewel deze opdracht vrij praktisch van aard is, komen er toch enkele interessante topics aan bod, zoals serializing en het implementeren van TCP- verbindingen via C#. Het is duidelijk dat de praktische aard van de masterproef geen afbreuk doet aan het nut van de opdracht dit zowel voor het bedrijf Psi Control, als voor andere bedrijven die eigen software ontwikkelen. Deze bedrijven hebben bij deze namelijk een document dat duidelijk de problemen en mogelijke oplossingen aanreikt om hun projecten vooruit te helpen. 1.3 WERKWIJZE De thesis bestaat hoofdzakelijk uit twee delen. Een eerste deel waarin de verschillende problemen worden besproken en een tweede deel waar de praktische uitwerking van de gekozen oplossing aan bod komt. Voor de duidelijkheid is het aangeraden dat de lezer eerst de opdracht omschrijving duidelijk leest alvorens de rest van de tekst te bestuderen. De reden hiervoor is dat sommige keuzes misschien niet altijd logisch lijken voor mensen die niet de specifieke eisen kennen die verbonden zijn aan de applicatie. Dit werk is zo opgesteld dat de lezer niet de volledige tekst hoeft te lezen om de verschillende onderdelen te kunnen begrijpen. Voor personen die meer geïnteresseerd zijn in de mogelijke problemen die optreden bij een dergelijk project is het eerste deel van de thesis het belangrijkst. Daar worden de verschillende problemen aangekaart samen met een of meerdere oplossingen. Voor personen die eerder de praktische kant, de uitwerking van het probleem willen bestuderen zijn dan eerder gebaat met het tweede deel van dit document. 2

15 H2 OMSCHRIJVING VAN DE OPDRACHT 2.1 ACHTERGROND PSI CONTROL Zoals in de inleiding te lezen valt, is Psi Control de afdeling van de Picanol Group waar PCB s gemaakt worden. PCB staat voor Printed Circuit Board en wordt ook wel printplaat genoemd. Psi Control vervaardigt niet alleen de printplaten zelf, maar bestukt deze ook WAT IS EEN PCB? Een PCB is een drager waarop elektronische componenten kunnen worden geplaatst. De drager zelf is van een niet geleidend materiaal en de componenten worden met elkaar verbonden door een geleidende verbinding die op de drager wordt geëtst of gedrukt WAT KAN ER MISGAAN MET EEN PCB? Wanneer printplaten worden gefabriceerd is het van groot belang dat deze worden getest voor deze zouden worden gebruikt in machines. Het is dus belangrijk om te weten wat er zoal kan misgaan en om dan een test systeem te ontwikkelen die deze problemen kan opsporen. Lijst met mogelijke fouten - Fout in het ontwerp (de lay-out). FIGUUR 1: VOORBEELD VAN EEN PCB - Geen verbinding tussen twee componenten waar er wel een hoort te zijn. - Een verbinding tussen twee componenten die er niet hoort te zijn. - Een slechte verbinding (te grote weerstand of capaciteit). - Een fout met een component. 3

16 2.1.4 HOE KUNNEN FOUTEN OPGESPOORD WORDEN? Na het produceren van een printplaat, moet deze individueel worden getest. Dit kan met verschillende technieken, of in het ideale geval door een combinatie van verschillende technieken. Een eerste mogelijkheid is een optische controle waarbij met speciale apparatuur foto s worden gemaakt van de printplaten om zo te zien of er slechte verbindingen zijn. Deze techniek is echter niet in staat om fouten in componenten of in het ontwerp te detecteren. Een tweede mogelijkheid is om de een test te ontwikkelen die effectief metingen uitvoert op de printplaat zelf. Dit kan bijvoorbeeld door met naalden contact te maken met de printbanen. Op deze manier is het mogelijk om signalen op de print te plaatsen en deze dan op een ander punt op te meten. Deze tweede manier van werken heeft als voordeel dat niet enkel verbindingsfouten, maar ook foutieve componenten en mogelijks zelfs ontwerpfouten kunnen worden opgespoord HOE WERKT PSI CONTROL? Bij Psi Control werd enkele jaren geleden een eigen testplatform ontwikkeld dat op het tweede principe (contact maken en resultaten opmeten) werkt. Psi Control heeft momenteel een 10 tal systemen draaiende in verschillende landen zoals België en Roemenië. FIGUUR 2: AFBEELDING TESTPLATFORM ONTWIKKELEN VAN DE TESTS Voor ieder type printplaat die ontwikkeld wordt in Psi Control moet nu ook een eigen test ontworpen worden. Dit houdt in dat er een bijkomende printplaat moet ontwikkeld worden waarop de pinnen staan en die tijdens het testen contact moet maken met het D.U.T. (Device Under Test ). Verder moet er ook bepaald worden welke signaal, op welk ogenblik, op welke pin, moet worden aangeboden aan de print en welke pin het resultaat moet opmeten. Om te kunnen bepalen of de test wel of niet geslaagd is, moet dan ook nog eens de uiterste grenzen worden opgegeven waarbinnen het resultaat als goed kan worden beschouwd. Deze beschrijving wordt vervolgens in een bestand opgeslagen en naar alle test platformen opgestuurd. Dat het ontwikkelen van zo een test geen sinecure is, is duidelijk. Dat er af en toe na ingebruikname van een test wordt vastgesteld dat een test niet 100% correct is hoeft dan ook geen verder verklaring. 4

17 2.2 DE OPDRACHT Uit de achtergrond beschouwing blijkt duidelijk dat er in Psi Control regelmatig nieuwe of verbeterde tests ontwikkeld worden. Nu is het zo dat deze tests in België worden ontwikkeld, dat er meerdere testplatformen zijn en dat en deze niet allemaal in België gelegen zijn. Toch moeten alle testplatformen telkens worden geüpdate zodat deze steeds werken met de laatste (meest correcte ) versie van de test. Het updaten van de test platformen gebeurt momenteel handmatig. Dit wil zeggen dat een nieuwe test sequens file via of een ander programma (FileZilla,...)verspreid wordt naar de verschillende productie plants en dat deze plants er dan voor moeten zorgen dat deze file op het test systeem terecht komt. Het spreekt voor zich dat dit voor problemen zorgt. Ten eerste is er de typische menselijke fout, waardoor het bestand op de verkeerde locatie terecht komt, of dat één van de testsystemen vergeten wordt. En ten tweede is er de kans dat de operator van het testsysteem gewoon weigert om de update uit te voeren, wegens te veel werk, tijd, te ingewikkeld. Een probleem dat zeker in Roemenië nog wel eens kan voorkomen. De opdracht is dan ook zeer eenvoudig, namelijk het automatiseren van deze taak (update) zodat de operator geen (of zeer weinig) moeite moet doen, er praktisch geen fouten kunnen gebeuren en dat de R&D afdeling vanuit België kan controleren of de update is uitgevoerd. 2.3 BIJKOMENDE EISEN 1) Ondanks het feit dat alles zo veel mogelijk moet worden geautomatiseerd, mag het programma (nog ) niet volledig autonoom draaien en moet in elke stap van het proces nog om toestemming worden gevraagd. Het programma mag bijvoorbeeld wel voorbereidende werken doen om door de nieuwe test bestanden te downloaden naar het update platform, maar mag de effectieve update maar uitvoeren na toestemming te hebben gekregen van de operator. 2) Het programma moet robuust zijn. Psi Control wil geen tijd verliezen door problemen met deze applicatie. Het is uiteraard een logische wens van een productie plant om de productie zo vlot mogelijk te laten verlopen, maar het is wel een wens die zwaar zal doorwegen op sommige beslissingen. Er moet ook rekening gehouden worden met het feit dat de verbinding tussen de verschillende afdelingen niet te vertrouwen is, deze valt van tijd tot tijd eens uit en werkt meestal redelijk traag. 3) Psi Control werkt nog steeds met Visual Studio De applicatie moet dan ook geschreven worden in vc2005 in de taal C#. 2.4 EXTRAS Tijdens het ontwerp van een update applicatie mag er gerust verder gekeken worden dan de strikt noodzakelijke functionaliteit. Daarom werden er enkele andere functies beschreven die zouden kunnen worden toegevoegd om de R&D afdeling te helpen. 1) De mogelijkheid om rechtstreeks te communiceren met het test platform. 2) De mogelijkheid om de databases van de testsystemen aan te spreken via het programma. 5

18 H3 PROBLEEMSTELLING FORMULEREN Alvorens er kan worden gewerkt aan een oplossing voor het probleem is het noodzakelijk om de opdracht te analyseren en indien mogelijk op te splitsen in kleinere deelproblemen. Op deze manier kan er een duidelijker beeld geschept worden over de inhoud van de opdracht. Verder helpt het ook bij het maken van een planning om vorderingen te kunnen plaatsen. Sommige van de hieronder gestelde problemen kunnen eerder doodgewone vragen lijken, dan een echt probleem. Er moet echter wel opgemerkt worden dat een ondoordachte keuze bij de start van het ontwerpproces, later tot onverwachte moeilijkheden kan leiden. Daarom is het belangrijk om eerst na te denken over de volledige structuur van het programma, voor er geprogrammeerd wordt. Dit wil niet zeggen dat er tijdens deze fase, geen kleine tests kunnen gebeuren om bepaalde zaken te onderzoeken. Verder blijft het nog steeds mogelijk om tijdens de implementatie licht af te wijken van bepaalde zaken indien zou blijken dat deze niet praktisch waren, of er verbeteringen mogelijk zijn. 3.1 ANALYSE VAN DE OPDRACHT HUIDIGE SITUATIE Momenteel ziet een testsysteem er (blokschematisch ) als volgt uit: FIGUUR 3: TESTPLATFORM - HUIDIGE SITUATIE Legende: Het grijze gebied stelt het volledige testplatform voor, de blauwe gebieden zijn de verschillende modules waaruit het testplatform bestaat. Het testsysteem is dus een computer waar een applicatie op draait en die verbonden is met specifieke hardware nodig om de tests uit te voeren. Bij iedere test scant de operator een barcode, waardoor het testplatform kan achterhalen welke test er uitgevoerd moet worden. Daarna haalt het testplatform deze test uit het geheugen. 6

19 De tests staan op een vaste locatie in het geheugen. Zo staan alle tests bijvoorbeeld in onder de map PsiTest. Eventueel is er nog een verdere onderverdeling per klant en per module. Uiteindelijk heeft ieder type print een eigen test bestand waarvan de naamgeving als volgt is: [Naam van de print (=type)] + spatie + [versie nummer]..tst Een voorbeeld ter verduidelijking: C:/.../PsiTest/Klant A/ModuleA/TypePrint v tst. Stel nu dat er een nieuwe versie van de test wordt ontwikkeld, dan zal deze de volgende naam krijgen: C:/.../PsiTest/Klant A/ModuleA/TypePrint v tst. Het testplatform is zelf in staat om de nieuwste versie te selecteren. En zal dus vanaf het ogenblik dat de nieuwe test in de juiste map geplaatst is, deze gebruiken TOEKOMSTIGE SITUATIE Zoals al aangehaald is het probleem de verspreiding van de test bestanden. Om dit te automatiseren, zal er een systeem moeten worden toegevoegd die in staat is om de bestanden op de juiste plaats te krijgen. Het uiteindelijke doel wordt afgebeeld op de volgende figuur: FIGUUR 4: TESTPLATFORM - TOEKOMSTIGE SITUATIE 7

20 Er wordt dus een extra programma geïnstalleerd op de computer dat in staat is om het bestandsysteem te ondervragen en indien nodig bestanden te uploaden van een centrale server. Op deze manier moet enkel de server onderhouden worden en moet er geen tijd meer worden besteed aan de afzonderlijke cliënts MOEILIJKHEDEN De opdracht luidt in zijn meest simpele vorm verstuur data via het internet van A naar B. Praktisch wil dit dan zeggen: maak een server en een cliënt, die met elkaar verbonden zijn via een internet connectie. Deze iets meer uitgebreide formulering doet reeds een aantal vragen reizen. De eerste vraag die gesteld moet worden is dus of er nu één of twee programma s moeten worden geschreven. Een tweede probleem is het internet. Het internet zorgt zelf voor meerdere problemen. Ten eerste wil dit zeggen de data die moet verstuurd worden over de applicatie grenzen zal gaan. Data die over de programmagrenzen heen gaat moet altijd serialiseerbaar zijn en er moet een gemeenschappelijke taal geformuleerd worden om te communiceren. Het tweede probleem met internet is dat er mogelijke beveiligingsrisico s ontstaan. Het is dus gewenst om de identiteit van alle partijen te controleren wanneer deze zich aanmelden bij de server. De vele veiligheidsproblemen met IT- systemen tonen aan dat dit niet zo eenvoudig is als het op het eerste zicht lijkt. Een derde probleem is dan de wijze waarop de connectie zelf tot stand komt. Er zal dus moeten nagegaan worden welke mogelijkheden er zijn en wat de voor en nadelen van deze opties zijn. Het spreekt voor zich dat de voorgaande probleemstellingen nog niet alles zijn. Er komt heel wat meer bij kijken dan eenvoudig weg de communicatie tussen twee entiteiten te modeleren. Er moet bijvoorbeeld ook nagedacht worden over de interne structuur van de cliënt en de server. Hoe worden gegevens opgeslagen, wie is er verantwoordelijk voor welke functionaliteit? Wat zijn de functionaliteiten? Een laatste maar misschien wel belangrijkste punt is dan de vraag hoe je nu precies object georiënteerd te werk kan gaan. Dit is belangrijk om de leesbaarheid van de code te verhogen en om herbruikbaar te zijn. 8

21 FIGUUR 5: SCHEMATISCHE VOORSTELLING VAN DE TESTSYSTEMEN Figuur 5 heeft een algemeen beeld van de situatie weer. De bovenste ellips stelt de thuisbasis voor van de R&D afdeling, de twee onderste ellipsen stellen verschillende productie afdelingen voor. De cliënts zijn stellen allemaal testplatformen voor. Opmerking: Hoewel de communicatie over het internet gaat, zijn de verschillende plants allemaal via een VPN verbinding met elkaar verbonden. 9

22 3.1.4 SAMENVATTING Uit voorgaande beschouwingen is het mogelijk om een lijst te destilleren van problemen, moeilijkheden en uitdagingen waaraan moet worden gedacht vooraleer te beginnen met enige code te schrijven. Dit wil echter niet zeggen dat de oplossingen die voor deze problemen worden aangereikt later niet herzien kunnen worden. Uiteindelijk is het ontwerpen van software een iteratief proces, waarbij steeds opnieuw moet worden nagedacht over de gekozen weg. Het is ook mogelijk dat tijdens het programmeren zelf er enkele problemen opduiken die niet voorzien waren, of dat sommige oplossingen in de praktijk niet mogelijk zijn. Lijst met uitdagingen: Eén of twee programma s Serializing implementeren Authenticatie implementeren Fysische connectie: TCP/UDP / WCF / remoting / Functionaliteit Multi threading. Communicatie protocol: Delete, Update, File, Structuur server / client Verantwoordelijkheden server / client? Object georiënteerd programmeren 10

23 H4 ALGEMEEN 4.1 EÉN OF TWEE PROGRAMMA S De keuze van het aantal programma s dat moet worden geschreven hangt voornamelijk af van hoeveel functionaliteit er gedeeld wordt. De vraag is dus of zowel de cliënt als de server een gelijke of gelijkaardige functionaliteit bieden. Het is duidelijk dat dit hier niet het geval is. Iedere cliënt zal namelijk enkel moeten verbinden met één server. De server moet echter in staat zijn om meerdere cliënts tegelijk te onderhouden. De cliënt moet eventueel verbinding kunnen maken met het testsysteem, terwijl de server dit helemaal niet hoeft te kunnen. Een cliënt moet relatief simpele commando s kunnen uitvoeren zoals bestanden verwijderen, copieren en dergelijke, terwijl de server in staat moet zijn om het hele updateproces in goede banen te leiden. Andere factoren die meespelen zijn de scheiding van verantwoordelijkheden en de mogelijkheden van object oriented design. Door twee applicaties te maken worden de verantwoordelijkheden namelijk duidelijker gesplitst. Ofwel staat de code in de server, ofwel staat de code in de cliënt. En als er goed object georiënteerd wordt geprogrammeerd, is het mogelijk om gedeelde functionaliteiten in aparte bibliotheken te schrijven en in te laden in beide projecten. Op deze manier moet ook deze code slechts eenmaal geschreven worden. De conclusie luidt dus dat het schrijven van twee programma s aangeraden is. De verschillen tussen cliënt en server zijn voldoende groot, de verantwoordelijkheden worden duidelijker gescheiden en de ontwikkelomgeving laat OO programmeren perfect toe. 4.2 FUNCTIONALITEIT Hoewel de functionaliteit van de volledige software reeds op de project sheet en het technisch detail is opgetekend, is het nog steeds nuttig om de gewenste functies nog iets beter te definiëren en op een rijtje te plaatsen. Hierbij moet zonder al te veel in detail te gaan worden vastgelegd wat er precies moet gebeuren. De functionaliteit zal zeer nauw aansluiten bij andere vragen zoals verantwoordelijkheden en communicatie. De functionaliteit van het programma is iets groter dan louter het versturen van files van A naar B. De server moet bijvoorbeeld in staat zijn om de verschillende cliënts uit elkaar te kunnen houden. Dit vraagt een zekere infrastructuur aan de server zijde. De echte functionaliteit bestaat er echter in om al de cliënts op regelmatige basis te ondervragen en te vergelijken met een basis model. Dit basis model wordt bijgehouden op de server. 11

24 4.2.1 VOLLEDIGE LIJST MET FUNCTIONALITEITEN: De server moet een lijst kunnen bijhouden met gekende cliënts. Deze moeten worden geauthentificeerd bij aanmelden. De server moet verschillende groepen ondersteunen. Een groep kan gezien worden als een basis model waaraan de cliënts moeten voldoen. Iedere cliënt moet in principe altijd tot een model behoren. Groepen moeten on-the-fly kunnen worden toegevoegd of verwijderd. Enkel de default group kan niet worden verwijderd. Een groep kan ook niet worden verwijderd als er nog steeds cliënts lid zijn van de groep. Het moet mogelijk zijn om een cliënt aan een nieuwe groep toe te wijzen. Een cliënt moet op commando kunnen worden geüpdate. Cliënts moeten ook automatisch kunnen worden geüpdate bij aanmelden. Het moet mogelijk zijn om op commando van de server een file te up- of downloaden naar of van een cliënt. Het moet mogelijk zijn om nieuwe cliënt toe te voegen. Het moet mogelijk zijn om een query uit te voeren vanaf de server op een database bij de cliënt. Het moet mogelijk zijn om een connectie te maken met het test platform. Bij het versturen van files moet het mogelijk zijn om een checksum mee te sturen die gecontroleerd wordt bij ontvangst. Files moeten worden goedgekeurd alvorens deze te versturen. 4.3 VERANTWOORDELIJKHEDEN. Om een duidelijk en efficiënt programma te kunnen ontwikkelen is het belangrijk om de verantwoordelijkheden van alle participanten in het proces wat nader te bestuderen. Het is duidelijk dat niet alle verantwoordelijkheid bij het programma ligt. Het bedrijf wenst namelijk volledige controle over het update proces. Dit wil zeggen dat ook al wordt er automatisch gecontroleerd of er files te kort zijn op het test systeem, er nog steeds een bevestiging moet komen van een operator om de update ook effectief door te voeren. Het is echter niet de bedoeling om te focussen op de verantwoordelijkheden van de operator maar op deze van het programma zelf. De verantwoordelijkheden zijn in principe vrij eenvoudig te definiëren. Het programma moet namelijk in staat zijn om al de gevraagde functionaliteiten aan te bieden. Er zouden echter problemen kunnen optreden omdat er nu niet één maar twee programma s worden geschreven. Om efficiënt te zijn, moet iedere taak door juist één applicatie worden uitgevoerd. Coördinatie is hierbij uiterst belangrijk en om goed te kunnen coördineren, moeten net zoals in het echte leven, de verantwoordelijkheden eerst duidelijk worden uitgesplitst. De verantwoordelijkheden hangen nauw samen met de functionaliteit, maar om deze goed te verdelen tussen de cliënt en de server, is ook een portie gezond verstand en logica nodig. 12

25 4.3.1 GEDEELDE VERANTWOORDELIJKHEDEN Bij het versturen van een file, moet er altijd een checksum worden berekend en mee doorgestuurd. Bij het ontvangen van een file, moet de checksum altijd worden gecontroleerd. Indien deze niet overeenstemt met de meegezonden checksum moet er een fout bericht worden verstuurd. Dit foutbericht moet leiden tot hertransmissie van de file. Zowel cliënt als server zijn verantwoordelijk voor het geheim houden van hun private key VERANTWOORDELIJKHEDEN VAN DE SERVER Authentificeren van de cliënt wanneer deze zich aanmeldt. Indien de uitkomst negatief is, moet de cliënt verwijderd worden. Controle proces opstarten wanneer de cliënt zich aanmeldt. Een lijst bijhouden van alle cliënts die toegang tot het systeem hebben. Wanneer een cliënt zich opnieuw aanmeldt, zonder zich eerst te hebben afgemeld, moet de server de reeds eerder aangemelde cliënt vervangen door de nieuwe cliënt. Na goedkeuring files en updates versturen VERANTWOORDELIJKHEDEN VAN DE CLIËNT Antwoorden op een poll bericht (als de server de verbinding test.) Antwoorden op een aanvraag om de index door te sturen. Update proces starten op aangeven van de server. Wachten met effectieve update tot de server daartoe opdracht heeft. Bij ontvangst van een commando een object creëren dat dit commando kan uitvoeren. Uitvoeren van commando s Nooit files definitief verwijderen, maar enkel verplaatsen van files naar een vuilbak map. Op deze manier moet het mogelijk zijn om bestanden te herstellen. 13

26 4.4 NOMENCLATUUR ROOT DIRECTORY Een root directory stelt een directory voor bij de cliënt vanaf waar er wordt geïndexeerd. Iedere cliënt kan een lijst met root directories aanleggen. Deze lijst bevat dan het pad van iedere map die als root moet beschouwd worden. Wanneer de server de index van de cliënt opvraagt, wordt de cliënt geacht alle roots te indexeren en het resultaat naar de server te zenden. De naam van iedere root directory moet verplicht uniek zijn RELATIEF PAD Een relatief pad is een pad dat start vanaf een niet specifiek gedefinieerde plaats. In dit document wordt de term relatief gebruikt om aan te duiden dat het pad van de root directory zelf niet gekend is. Bij het uitvoeren van de functie moet het relatieve pad wel omgezet worden naar een absoluut pad. Dit is de reden waarom de naam van een root directory uniek moet zijn. Voorbeeld: Stel dat een Cliënt het volgende bestand bezit: C:\Users\User\Documents\Application\RootDir\Dir1\Dir2\file.ext Dan kan de server naar deze file verwijzen op de volgende manier: Rootdir\Dir1\Dir2\file.ext Op deze manier hoeft de server niet het volledige pad bij te houden naar de root directories. Verder kan dit ook gebruikt worden om de data die heen en weer vestuurd wordt te beperken. (In dit voorbeeld moeten er 36 tekens minder verstuurd worden om het pad aan te duiden. Stel nu dat er bij een indexering maar 100 subitems in RootDir zijn, is dit toch een winst van 3600 tekens of 3.6 kilobyte) KANAAL Een kanaal is een virtuele verbinding tussen twee entiteiten die zich voordoet als een reële verbinding. In deze thesis worden kanalen gebruikt om via eenzelfde tcp-verbinding verschillende gesprekken te kunnen voeren, zonder rekening te moeten houden met andere entiteiten die hetzelfde kanaal gebruiken om data te versturen. Ieder kanaal heeft eigen events om speciefke gebeurtenissen voor dat kanaal te melden, maar gebruikt ook enkele gemeenschappelijke events GESPREK Een gesprek is een logische opeenvolging van berichten die tussen twee entiteiten worden uitgewisseld, over een kanaal. De berichten die tijdens een gesprek worden verzonden worden bepaald door het protocol. Een protocol kan ook zelf ontwikkeld zijn. 14

27 4.5 STRUCTUUR VAN DE SERVER EN DE CLIËNT Eerder in deze tekst is er reeds aandacht besteed aan de communicatie tussen de cliënt en de server en aan de verantwoordelijkheden van de cliënt en de server. Nu deze punten zijn behandeld en er bepaald is wie waarvoor verantwoordelijk is, is het aan te raden om ook eens stil te staan bij welke gegevens er zoal moeten worden bijgehouden en op welke manier dit dient te gebeuren. De gegevens die moeten bijgehouden worden slaan veelal op reeds eerder aangehaalde punten. Vandaar dat er hier iets minder aandacht wordt besteed aan verantwoording waarom bepaalde gegevens wel of niet zouden moeten bijgehouden SERVER Algemeen & instellingen De server zou moeten in staat zijn om een lijst met namen van alle cliënts bij te houden. Aan elke naam, moet de publieke sleutel en de groep waartoe de cliënt behoort worden verbonden. Er zou ook een mogelijkheid moeten bestaan om extra (optionele) gegevens toe te voegen specifiek aan iedere account. Verder moet de server ook in staat zijn om de verschillende groepen en hun indeling bij te houden. Hiermee wordt bedoeld dat er een mapstructuur met de files op de server aanwezig moet zijn. Uiteindelijk moet het ook voorzien zijn dat sommige algemene gegevens moeten kunnen worden opgeslagen. Hiermee worden voornamelijk gegevens bedoeld die na eenmalig instellen niet of zelden worden aangepast. Ten slotte moet er ook gedacht worden aan een structuur om wijzigingen te kunnen opvolgen. Dit gebeurt best door logging in een database Cliënt specifieke gegevens Behalve instellingen moet de server ook in staat zijn om verschillende logboeken bij te houden. Hierbij wordt gedacht aan een algemeen logboek en een apart logboek voor iedere cliënt. Het is ook handig om specifieke instellingen te kunnen opslaan per cliënt. Verder moeten ook voor iedere cliënt de volgende gegevens worden bijgehouden: Geplande updates De laatst ontvangen volledige index Niet geautoriseerde berichten Wel geautoriseerde berichten die nog niet verzonden zijn 15

28 4.5.2 CLIËNT Iedere cliënt moet uiteraard in staat zijn om verbinding te maken met de server. Hiervoor moet de computernaam van de server of het IP adres van de server worden opgeslagen samen met het poortnummer waarnaar de server luistert. Verder moet ook de eigen geheime sleutel en de publieke sleutel van de server worden bewaard. Het is echter altijd handig om ook de eigen publieke sleutel te bewaren op het toestel om deze te kunnen verdelen. Een ander gegeven dat moet worden bijgehouden zijn de mappen die moeten worden geïndexeerd op aanvraag van de server. Hiervoor moet de cliënt het volledige pad naar de root folders opslaan. De cliënt moet ook voorzien in een tijdelijke map voor het ontvangen van updates. Op deze manier kunnen alle updates worden verzonden en dan in één keer worden aangepast. De cliënt moet een vuilbak map bezitten waar files in terecht komen die verwijderd worden. Dit dient om samen met de logboek gegevens veranderingen ongedaan te kunnen maken. Ten slotte moeten er ook bij de cliënts logboeken worden bijgehouden. Deze logboeken moeten niet meteen kunnen worden gevisualiseerd, maar kunnen uitermate belangrijk zijn in geval van fouten, om zo te kunnen terug keren naar een eerder punt in de tijd. De logboeken moeten alle acties netjes oplijsten in chronologische volgorde. (Optioneel kan de cliënt ook een up/downloadmap bezitten.) 4.6 OBJECT ORIENTED DESIGN. Het.NET framework waarmee gewerkt wordt maakt het mogelijk om object georiënteerd te werk te gaan, zoals geïllustreerd in [1]. Object georiënteerd werken heeft, indien goed gedaan, het voordeel dat de code beter leesbaar wordt en vooral herbruikbaar. Door herbruikbare software te schrijven is het mogelijk om weliswaar één keer veel tijd in een probleem te steken, maar later (in andere projecten) de oplossing zonder enig probleem te hergebruiken en dus geen kostbare tijd meer te verspillen aan het heruitvinden van het wiel. De aard van OOP zorgt er dan weer voor dat de code leesbaar wordt. De code wordt namelijk opgesplitst in deelproblemen die één voor één worden opgelost. Alle code die bij een bepaald probleem hoort staat dan ook samen. Samen met een goede naamkeuze van variabelen en voldoende commentaar, wordt de code dan ook zeer leesbaar voor derden. 16

29 Het blijkt dus nodig te zijn om het project op te splitsen in deelproblemen en deze kleinere problemen op te lossen. Het is natuurlijk mogelijk dat een deelprobleem nog steeds een vrij groot en complex probleem blijkt te blijven. In dit geval kan het grote deelprobleem gepromoveerd worden naar een eigen project dat opnieuw wordt opgesplitst in kleinere deelproblemen. Het grote probleem waarmee gestart wordt, wordt dus steeds opgesplitst in kleinere entiteiten tot deze handelbaar worden. In deze thesis wordt het probleem opgesplitst in verschillende deelprojecten. Deze deelprojecten zullen uiteindelijk moeten samen werken, maar bij de keuze van de projecten is het toch zeer belangrijk om goed na te denken over functionaliteit van ieder project. Bij een goede keuze staat ieder project min of meer op zich en kan ieder project herbruikt worden bij andere projecten zonder veel extra code. Uiteraard is het niet mogelijk om altijd alles te hergebruiken. Ieder project zal ook een deel code bevatten die zeer specifiek is voor dat bepaalde project. Ook deze code wordt best in één of meerdere aparte projecten geplaatst. Hierin staat ook heel wat glue code die gebruikt wordt om de verschillende wel herbruikbare modules te gebruiken. Database Common language Network ServerBL (Server Business Layer) ServerGUI (Server General User Interface) CliëntBL CliëntGUI Uit deze lijst zijn enkel de modules Database en Network herbruikbaar. De Common language module bevat code die specifiek is voor deze applicatie en gebruikt wordt door zowel de cliënt als de server. De serverbl en ClientBL klas zijn klassen die specifieke code bevatten voor deze applicatie, die respectievelijk enkel in de server en in de cliënt gebruikt wordt. De ServerGUI en ClientGUI klas zijn klassen die enkel in staan voor de grafische weergave van de data. Hoewel uit het voorgaande misschien blijkt dat er maar zeer weinig kan worden herbruikt, is dit niet correct. Het is ten eerste altijd mogelijk om een aparte klasse te herbruiken, indien het volledige project op zich niet bruikbaar is. Het is anderzijds ook zo dat de twee modules die wel herbruikbaar zijn, ofwel zeer veel gebruikt kunnen worden (zoals de Logger ) of zeer veel werk vragen (zoals Network ). Het herbruikbare karakter van deze twee modules is dus zeker niet onbeduidend. Behalve het opsplitsen van het project in kleinere projecten, is het ook belangrijk dat de data zo weinig mogelijk gekopieerd wordt, maar er steeds gewerkt wordt met een object dat door gegeven wordt. Dit vraagt een diepgaand inzicht in de werking van de programmeer taal/ omgeving en kennis van de syntax. 17

30 H5 SERIALIZING Zoals al in de probleemstelling is aangehaald vormt het overschrijden van de programmagrenzen een probleem. Dit geldt ook wanneer er gegevens moeten verstuurd worden van en naar twee gelijke programma s, die echter op een verschillend proces draaien. Het probleem is dat je objecten niet zomaar kan doorgeven THEORETISCH Het enige wat in principe mogelijk is, is het doorgeven van een serie van enen en nullen. Deze array wordt een stream genoemd. Data die tussen twee applicaties wordt uitgewisseld moet dus altijd kunnen worden voorgesteld als een serie van enen en nullen. Omdat de ontvanger hier een betekenis moet aan kunnen koppelen, moet er een formaat worden afgesproken, dat gekend is door beide partijen. In de praktijk blijkt dat er twee verschillende manieren van serilaizeren worden onderscheiden. In de grond zijn beide technieken uiteraard gelijk. De eerste techniek is het binair serialiseren, de tweede is het tekstueel serialiseren. Tekstueel serializeren heeft het voordeel dat het resultaat (de verzonden data ) leesbaar is voor mensen. Ook is het zo dat wanneer gegevens tekstueel verstuurd worden, er een grotere overdraagbaarheid is tussen verschillende platformen. Hierbij wordt bijvoorbeeld gedacht aan Linux versus Microsoft. Het nadeel van de tekstuele serialisatie is dan weer dat wanneer binaire informatie tekstueel voorgesteld wordt, er een groot deel van de binaire codes niet gebruikt kan worden in de tekstuele versie. Er moeten dus speciale codeertechnieken gebruikt worden om de data om te zetten naar leesbare tekens. Een voorbeeld van zo een conversie standaard is base64. Het omzetten naar tekst zorgt er dus ook voor dat het bericht veel langer zal worden. Wanneer gegevens tekstueel verstuurd worden, gebeurt dit bijna altijd door gebruik te maken van XML. Een ander feit dat in rekening moet worden gebracht is dat enkel geserializeerde data kan worden opgeslagen op de harde schijf. Het is dus mogelijk om dezelfde techniek die gebruikt wordt om data over het netwerk te versturen, te gebruiken om gegevens op te slaan op de harde schijf. Deze gegevens kunnen dan worden bewaard ook nadat het programma is afgesloten en bij opnieuw opstarten worden ingelezen. 18

31 5.1.2 PRAKTISCH Vooraleer een definitieve keuze te maken over de te gebruiken techniek, is het aangeraden om eens te bestuderen hoe beide technieken kunnen worden geïmplementeerd in C#. Het blijkt dat er in C# standaard zowel een binaire serializer als een XML serializer is geïmplementeerd. Beide technieken kunnen blijkbaar met een zelfde gemak worden toegepast. Het schrijven van een eigen serializer is in principe ook mogelijk maar lijkt redelijk complex. De kans op fouten bij een eigen implementatie is zeer reëel en daardoor af te raden. Het is echter wel mogelijk om het gedrag van de ingebouwde serializers aan te passen aan de eigen noden, waarbij de complexiteit nog redelijk binnen de grenzen ligt. Een aangepaste versie is nodig indien de binairy serializer wordt gebruikt op een object dat events bezit. Het is namelijk zelden de bedoeling om ook deze events mee te serializeren. De XML- serializer heeft dit probleem niet, maar verwacht wel een publieke constructor zonder input argumenten. Dit kan ongewenst zijn wanneer bijvoorbeeld een object een unieke code moet meekrijgen op het ogenblik dat een object van de klasse wordt geïnstantieerd KEUZE VAN DE SERIALIZER. Blijkbaar zijn er twee opties mogelijk voor het versturen van data. De eerste optie is leesbaar voor mensen, de tweede optie niet. De tweede optie is dan wel meestal een heel stuk compacter dan de eerste optie. Beide worden standaard reeds geïmplementeerd in C# Het is aan te raden om gegevens binair te versturen wanneer deze via het internet worden verstuurd. Dit heeft als voordeel dat de te versturen data kleiner is dan bij gebruik van een XML serializer. Dat de gegevens niet zomaar leesbaar zijn voor een mens is op zich ook niet erg en kan zelfs gezien worden als een plus punt voor security. Wanneer gegevens echter op de harde schijf worden opgeslagen is het eerder aan te raden om voor een XML- serializer te kiezen. Geheugen is namelijk relatief goedkoop en als de data leesbaar is, kan deze worden bekeken en eventueel worden aangepast in een standaard tekstverwerker zoals kladblok. De gebruiker hoeft dus niet het programma op te starten en te doorzoeken om te weten welke informatie er in de file staat, maar kan deze eenvoudig open in tekst formaat BESLUIT De conclusie is dus dat gegevens die over het internet worden verstuurd best binair geserialiseerd worden. Ook gegevens die lokaal worden opgeslagen en waar de gebruiker best niets aan wijzigt, worden best binair gecodeerd. Gegevens die echter lokaal worden opgeslagen en waarvan de gebruiker eventueel zelf wijzigingen mag aan doorvoeren, worden bij voorkeur via XML geserialiseerd. 19

32 H6 AUTHENTICATIE Hoewel het internet een zeer goede manier is om gegevens goedkoop en snel te versturen, heeft de vrij recente geschiedenis ons toch geleerd dat er enkele gevaren aanwezig zijn. Omdat ieder programma dat via het internet communiceert een mogelijk doelwit is voor criminele individuen, is het aan geraden om toch enige beveiliging in te bouwen. Authenticatie heeft als doel om de identiteit van de tegenpartij te bepalen. Eenmaal de identiteit van de partner gekend is, kan worden besloten of deze toegang krijgt tot het systeem. Het doel van authenticatie is enkel gekende cliënts toelaten in het systeem. Alle andere cliënts moeten worden geblokt. Om dit te realiseren, moet de server over een lijst beschikken van toegelaten cliënts en een manier om deze te kunnen identificeren. Opmerking: Gezien de uiteindelijke applicatie enkel binnen het eigen bedrijfsnetwerk van Psi Control blijft (via VPN ) is authentificatie op zich niet zo belangrijk. Dit zou wel het geval zijn indien er ook van buitenaf een verbindingsmogelijkheid zou moeten bestaan. Toch is er een kleine authentificatie module ingebouwd omdat het de bedoeling is om de netwerk module later te kunnen gebruiken in andere projecten, waar authentificatie misschien wel nodig is. 6.1 IMPLEMENTATIE MOGELIJKHEID 1 Authentificatie kan bijvoorbeeld door iedere cliënt een unieke naam te geven en een paswoord. Wanneer de cliënt zich aanmeldt, stuurt de cliënt op verzoek van de server zijn naam en wachtwoord. De server vergelijkt daarna het wachtwoord met de database. Deze manier van werken heeft echter een groot nadeel. Het is namelijk mogelijk dat een kwaadaardige identiteit zo een identificatie bericht zou onderscheppen en dit dan later opnieuw verstuurt om zo zichzelf aan te melden (reply, MITM-attack ). Het spreekt voor zich dat dit niet de bedoeling is MOGELIJKHEID 2 Om het probleem van replay- messages te omzeilen, moet er een ander systeem gebruikt worden dat ervoor zorgt dat de identificatie berichten telkens anders zijn. Dit kan bereikt worden door een random waarde toe te voegen aan een bericht en dit bericht te versleutelen via een asymmetrische versleuteling. In dit geval bewaart de server niet zo zeer een passwoord, maar wel de publieke sleutel (PuK) van de cliënt. Op het ogenblik dat de cliënt zich aanmeldt, kan de server dan een random waarde genereren, deze waarde versleutelen met de PuK van de cliënt en dit bericht versturen. De cliënt ontvangt dan dit versleutelde bericht, ontsleutelt dit met zijn eigen private sleutel (PrK) doet eventueel een bepaalde bewerking op de ontvangen waarde 20

33 en stuurt deze waarde al dan niet versleuteld terug naar de server. Als de server een correct antwoord ontvangt van de cliënt, weet deze dat de cliënt is wie hij beweert te zijn. Opmerking: Deze methode houdt wel in dat de publieke sleutel van de cliënt gekend is bij de server en dat de server er zeker van is dat de publieke sleutel inderdaad van de cliënt is en niet van iemand anders. Hoe dit gebeurt wordt hier niet behandeld KEUZE EN PRAKTISCH. Het is duidelijk dat de tweede mogelijkheid een betere beveiliging biedt dan de eerste mogelijkheid. In de applicatie zal er dan ook gekozen worden voor het principe waarbij er een publieke sleutel wordt bewaard op de server. De implementatie zal in de praktijk echter iets anders zijn, in de zin dat de server een symmetrische sessie sleutel asymmetrisch zal versleutelen en verzenden naar de cliënt. De server zal dus telkens er zich een cliënt aanmeldt een nieuwe symmetrische sleutel aanmaken en doorsturen naar de cliënt. De identificatie gebeurt dan door een willekeurige byte array versleuteld met de symmetrische sleutel te versturen als identificatie token. De token wordt symmetrisch versleuteld, omdat asymmetrische versleuteling veel langer duurt dan symmetrische versleuteling. In de praktijk wordt dus steeds enkel de symmetrische sleutel asymmetrisch versleuteld. Het is ook zo dat de ingebouwde asymmetrisch versleutelingmodule niet in staat is om de token volledig te versleutelen ( in.net). Merk op dat enkel berichten die zijn versleuteld met de sessie sleutel geauthentificeerd zijn. 21

34 H7 CONNECTIE METHODE Onder connectie methode verstaan we niet welke kabel er gebruikt zal worden om de gegevens te versturen. Er wordt eerder mee bedoeld op welke manier kan er vanuit een programma data worden verstuurd over het internet. In mindere mate wordt er ook geduid welk protocol er gebruikt zal worden omdat dit misschien een rol kan spelen in de keuze van de te gebruiken methode. Dit probleem is nogal praktisch in die zin dat het zeer sterk afhankelijk is van de ontwikkelomgeving. De taakomschrijving vermeldt duidelijk dat de applicatie geschreven moet worden in C#. Dit wil zeggen dat wanneer er een internet connectie moet worden gemaakt, de werkwijze waarop dit gebeurt beperkt is tot de mogelijkheden die de ontwikkelomgeving toestaat. C# draait echter op het.net framework en dit framework biedt vier verschillende mogelijkheden om verbindingen te maken met het internet. Om een keuze te maken over de beste methode is het noodzakelijk om het netwerk van naderbij te bekijken. Netwerken zijn sterk beïnvloed door het OSI model dat eind de jaren 70 werd ontwikkeld. Het is dan ook aangewezen om dit model even kort te bestuderen. Er moet wel worden opgemerkt dat het OSI model niet strikt gevolgd wordt door het TCP/IP model. 22

35 7.1 OSI MODEL Het OSI model [2] is een theoretisch model ontwikkeld eind de jaren 70 door het ISO (International Organization for Standardization ) met als bedoeling een abstract model te maken van hoe netwerk verbindingen eruit zouden moeten zien. Inclusief enkele protocollen. Het protocol kwam er omdat er een dringende nood was voor standaards en hetrogene netwerken [3]. Het spreekt voor zich dat in projecten als deze er een minimum kennis moet zijn van het protocol dat aan de basis ligt van bijna alle hedendaagse netwerken. Het OSI model splitst een netwerk op in zeven verschillende lagen. Iedere laag biedt services aan, aan de bovenliggende laag en gebruikt hiervoor services van de onderliggende laag. Het doel van deze aanpak is het opsplitsen van de complexiteit en de functionaliteit in verschillende aparte delen DE LAGEN IN HET OSI MODEL. Application Layer Presentation Layer Session Layer Transport Layer Network Layer Data Link Layer Physical Layer FIGUUR 6: HET OSI MODEL 23

36 7.1.2 VERKLARING VAN DE LAGEN Hier volgt een zeer korte beschrijving van de verschillende lagen. Uitgebreidere informatie kan teruggevonden worden in [4] Toepassingslaag Deze laag staat helemaal bovenaan in het model en stelt het programma voor dat wenst te communiceren via het netwerk, zoals Internet Explorer, Outlook,....Deze laag kent een groot aantal protocollen zoals: HTTP, SMTP, FTP, Presentatielaag De presentatielaag zorgt voor enkele diensten die moeten helpen bij het interpreteren van de gegevens die tussen toepassingen worden uitgewisseld, zoals versleutelen, ontsleutelen en comprimeren Sessielaag Deze laag is verantwoordelijk voor het creëren, beheren en afsluiten van sessies, tussen twee systemen De transport laag De transport laag verstuurt de berichten van de applicatie laag. Het internet gebruikt twee transport protocollen TCP & UDP. TCP is een connectie georiënteerde service die de data opsplitst bij de zender en weer samenvoegt bij de ontvanger. Verder zorgt TCP voor een betrouwbare verbinding waarbij de snelheid van verzenden aangepast wordt aan de netwerk capaciteit. (Door flow control en error control ) UDP is in tegenstelling tot TCP een zeer kort en eenvoudig protocol dat weinig diensten levert, connection less is, maar door het gebrek aan flow control mogelijks sneller is. De transport laag is de laatste laag die werkt op end to end basis. De transportlaag gebuikt postnummers om bij ontvangst van data deze aan het juiste proces te linken Netwerklaag De netwerklaag breekt de segmenten afkomstig van de transportlaag verder op in pakketten en voegt daar een source en destination IP adres aan toe Datalink laag De datalink laag is verantwoordelijk voor het versturen van data tussen twee netwerk apparaten. Dit gebeurt door de data in frames te plaatsen Fysieke laag De fysieke laag is de laag waarop data effectief wordt verstuurd. Hier wordt de data (bits ) omgezet naar signalen die dan over het gebruikte medium worden verzonden. Onder de fysieke laag vallen onder andere afspraken in verband met timing, afmetingen et cetera. 7.2 TCP/IP Hoewel het OSI model een mooi model is dat vaak wordt gebruikt als theoretische achtergrond, blijkt dat in de praktijk het TCP/IP model gebruikt wordt om data te 24

37 versturen. Het verschil tussen TCP/IP en het OSI model bevindt zich voornamelijk in de drie hoogste lagen van het OSI model. De toepassing laag, de presentatie laag en de sessie laag zijn namelijk samengebracht in een enkele applicatielaag. Het is dus de verantwoordelijkheid van de programmeur geworden om de functionaliteit van de sessieen presentatie laag te implementeren in de applicatie. (Indien dit noodzakelijk is. ) Verder is het zo dat het TCP/IP model inhoudt dat data wordt verstuurd via een TCP verbinding (transport laag ) wat inhoudt dat er een virtuele link wordt gecreëerd die als het ware een foutloze data overdracht mogelijk maakt. Application Layer Transport Layer Network Layer Data Link Layer FIGUUR 7: HET TCP-IP MODEL 7.3 VOORDELEN VAN DE GELAAGDE AANPAK Een voordeel van een gelaagde aanpak is dat de complexiteit verkleint [3], [4]. Wat op zijn beurt resulteert in minder fouten en dus een betrouwbaarder netwerk Het wordt ook mogelijk voor verschillende producenten om producten te maken die met elkaar kunnen communiceren. Dit kan ook de concurrentie verhogen en op deze manier voor goedkopere producten zorgen. Geen van deze reden is echter interessant voor de programmeur. Wat wel interessant is voor software ontwikkelaars is dat deze geen rekening meer moeten houden met onderliggende lagen. Er moet enkel een connectie worden gemaakt tussen de applicatie en de transportlaag, om twee applicaties met elkaar te verbinden. De enige keuze die uiteindelijk moet gemaakt worden, is de keuze tussen TCP of UDP. 25

38 7.4 TCP VERSUS UDP TCP [5] en UDP [6] zijn twee protocollen die werken op de transportlaag. Het verschil tussen beide protocollen is dat TCP flow control en error control aanbiedt en UDP deze functionaliteiten niet aanbiedt. TCP biedt dus duidelijk meer functionaliteit dan UDP. Dit brengt uiteraard ook een kost met zich mee. Het is namelijk zo dat om een TCP verbinding op te stellen er eerst een handshake procedure zal plaatsvinden. UDP verbindingen kunnen daarentegen onmiddellijk starten met het versturen van data, wat iets sneller zal zijn. Verder is het ook zodat de hedendaagse TCP congestie protocollen dataverkeer over langere afstanden iets benadelen ten opzichte van pakketten die over korte afstanden worden verzonden zoals blijkt uit [7].Gezien België en Roemenie niet onmiddellijk naast de deur liggen, kan dit dus een extra vertraging geven. De transmissie snelheid is voor deze applicatie echter minder belangrijk en de snelheidswinst weegt niet op tegen het extra werk dat zou moeten gebeuren om de beperkte mogelijkheden van UDP op te krikken. 7.5 KEUZE PROTOCOL Gezien in deze applicatie betrouwbaarheid van de verstuurde data een topprioriteit is, is de keuze van het protocol zeer simpel. Er moet voor TCP gekozen worden. Deze keuze impliceert dat er automatisch een flow control aanwezig is en dat de applicatie er reeds vrij zeker van kan zijn dat de ontvangen data correct en in de juiste volgorde ontvangen wordt. 26

39 H8 IMPLEMENTATIE.Net biedt verschillende mogelijkheden om gegevens via netwerken te versturen. Er zijn vier mogelijkheden onderzocht. Sockets.NET remoting WCF Webservices 8.1 SOCKETS Deze eerste mogelijkheid biedt een zeer directe verbinding met de onderliggende lagen. De ingebouwde System.Net.Sockets namespace biedt een TcpClient en een TcpListner klasse. Er zijn ook enkele andere klassen beschikbaar die echter minder interessant zijn voor de beoogde toepassing, zoals een UdpClient, of de Socket klasse. De socket klasse laat weliswaar nog iets meer controle toe, maar opereert op een iets lager niveau dan de tcpclient klasse. Het werken met deze klasses is vrij eenvoudig. Aan server zijde wordt er een TcpListner klasse gecreëerd. Deze wordt ingesteld om te luisteren naar een bepaalde poort. Aan de cliënt zijde wordt er dan een tcpclient aangemaakt die connecteert met de server door het IP adres van de server op te geven samen met de poort waar de server naar luistert. Eenmaal er een nieuwe connectie gedetecteerd is, kan deze worden geaccepteerd in de vorm van een TcpClient object. Wanneer dit gebeurd is heb je zowel aan cliënt als aan server zijde een TcpClient object die gebruikt kan worden om data te versturen en ontvangen. Op dit ogenblik is er een full duplex verbinding. Nu moet er opnieuw gepolld worden om te controleren of er data aanwezig is. Het voordeel van deze aanpak is dat het vrij eenvoudig is. Het is zeer gemakkelijk om de relatie te zien met het OSI model of het TCP/IP model. Het is wel zo dat de ontwikkelaar zelf verantwoordelijk is voor het opvangen van fouten, het versturen van data en vooral het ontvangen en juist interpreteren van deze data. Dit zou kunnen gezien worden als een nadeel, maar hoeft dit niet te zijn. In het geval de applicatie verplicht gebruik moet maken van een bestaand protocol, kan dit zeer veel werk betekenen om dit protocol volledig en correct te implementeren. Indien het echter mogelijk is om een eigen protocol te ontwikkelen, kan dit vrij eenvoudig [4], door zelf gedefinieerde data objecten te specificeren die zo eenvoudig of ingewikkeld gemaakt kunnen worden als noodzakelijk is voor de applicatie. 27

40 8.2.NET REMOTING.Net Remoting [8] is ontwikkeld door microsoft met als doel een abstract communicatie proces te creëren. Dit communicatie proces zou moeten flexibel en gemakkelijk aanpasbaar zijn. Verder zou het mogelijk moeten zijn om het protocol en het serialisatie formaat aan te passen zonder de cliënt of de server te moeten herconfigureren..net Remoting is een voorloper van WCF. Om een applicatie te bouwen die gebruik maat van.net Remoting, heb je minstens de volgende elementen nodig: Een remotable object Een server applicatie Een cliënt applicatie Deze elementen zijn echter nodig voor alle technologieën die beschikbaar zijn..net Remoting is echter helemaal niet zo simpel als het op het eerste zicht lijkt. Zo is het bijvoorbeeld zeer belangrijk om de werking van de infrastructuur te kennen en te begrijpen. Op de website van Microsoft is hierover het volgende te vinden: you must understand the lifetime and activation issues that the remoting infrastructure introduces. Om een robuuste applicatie te bouwen is het dus van het uiterste belang om eerst een zeer uitgebreide studie te maken over dit onderwerp. Indien dit niet gebeurd is het namelijk onmogelijk te beweren dat de applicatie in alle gevallen goed zal functioneren. De studie die gemaakt moet worden is daarbij nog niet eens zo eenvoudig. Enkele tests met deze infrastructuur hebben ook duidelijk gemaakt dat remoting niet zo eenvoudig is. En zeker niet voor de toepassing die voor deze thesis moet worden gemaakt. Remoting heeft namelijk het nadeel dat het maar een kant op gaat. Uiteraard kan een server wel antwoorden op een vraag van de cliënt, maar de server kan nooit zelf het initiatief nemen om met de cliënt contact op te nemen. Andere methodes bieden deze mogelijkheid wel. Indien het dus wenselijk is dat de server op eigen initiatief contact kan op nemen met een cliënt, dan zou de cliënt zelf ook als server fungeren en moet er aandacht worden besteed aan de binding tussen de twee kanalen die op dat ogenblik zullen bestaan. 28

41 8.3 WCF De derde manier om via het netwerk te communiceren is door gebruik te maken van WCF [9](Windows Communication Foundation ). Dit platform is net zoals.net Remoting ontwikkeld door Microsoft met de bedoeling om developers een eenvoudigere manier aan te reiken om service te ontwikkelen en om de SOC paradigm te gebruiken. Het toenemende belang van services en de bijhorende SOC paradigma, wordt ook aangestipt door [10] Yinong Chen en W.T. Tsai in hun artikel over Service Orientated Computing systems. In tegenstelling tot.net remoting is WCF ook geschikt om te communiceren tussen verschillende platforms 1. Dit omdat remoting eigenlijk maar een tussenoplossing was om te komen tot WCF. WCF is namelijk het doel waar microsoft naar streefde om een algemeen, performant systeem te ontwikkelen die zowat alles onder de motorkap heeft. WCF biedt bovenop het versturen van standaard asynchrone berichten ook protocollen voor beveiligde, betrouwbare transactie mogelijkheden. Met een brede keuze van transport en codeer opties. Het grootste voordeel van WCF is waarschijnlijk dat zoveel verschillende protocollen reeds standaard geïmplementeerd zijn. (Zoals ASMX,.Net Remoting, WSE, MSMQ, ) Hierdoor wordt het mogelijk om met dezelfde of minstens zeer gelijkaardige code connectie te maken met verschillende cliënts via verschillende protocollen. WCF maakt voornamelijk gebruik van SOAP berichten, maar kan ook overweg met andere formaten zoals XML. Een nadeel van WCF is echter dat deze nieuwe technologie enkel werkt vanaf.net framework Figuur 8: WCF 3.0. Dit wil zeggen dat er geen gebruik kan gemaakt worden van WCF in vs2005 gezien vs2005 werkt met.net framework 2.0. Er is ooit een beta versie gepubliceerd door Microsoft om vs2005 compatible te maken met WCF, maar er is nooit een officiële versie verschenen. De officiële downloadlink naar deze beta versie is ook verdwenen [11], [12]. 1 Zie figuur 8 (Used with permission from Microsoft. ) 29

42 8.4 WEBSERVICES Een laatste optie is gebruik maken van webservices. Deze optie is eenvoudiger in gebruik dan Remoting. Webservices hebben echter het nadeel ten opzichte van bijvoorbeeld sockets, dat de server passief is in de zin dat deze wacht tot de client een oproep doet, om dan een bepaalde routine uit te voeren. Gezien de aard van de opdracht, zou het in dit geval echter handig zijn, dat de server de verschillende cliënts kan aanspreken op het ogenblik dat de server dit wenst. Hoewel dit met enige creativiteit kan bekomen worden, is dit niet onmiddellijk de bedoeling van een webservice. 8.5 BESLUIT Na een onderzoek van de verschillende mogelijkheden kan worden geconcludeerd dat het gebruik van de System.Net.Socket namespace aangewezen is..net Remoting heeft als belangrijk nadeel dat het achterliggende concept vrij moeilijk is. Toch zou dit concept volledig moeten begrepen worden alvorens het mogelijk zou zijn om remoting te gebruiken rekening houdend met het feit dat de applicatie robuust moet zijn. Verder is Remoting ondertussen een al wat oudere technologie die ondertussen vervangen is door WCF. Ook het feit dat er geen eenvoudige full duplex communicatie mogelijk is, is een serieus min punt. WCF daarentegen is over de volledige lijn zeer positief, maar kan niet gebruikt worden met vs2005. PSI Control werkt echter nog steeds met vs2005 dus ook WCF is geen optie. Er moet wel opgemerkt worden dat WCF eigenlijk een zeer goed model lijkt te zijn dat in de toekomst waarschijnlijk veel gebruikt zal worden. Wanneer webservices dan vergeleken worden met sockets, blijkt dat het eenvoudiger is om de cliënts aan te spreken (vanaf de server) door gebruik te maken van de sockets.het nadeel van het gebruik van de sockets is dat deze nogal low level zijn. Dit kan echter meteen ook als een voordeel gezien worden daar de programmeur veel vrijheid heeft in het ontwikkelen van de applicatie. 30

43 H9 COMMUNICATIE PROTOCOL Wanneer de functionaliteiten van het programma gekend zijn, moet worden bestudeerd welke informatie er moet worden verzonden en in welke volgorde dit moet gebeuren. Deze afspraken vormen samen een protocol. Tijdens de implementatie zijn sommige aspecten nog gewijzigd. De berichten zullen in de applicatie dus andere namen hebben, in een iets andere vorm voorkomen en een beetje anders geschikt zijn. Toch blijft deze eerste versie van het protocol belangrijk omdat er enkele goede principes zijn in opgenomen en het een beeld heeft van de opdeling van het programma. De wijzigingen zijn niet zozeer gemaakt omdat de hier beschreven berichten niet voldoen, maar omdat er enkele praktische elementen opdoken, waardoor het protocol enigszins geëvolueerd is. Het originele protocol is in sommige opzichten zelfs beter in die zin dat er in principe een kleinere kans op fouten is bij de implementatie. Daar staat wel tegenover dat de implementatie misschien iets omslachtiger is. Opmerking : De berichten in verband met de authenticatie worden hier niet besproken. Het idee is om alle berichten die moeten of kunnen worden verstuurd te omschrijven in een gemeenschappelijke module. Ieder bericht zou dan de vorm van een object innemen en serializable moeten zijn. De naam van de klasses zou dan het commando zijn en ieder commando kan op deze manier een eigen set van voorgedefinieerde argumenten hebben. Om een commando uit te voeren moet dan in eerst instantie een object van het commando worden aangemaakt (via het new keyword). Vervolgens kunnen de argumenten ingevuld worden en uiteindelijk kan het object verzonden worden. Bij de ontvangst moet dan het type van het object bepaald worden en een functie worden opgeroepen die dit commando kan afhandelen. Voorbeeld: stel dat we een commando Delete willen versturen, waarbij we als argument het pad van het bestand of de map kunnen opgeven dat verwijderd moet worden. Dan zou de declaratie van het bericht als volgt kunnen zijn: CODE 1: BESCHRIJVING VAN EEN COMMANDO namespace common { [Serializable] [XmlRoot("Delete")] public class Delete { [XmlAttribute("ToBin")] public bool ToBin = true; [XmlElement("Path")] public string Path = ""; public Delete() { 31

44 Wanneer een bericht op deze manier wordt gedefinieerd is het zowel binair als XML serializable. Het bericht zelf bevat twee argumenten. Het eerste argument is een boolean die aangeeft of het bestand verplaatst moet worden naar de vuilbak, of definitief verwijderd moet worden. Het tweede argument duidt het bestand (of de map) aan die verwijderd moet worden. De functie die dit commando wenst te versturen kan er uit zien zoals beschreven in Code 2: Verzenden van een commando. Voor de duidelijkheid zijn de variabelen in de functie zelf vervangen door een voorbeeld waarde. Het resulterend bericht (indien er gebruik gemaakt zou worden van een XML serializer ) is te zien in Code 3: Commando bericht, XML geserializeerd. De verwerking staat (vereenvoudigd ) weergegeven in Code 4: Verwerken van ontvangen commandos. Bij de verwerking wordt er voor de eenvoud vanuitgegaan dat het pad verwijst naar een bestand en niet naar een map. Ook veiligheden zoals het controleren van de variabelen en het gebruiken van try blokken zijn weggelaten. CODE 2: VERZENDEN VAN EEN COMMANDO private void Delete(string path, bool ToBin) { common.delete commando = new common.delete(); commando.tobin = true; commando.path Client.send(commando); CODE 3: COMMANDO BERICHT, XML GESERIALIZEERD <?xml version="1.0"?> <Delete xmlns:xsi=" xmlns:xsd= ToBin="true"> <Path>C:\Users\Nick\..\Directory\file.ext</Path> </Delete> 32

45 Code 4: Verwerken van ontvangen commandos void Handler(Network.Messages.ObjectMessage message) { /*other types*/ if (message.body is common.delete) { DeleteFunction(message.Body as common.delete); goto LabelFinaly; /*other types*/ CommandNotRecognised(message); return; LabelFinaly: /*code to execute after handling messages*/ void DeleteFunction(common.Delete message) { if (message.tobin) System.IO.File.Move(message.Path,"C:\..\Bin\[filename]"); else System.IO.File.Delete(message.Path); void CommandNotRecognised(Network.Messages.ObjectMessage message) { /*handle error*/ In de code wordt gebruik gemaakt van een GoTo statement. Dit wordt in een reële applicatie best vervangen door een return statement waarbij de code na LabelFinaly wordt uitgevoerd in de functie die de handler in de eerste plaats heeft opgeroepen. Het gebruik van GoTo statements is namelijk al jaren bekend voor het verhogen van fouten in de code. Zoals blijkt uit het artikel van de heer Dijkstra [13] waarin reeds in 1968 gewaarschuwd werd voor het gebruik van GoTo. De aandachtige lezer zal later in de tekst opmerken dat het GoTo statement toch gebruikt wordt in de code. Hier moet echter een kleine kanttekening bijgepplaatst worden in die zin dat bijna alle stukken code waarin dit statement staat in deze thesis tekst zijn opgenomen. Het gaat steeds over sleutel fragmenten waar lange tijd over is nagedacht. Er zijn dus weinig andere blokken die dit statement bevatten en het statement werd zeker niet lichtzinige gebruikt. De reden waarom het toch gebruikt wordt is omdat in de specifieke gevallen waar het gebruikt werd de code zeer uitgebreid zou worden zonder dit statement, waardoor de algemene leesbaarheid zou dalen en de kans op fouten zou stijgen. 33

46 9.1 HOOFDCOMMANDO S Om een overzicht te kunnen houden op de berichten die worden verzonden, kunnen deze worden opgedeeld in hoofd en sub commando s. De hoofdcommando s worden gebruikt om belangrijke of grote zaken te regelen, terwijl de subcommando's de eigenlijk sturingen doen. Om sub commando s aan de juiste hoofdcommando s te kunnen binden, kan men gebruik maken van kanalen. Lijst van gedefinieerde hoofdcommando s: Delete StartUpdate GetIndex GetDirectory GetFile File GetDrives BESCHRIJVING VAN DE HOOFDCOMMANDO S Tabel 1: Hoofd commando's Commando Beschrijving Argument Delete De cliënt moet de gespecificeerde file of folder verplaatsen naar de vuilbak. Pad naar een file of folder. 2 StartUpdate De cliënt moet een object aanmaken dat updates kan afhandelen en de sub commando s verstaat. GetIndex De cliënt moet de volledige lijst doorsturen met alle rootdirectories, subdirectories en files. GetDirectory De cliënt moet de namen van alle files en Pad naar de folder 2 directories terugsturen naar de server, alsook een directory informatie object van de gespecificeerde directory. GetRootDirectory- Names De cliënt moet een lijst doorsturen met de geregistreerde root directories. GetFile De cliënt stuurt de gespecificeerde file op Pad naar de file 2 File GetDrives naar de server De cliënt ontvangt een file van de server en slaat deze file op, op de opgegeven locatie of anders in een standaard download map. Returns the drives on the client. [Pad naar een folder 2 ] 2 Het pad van de file of de folder die verwijderd moet worden. Dit pad kan zowel absoluut als relatief zijn. 34

47 Delete Het delete commando is een basis commando dat de gebruiker in staat moet stellen om files en folder te verwijderen. De cliënt mag echter nooit een file definitief verwijderen. Iedere file wordt dus gekopieerd naar een speciale vuilbak map op de cliënt. Op deze manier is het mogelijk om later terug te keren naar een vorige toestand. Om de originele locatie van de files in de vuilbak te kunnen achterhalen, moeten alle verrichtingen worden gelogd. Op deze wijze moet het mogelijk zijn om op een later tijdstip files terug te plaatsen StartUpdate Wanneer de server het startupdate commando stuurt, moet de cliënt hierop reageren door een object te creëren dat in staat is om een update door te voeren. De server moet hiervoor steeds een kanaal voorzien. Het update object is verplicht om zich in te schrijven op dit kanaal. De cliënt is ook verplicht om via dit kanaal te melden dat het update proces kan beginnen. Het start update commando kent verschillende sub commando s. Deze commando s mogen in principe enkel worden gestuurd over het gereserveerde kanaal voor het update proces. Status ContinueLastUpdate NewUpdate File Folder DoUpdate Close 35

48 TABEL 2: START UPDATE - SUBCOMMANDO S Commando Bescrijving Argumenten ContinueLastUpdate De server vraagt de cliënt om verder te doen met een vorige update. NewUpdate De cliënt wordt gevraagd om de vorige niet voltooide update te verwijderen en een nieuwe update te beginnen. Status De server vraagt de huidige status van het update object. File De server stuurt een file door naar de cliënt. De file zelf Pad naar de doel directory Folder De Server stuurt een folder door Pad van de folder die moet gecreëerd worden. DoUpdate De server heeft opdracht om de ontvangen files effectief te updaten. Close De server meldt de cliënt dat de update als volledig beschouwd wordt. Opmerking: Alle commando s, met uitzondering van het File commando, worden beantwoord door de cliënt met een status bericht. Het File commando wordt beantwoord et een speciaal FileReceived bericht Continue last update Het is altijd mogelijk dat een update procedure halverwege wordt afgebroken. Dit kan vele redenen hebben, maar het is niet de bedoeling om reeds verzonden files opnieuw te versturen. Als de server kennis heeft van het feit dat er reeds een update gestart is, kan de server deze update voltooien. Als de cliënt geen al gestarte update kan terug vinden, wordt de cliënt verondersteld niets te doen. De status blijft ingesteld op Initialized. Indien er wel een reeds gestarte update bestaat, is de cliënt verplicht om zijn status te veranderen naar ReceivingUpdates. De server zal de status controleren om te bepalen of er kan worden verder gegaan met de vorige update. Indien er kan verder gegaan worden met een vorige update, zal de server de extra variabele die bij de status ReceivingUpdates hoort gebruiken om te bepalen welke files nog moeten worden doorgestuurd New Update Wanneer de server een nieuwe update wenst te starten kan de server het NewUpdate commando versturen. Wanneer dit commando wordt verstuurd, moet de cliënt mogelijke vorige updates verwijderen en een nieuwe tijdelijke update map creëren. 36

49 Status De server kan te allen tijde de status van het update object bij de cliënt opvragen. De cliënt antwoordt hierop met één van de volgende mogelijkheden: Waiting Receiving updates + number of received files Executing Done Error De opties worden bijgehouden in een enumeratie. In het geval van Receiving updates worden er twee velden doorgestuurd. Namelijk Receiving updates + een integer. De status kan enkel veranderen in de zelfde volgorde als opgegeven, met uitzondering van de error status. TABEL 3: THEORIE OPDATE MODULE - STATUS BERICHTEN Optie Waiting ReceivingUpdates Executing Done Error Beschrijving Er is een update object aanwezig dat klaar is om updates te ontvangen Heeft aan dat er reeds updates zijn ontvangen. Deze updates komen terecht in een tijdelijke map. Extra argument: Het aantal files dat al ontvangen is. Deze optie heeft aan dat alle updates zijn ontvangen en dat de server opdracht gegeven heeft om de updates ook effectief door te voeren. De cliënt is nu bezig met het verwerken van de updates. De updates zijn doorgevoerd. Het update object wacht nu om te worden afgesloten. Er is een fout opgetreden, De reeds ontvangen updates zijn verwijderd. Het update proces moet opnieuw worden opgestart. 37

50 File Wanneer de status van de cliënt gelijk is aan ReceivingUpdates, kan de server files versturen. Telkens er een file wordt ontvangen, zal de cliënt hiervoor een bevestiging sturen naar de server. De file heeft als argumenten een locatie waar deze moet worden opgeslagen. Wanneer de map waarin de file moet worden geplaatst niet bestaat, is het de verantwoordelijkheid van de cliënt om deze map te creëren. Files die verstuurd worden wanneer de status niet gelijk is aan ReceivingUpdates, moeten worden genegeerd Folder Het is mogelijk dat er nieuwe folders moeten gecreëerd worden tijdens het update proces. Indien dit het geval is, kan de server dit doen door een Folder commando te sturen. Wanneer er echter ook files in de betreffende folder moeten komen, is de cliënt er zelf voor verantwoordelijk om deze folders te creëren. Het is in dit geval dan niet nodig om zowel een folder commando als een file te versturen. Folders kunnen enkel worden verstuurd wanneer de status van de cliënt gelijk is aan ReceivingUpdates. In alle andere gevallen moet de cliënt deze berichten negeren Do update Met dit commando geeft de server aan dat er geen nieuwe files of folders meer zullen worden verstuurd. De ontvangen files en folders moeten effectief worden geüpdate. De cliënt verandert zijn status eerst in Executing. Wanneer de cliënt klaar is met het updaten, wordt de status opnieuw aangepast naar Done. Ook wordt de server ervan op de hoogte gebracht dat de files zijn geüpdate Close Als laatste stap in het update proces moet de server de client toestemming geven om het update object te verwijderen en de tijdelijke map waarin de updates werden ontvangen te verwijderen. Dit gebeurt met het Close commando. Nadat de server dit commando heeft verstuurd, zal de server ervan uit gaan dat de update volledig uitgevoerd is en het gereserveerde kanaal vrijgeven. 38

51 Get Index Dit commando verplicht de cliënt om alle rootdirectories volledig te indexeren. Dit wil zeggen dat alle mappen, submappen en files in deze mappen moeten worden opgelijst en dat deze lijst moet worden teruggestuurd naar de server. De server gebruikt deze lijst om te vergelijken met de groep waartoe de cliënt behoort en updates te versturen. De index bevat een momentopname van de cliënt. Het is de server die initiatief neemt om de index van de cliënt op te vragen. Dit gebeurt meestal op het ogenblik dat een cliënt zich aanmeldt. Het kan gebeuren dat de server echter een indexering opvraagt nadat een update is doorgevoerd om te controleren of alle files correct zijn geüpdatet. Ook wanneer de laatste indexering reeds lange tijd geleden gebeurd is of als de operator hier expliciet opdracht toe geeft, kan een indexering worden gevraagd Get Directory Het GetDirecory is commando een beperktere vorm van indexeren. Met het getdirectory commando is het mogelijk om vanaf de server de directory informatie van een opgegeven map op te halen, samen met een lijst van mappen en files in deze map. Dit heeft als voordeel dat er minder computertijd nodig is om deze lijst te indexeren en minder bandbreedte om de lijst door het netwerk te sturen Get Root Directory Names Dit commando vraagt de cliënt een lijst door te sturen met de geregistreerde root directories Get File Het GetFile commando kan gebruikt worden om een file te downloaden van de cliënt. Op deze manier is het mogelijk om een file te open op de server File Met het File commando, kan de server een file uploaden naar de cliënt, zonder dit in een update proces te doen. Het is mogelijk om als extra argument de locatie van de file op de server mee te geven. Indien er geen pad wordt opgegeven, zal de cliënt de file in de default downloadmap plaatsen. Het File commando is gelijk aan het sub File commando van het update commando. Alleen de context en dus ook de afhandeling zal hier anders zijn GetDrives Via deze functie wordt de cliënt gevraagd om een lijst te sturen naar de server met de aanwezige drives (vb. c:/ ) Indien de server over een lijst beschikt van alle beschikbare geheugen locaties, kan de server ook al deze locaties gaan onderzoeken. Dit gebeurt weliswaar niet automatisch, maar kan toch gebeuren op aanvraag van de operator. 39

52 H10 MULTI THREADING 10.1 WAT IS (MULTI ) THREADING? Een thread is een soort van proces binnen een proces. De hedendaagse computers gebruiken allemaal multi processing. Dit wil zeggen dat iedere computer verschillende processen tegelijk kan uitvoeren. Hierdoor zijn computers in staat om meerdere programma s zoals Word en Excel tegelijk te draaien. In de praktijk worden deze programma s niet echt tegelijk uitgevoerd, maar wisselt de cpu continue van proces zodat de gebruiker de indruk krijgt dat alle programma s tegelijk werken. Nu is er ook zo iets binnen een programma/proces maar dit wordt dan een thread genoemd. Hierdoor kan een programma verschillende dingen tegelijk kan doen. Er zijn wel enkele verschillen tussen een thread en een proces. Zo zal het OS ervoor zorgen dat verschillende processen elkaar niet kunnen storen, maar zal het OS dit niet doen voor verschillende threads. Dit wil zeggen dat de ontwikkelaar van een multi threaded programma zelf verantwoordelijk is voor een aanzienlijk deel van het geheugen management. Indien dit niet goed is, is het mogelijk dat er na verloop van tijd problemen optreden die zeer moeilijk te debuggen zijn WAAROM MULTITHREADING? Op een bepaald ogenblik is het mogelijk dat een programma te traag wordt om alle functionaliteit op één thread uit te voeren. Dit heeft voornamelijk te maken met het feit dat de UI (User Interface ) tijdens het uitvoeren van lange taken zal blijven hangen. Wanneer een UI blijft hangen wil dit niet noodzakelijk zeggen dat het programma niet meer correct werkt, maar eerder dat de main thread druk bezig is. Dit heeft niet enkel ergernis van de gebruiker tot gevolg, die namelijk in het ongewisse wordt gelaten van de correcte werking van het programma (het programma kan of kan niet gecrasht zijn ). Een vastgelopen UI kan er ook toe leiden dat zelfs het besturingsysteem denkt dat de applicatie is vastgelopen en automatisch beslist om de applicatie af te sluiten, met alle problemen van dien, zoals het niet vrijgeven van resources, half afgewerkte update, et cetera. Een tweede probleem in het geval van een cliënt server applicatie is de response tijd die de cliënt mag verwachten wanneer deze met de server contact opneemt. Wanneer een server slechts met een enkele thread werkt, wordt het zeer moeilijk tot zelfs onmogelijk om te multitasken en dus meerdere cliënts tegelijk te onderhouden. Er wordt echter verwacht van een server dat deze meerder cliënts simultaan kan ondersteunen waardoor de noodzaak zich opdringt threads te ondersteunen. 40

53 Microsoft heeft zelf aan om multi threading te gebruiken wanneer één van de volgende elementen van toepassing is [14]. Communicatie over een netwerk en met een database Uitvoeren van operaties die een langere tijd in beslag nemen Taken met een verschillende prioriteit behandelen. De UI responsief houden PROBLEMEN MET THREADING [15] Threading is echter een niet te onderschatten probleem, die voor vele verwachte en onverwachte problemen kan zorgen, zelfs voor ervaren programmeurs, laat staan voor onervaren programmeurs zoals mezelf. De noodzaak en het belang van threading in webservices wordt dieper behandeld door Wemke van der Weija et al in een artikel over multithreading in web servers. [16]. De onderzoekers behandelen het belang van goed multi threading en stellen een nieuw dynamische thread assignment policy voor. Het spreekt voor zich dat deze masterproef niet zo diep kan ingaan op thread assignment policies, wegens de te beperkte kennis over threads van de onderzoeker, los van het feit dat dit reeds een op zichzelf staande thesis zou kunnen zijn. Toch is het nodig om het belang van threading correct te kunnen inschatten en de problemen ervan te onderkennen alvorens te starten met programmeren GEDEELDE DATA Eén van de meest voorkomende problemen die optreden bij multi threaded applications is dat er altijd wel ergens data zal zijn die mogelijk door meerdere threads tegelijk zou worden gebruikt. Op het eerste zicht lijkt dit misschien niet zo een groot probleem, maar dit is het zeker wel. De reden waarom dit een probleem is, is dat het niet gegarandeerd is dat de data te allen tijde consistent is. Hiermee wordt bedoeld dat één enkele thread data kan aanpassen en dat een andere thread tegelijk deze data probeert aan te spreken. Voorbeeld: Thread A wenst in een variabele naam de waarde Kristof weg te schrijven, maar halverwege deze transactie, probeert thread B deze data uit te lezen. In dit geval is het mogelijk dat thread B de naam Krist uitleest en dus met een verkeerde mogelijk zelfs onbestaande naam probeert verder te werken. 41

54 BEPERKTE RESOURCES Een tweede mogelijke probleem is dat niet alle resources meerdere keren aanwezig zijn op een pc. Zo is het bijvoorbeeld mogelijk dat meerdere threads tegelijkertijd gegevens nodig hebben van de harde schijf. In vele standaard computers is er echter maar één fysieke harde schijf aanwezig, waardoor de processen op elkaar moeten wachten. Het is dus zeker niet zo dat een verdubbeling van het aantal threads de snelheid van het programma twee maal zal versnellen WACHTEN OP EINDE VAN EEN ANDERE THREAD. Een laatste probleem dat in deze context wordt aangehaald is dat het soms nodig is dat een bepaalde actie pas kan uitgevoerd worden wanneer een of meerder andere acties volledig zijn afgehandeld. Stel bijvoorbeeld dat actie A en B gelijktijdig kunnen worden uitgevoerd, maar actie C pas nadat zowel A als B zijn afgewerkt, dan moet er een mechanisme worden ontwikkeld om de nodige synchronisatie te bewerkstelligen. In het eenvoudigste geval is gekend welke actie (A of B ) het langst duurt. In zulk geval wordt actie C pas uitgevoerd nadat de langst durende actie is voltooid. Meestal is het echter niet met zekerheid te bepalen welke functie eerst zal aflopen. Daarom is het noodzakelijk om extra code en bijgevolg ook complexiteit te introduceren. Logisch gevolg is dat de kans op fouten vergroot. 42

55 10.4 LOCKS Het probleem van de gedeelde data kan worden opgelost door gebruik te maken van lock s. Wanneer de programmeur een bepaalde resource lockt, zorgt de CLR ervoor dat andere threads deze resource niet kunnen gebruiken tot het lock opnieuw wordt vrij gegeven. Het plaatsen van een lock vertraagt echter wel de uitvoering van het programma. Het is tot nader order de verantwoordelijkheid van de programmeur om consequent locks te plaatsen. Gebeurt dit niet, dan kan het toch zijn dat een gelockt object aangepast wordt door een andere thread die niet controleert of het object gelockt is DEADLOCK Hoewel locks geïntroduceerd werden om een probleem op te lossen (wat ze ook doen) introduceert het gebruik van locks een nieuw probleem, namelijk deadlock. Een deadlock krijg je wanneer twee (of meerdere ) threads wachten op elkaar. Dit probleem is soms heel moeilijk te ontdekken en soms nog moeilijker op te lossen omdat deadlocks meestal voorkomen door ingewikkelde constructies van locks die in het grotere geheel plotseling een deadlock vormen. Het is meestal ook zeer moeilijk om een deadlock te reconstrueren, omdat deze vaak toevallig plaatsvinden. (Reconstructie kan nodig zijn om de fout te debuggen. ) 10.5 ASSYNCCALLBACK Ook voor het derde opgesomde probleem, namelijk het wachten op andere threads heeft in C# een ingebouwde oplossing. Het is namelijk mogelijk om een AssyncCalback object mee te geven met de standaard geïmplementeerde multi threaded functionaliteit. Het is verder ook mogelijk om deze manier van werken te gebruiken in zelf ontwikkelde asynchrone functies. Op deze manier is het mogelijk om overal consequent dezelfde aanpak te gebruiken THREADPOOL Een threadpool is een verzameling van threads in een proces die kunnen gebruikt worden om taken op uit te voeren. Een threadpool kan gebruikt worden om multithreading binnen een applicatie te beheren. Zo kan er een maximum aantal threads worden vastgelegd, bijvoorbeeld 250 background threads en 1000 I/O completion threads. Dit kan er voor zorgen dat indien er een beperking is op het aantal threads die tegelijkertijd actief kunnen zijn. Er zijn verschillende redenen waarom het aantal threads beperkt moet zijn. In theorie speelt enkel de hoeveelheid geheugen een rol, gezien iedere thread een beperkte hoeveelheid geheugen bezit (voor administratie en de stack ), in de praktijk kost het echter ook tijd om te switchen tussen verschillende threads, waardoor bij een te groot aantal threads de switching kost te groot zou worden. Verder kunnen er ook threads in een threadpool zitten die niet gebruikt worden. De reden niet actieve threads niet onmiddellijk af te sluiten is dat het creëren en verwijderen van threads enige tijd kost (het OS moet geheugen allokeren en enige administratie doen ) is het soms beter om een idle thread te behouden. 43

56 Netwerk Database Update RDB TestPlatform Common Language PRAKTISCHE IMPLEMENTATIE H11 UITWERKING Wat hier volgt is de praktische implementatie. De algemene opbouw van de applicatie en bepaalde stukjes sleutel code worden besproken. Er zijn uiteindelijk twee programma gemaakt: PsiServer & PsiCliënt. Toch zijn beide programma s zeer gelijkaardig opgebouwd. Voor iedere module in de server is er namelijk een host module op de cliënt aanwezig, waarvan de implementatie uiteraard verschillend zal zijn. Geraadpleegde literatuur tijdens de implementatie: [17], [18], [19], [20], [21] en [22] ALGEMENE STRUCTUUR Op onderstaande afbeelding is te zien hoe het project is opgedeeld in verschillende modules. Sommige modules zoals Netwerk, Database & Common language zijn uitgegroeid tot zelfstandige projecten die samengebracht zijn tot één applicatie. Andere modules zoals de Update module en de RDB (Remote DataBase ) module zijn aparte namespaces binnen het model. Zowel PsiCliënt als PsiServer hebben volledig dezelfde layout. APPLICATIE GUI Controller / Model FIGUUR 9: APPLICATIE - ALGEMEEN BLOKSCHEMA 44

57 KORTE VERKLARING VAN DE MODULES GUI De (general ) user interface zorgt voor de communicatie tussen het programma en gebruiker. Deze module kan enkel communiceren met het model en de Database module Model Het model is een DLL die alle applicatie specifieke code bevat. Met uitzondering van de Database module Netwerk module De netwerkmodule is identiek voor beide programma s. Deze class library bied alle functionaliteiten aan om data te kunnen versturen van en naar de server/cliënt. Deze module is ook zo opgemaakt dat deze eenvoudig in andere projecten kan worden hergebruikt Database module Deze module zorgt voor de communicatie met de eigen database van het programma. Zowel de PsiServer als de PsiCliënt applicatie hebben een eigen gegevensset, maar met iets andere tabellen en dus een eigen invulling van de module Update module De update module is geen eigen class library, maar een aparte namespace binnen het model. De module behandelt alle communicatie tussen de cliënt en de server in verband met het indexeren en updaten van de cliënts RDB De Remote DataBase module, afgekort RDB, is in staat om eenvoudige queries uit te voeren op databases die bij de cliënt aanwezig zijn. Het is voornamelijk de bedoeling om de DB van het testsyteem aan te spreken, maar indien er andere DB s staan op de cliënt kunnen deze ook zonder problemen worden aangesproken Testplatform Deze module zorgt voor een link met het test platform. Het is de bedoeling om zo enkele parameters op te vragen die niet in de database staan. Deze module wordt volledig ontworpen door PsiControl zelf. Er zal verder dus ook geen bijkomende informatie worden over gegeven Common Language Deze module is gemeenschappelijk voor beide applicaties en bevat de structuur van de objecten die uitgewisseld kunnen worden. 45

58 MAPSTRUCTUUR De structuur waarop gegevens bijgehouden worden, hangt nauw samen met de structuur van het programma. Daarom kan het geen kwaad om de gegevens structuur eens te bekijken. Links op de figuur staat de install directory (= data directory). Het is in deze map dat de server (standaard ) alle data zal stockeren. De locatie van deze map kan gekozen worden bij het instaleren van het programma, of bij het resetten van het programma. De grote van deze map kan zeer sterk groeien na de installatie. (Meer cliënts, meer groepen, logs,... ) Rechts staat dan de map waarin de exe staat van de applicatie. In deze map staan ook enkele andere bestanden die strikt noodzakelijk zijn voor het opstarten van de applicatie. De totale grootte van deze map verandert na installatie niet meer. Figuur 10: Map structuur Location exe file Deze map bevat de executable en de dll s die het programma nodig heeft. Verder staat hier ook een lege database die dient als model en is er een sub map waarin de afbeeldingen staan die gebruikt worden in het programma. Omdat het programma moet in staat zijn om de locatie van de data terug te vinden is er ook een bestand DBLocation.stt aanwezig die de connectie string van de database bevat. Bij het opstarten kan de applicatie dan de database aanspreken om bijvoorbeeld de locatie van de Install Directory terug te vinden. 46

59 Install Directory Deze map bevat alle data die door het programma gegenereerd en/of beheerd wordt. Een korte beschrijving van de aanwezige mappen: Back-up Deze map is de standaard locatie waar de back-ups geplaatst worden. In principe kunnen de back-ups echter op gelijk welke plaats worden bewaard Bin (Vuilbak ) In deze map worden de bestanden opgeslagen wanneer deze overschreven of verwijderd worden. De bin map heeft als doel om bestanden later eventueel te kunnen herstellen. De oorspronkelijke locatie en het ogenblik waarop de bestanden werden verwijderd, worden in de database bijgehouden. Bestanden krijgen een nieuwe (random) naam en de.file extensie. Mappen die verwijderd worden, worden eerst gecomprimeerd en krijgen de.zip extensie Clients In deze map worden specifieke gegevens van de cliënt bewaard die niet in de database worden bijgehouden. Ook files die geüpload worden naar de server of gedownload worden, kunnen worden terug gevonden in deze map. Verder kan iedere module een eigen map toevoegen in de Cliënt map met de naam van de module om zo extra gegevens bij te houden Groups In de Groups map worden alle groepen bijgehouden. Dit wil zeggen dat iedere groep een eigen map krijgt. In deze map staan dan alle roots van de groep met hun submappen. En bestanden Server In deze map kunnen bestanden worden bijgehouden die specifiek zijn voor de server Settings De settings map bevat de algemeen instellingen van het programma. Hier bevindt zich normaal gezien ook de database. Het gebruik van een database biedt enkele voordelen ten opzichte van zelf gegevens te stockeren in bestanden, zoals een bescherming tegen multithreading (databases kunnen aangesproken worden vanop verschillende threads.). Databases zijn ook ontwikkeld met het oog om veel data efficiënt bij te houden, beschikbaar te stellen en om met transacties te werken. Verder is de settings map ook de standaard locatie voor het opslaan van de key files. Key files zijn bestanden die de publieke (en eventueel ook de private) sleutel bevatten. Deze files kunnen op verzoek worden gegenereerd door de applicatie en worden zowel door de server als cliënt herkend. Op deze manier kunnen de sleutels uitgewisseld worden. Merk op dat de private sleutel geheim dient gehouden te worden en dus niet zomaar naar de cliënts mag verzonden worden. 47

60 H12 DE NETWERKMODULE 12.1 ALGEMEEN BLOKSCHEMA Een van de belangrijkste modules van deze thesis is de netwerk module. Deze module verzorgt alle communicatie die over het netwerk gebeurt. De volgende afbeelding geeft de verschillende classes weer waaruit de netwerkmodule is opgebouwd. FIGUUR 11: Blokschema van de Netwerk Module Legende Het grijze blok (NETWORK) stelt de algemene module voor, de blauwe blokken stellen verschillende klassen voor, het paars blok (Messages) is een map en de gele blokken zijn abstracte klassen. 48

61 12.2 WERKING VAN DE NETWERK MODULE. Hoewel de verschillende blokken hieronder in detail worden besproken, is het toch belangrijk om eerst een inzicht te krijgen in het idee achter deze module. De module is zo ontwikkeld dat andere modules die gebruik wensen te maken van een netwerk connectiviteit deze module op eenvoudige wijze kunnen gebruiken. Dit wil zeggen dat de interface zo eenvoudig mogelijk moet zijn, maar toch nog veel vrijheid moet bieden en dat de module zelf een groot deel van het werk op zich moet nemen in verband met het beheer van de verschillende verbindingen (authentiseren, encrypteren, pollen naar data, et cetera ) Modules die gebruik wensen te maken van deze module, zullen enkel te maken krijgen met zes van de blokken die op het schema staan afgebeeld. Dit zijn in eerste plaats de cliënt, server en properties blokken en in tweede plaats de drie bericht types namelijk tekst, object en file. De andere blokken zijn verborgen voor externe modules en worden intern gebruikt om de verschillende verbindingen te beheren. Dit om de interface zo eenvoudig mogelijk te maken ALGEMEEN Alle communicatie die over het netwerk gebeurt, gebeurt in de vorm van berichten. Alle mogelijke berichten zijn beschreven in de netwerkmodule. Er zijn in totaal zeven verschillende berichten die kunnen worden verzonden. Van deze berichten zijn er drie soorten berichten die door externe modules kunnen worden verzonden en vier types berichten die door de eigen module worden gebruikt om de nodige administratie te doen en de verbindingen te beheren. Het is zo dat wanneer twee applicaties gegevens wensen uit te wisselen, deze berichten altijd gestuurd worden via de cliënt klasse. Dit wil zeggen dat ook aan de server zijde er een cliënt klasse aanwezig zal zijn voor iedere verbinding die de berichten zal versturen en ontvangen. Wanneer een externe module een bericht wenst te versturen, moet deze eerst een keuze maken uit een bericht en daarna dit bericht versturen via de [cliënt].send([message]) functie. Zoals men kan zien is dit vrij eenvoudig. Men heeft enkel een cliënt object nodig en een message object. 49

62 Berichten die worden verzonden door de Netwerk module (private): KeepAlive Authentication Handshake Settings Berichten die worden verzonden door externe modules (public): Text Object File Opmerking: Het is zo dat de netwerk module uit zichzelf nooit publieke berichten zal versturen en omgekeerd, dat externe modules niet in staat zijn om interne ( private ) berichten te versturen. FIGUUR 12: NETWORK - DATA FLOWS 50

63 VERKLARING BLOKSCHEMA Figuur 4 heeft een blok schematisch beeld weer van hoe data (messages) tussen twee applicaties heen vloeit. De figuur stelt in dit geval een server voor die verbonden is met vier verschillende cliënt applicaties (waarvan er slechts twee staan afgebeeld). De server zelf geeft twee modules (A & B) die gebruik maken van dezelfde server. Er is te zien dat de eerste klasse van mod. A in verbinding staat met drie verschillende cliënts en dat mod. B drie klasses heeft waarvan er twee elk met één cliënt communiceren en waarvan één klasse data uitwisselt met de server klasse. De reden waarom class 4 van mod B rechtsreeks met de server communiceert, zou bijvoorbeeld kunnen zijn om gegevens op te vangen die blijkbaar door geen enkele cliënt worden opgevangen. Dit wil zeggen dat class 4 alle algemene berichten opvangt van alle cliënts die de server onderhoud. Gezien de mogelijkheid bestaat om ook op de server een band te leggen met één bepaalde cliënt, maakt het eenvoudig om sessies op te stellen. Men weet immers dat alle data die via die cliënt binnenvloeit van de zelfde cliënt afkomstig is. Er is ook te zien dat het perfect mogelijk is dat verschillende objecten/klassen met eenzelfde cliënt communiceren. De data kan indien gewenst ook via verschillende kanalen worden verstuurd, zodat beide klasses de verbinding kunnen gebruiken zonder rekening te moeten houden dat sommige berichten voor een andere klasse bestemd zijn. Opmerking: de messages die uitgewisseld worden tussen mod A( ), B( ) en de Netwerk module, zijn altijd publieke berichten. Tussen twee cliënts kunnen alle bericht types verzonden worden. 51

64 12.4 BERICHTEN BASE MESSAGE De abstracte klasse clsbasemessage bevat twee velden. Het eerste veld ID is van het type integer en het tweede veld is een enumeratie van het type protocol. Alle andere berichten erven van deze klasse. Het protocol enumeratie bevat de volgende waarden Handshake Authentication Setting Hartbeat (alias KeepAlive ) Message Het protocol veld wordt gebruikt om bij ontvangst van een bericht gemakkelijk te kunnen nagaan hoe het bericht moet worden afgehandeld. Het valt op dat alle private berichten een eigen protocol type hebben en dat alle publieke berichten onder de noemer Message vallen. Dit is zo omdat de Base Message klasse voornamelijk dient ter ondersteuning van de Socket klasse. Indien het protocol type gelijk is aan Message, dan weet de Socket klasse dat het bericht moet worden doorgespeeld naar de bovenliggende cliënt klasse om daar afgehandeld te worden. Alle andere protocollen worden binnen de socket klasse afgehandeld PRIVATE BERICHTEN Handshake Het handshake bericht wordt enkel verstuurd bij het opstarten van de verbinding. De server neemt het initiatief en de cliënt antwoordt. Wanneer de server het antwoord van de cliënt ontvangt, is dit het teken voor de server om de authentificatie procedure te starten. Het handshake wordt gebruikt om te bepalen met welke cliënt de server verbonden is. De server zelf stuurt voor de volledigheid ook zijn eigen gegevens naar de cliënt. Wanneer beide partijen weten met wie ze verbonden zijn, kan deze informatie gebruikt worden om de juiste publieke sleutel op te vragen. Velden van het handshake bericht: Settings (Network.Messages.clsSettings) Het Handshake bericht bevat slechts één veld waarin een Settings bericht geïncapsuleerd worden. Dit omdat settings berichten op zich niet kunnen worden verzonden voor de verbinding is vrijgegeven door de authentification service. Het is zo dat zolang de verbinding niet is vrijgegeven er enkel Handshake en Hartbeat berichten (en Authentification berichten) kunnen worden verstuurd. Alle andere berichten worden tegengehouden. 52

65 CODE 5: IMPLEMENTATIE VAN DE HANDSHAKE KLASSE namespace Network.Messages { [Serializable] public class clshandshakemessage :clsbasemessage { //VAR clssettingsmessage _settings; //INIT public clshandshakemessage(clssettingsmessage MySettings): base(messageprotocol.handshake,1) { _settings = MySettings; //PROPERTY public clssettingsmessage Settings { get { return _settings; Auhtentification Authentificatie berichten worden gemaakt, verstuurd en behandeld door de klasse clsauthentificationservice. Deze berichten bevatten de volgende velden Step (enum: AuthenticationStatus) ClientName (string) KeySize (integer) SessionKey (byte array) ServerToken (byte array) ClientToken (byte array) Het veld Step duidt aan in welke fase de verbinding zich bevindt en kan de waarde Pending, Authenticated en Failed hebben. ClientName wordt gebruikt voor het eventueel opvragen van de sleutels en de keysize bepaalt de lengte van de tokens. De session key kan een symmetrische sleutel bevatten en de laatste twee velden bevatten de tokens van respectievelijk de server en de cliënt. 53

66 Settings Settings berichten worden verstuurd om algemene instellingen en administratie te verzorgen nadat de verbinding in gebruik is genomen. Deze berichten kunnen de sessie sleutel wijzigen Velden van het settings message Name (string) Group (string) Country (string) MinKeySize (int) NewSessionKey (byte array) ClosingConnection (boolean) CloseChannel (boolean) ChannelID (integer) Done (boolean) De eerste drie velden ( Name, Group & Country ) zijn optioneel. De naam wordt gebruikt bij het authentificeren en moet dus verplicht worden opgegeven bij het initialiseren van de verbinding. De twee andere velden, zijn puur informatief. Het MinKeySize veld heeft aan welke de minimum lengte is van sleutel en met het NewSessionKey veld kan dan de sessie sleutel worden aangepast. De ontvanger zal na ontvangst alle verdere berichten ontsleutelen met de nieuwe sessie sleutel. ClosingConnection wordt gebruikt om de partner ervan op de hoogte te brengen dat de verbinding zal worden verbroken op een normale manier (dus niet wegens een error ). De Socket klasse kan deze berichten versturen en zal daarna nog een kleine tijd wachten alvorens de verbinding ook effectief te sluiten. Op deze manier krijgt het bericht de kans om ook effectief verstuurd te worden. Het is wel zo dat de Socket niet zal controleren of dit bericht ook effectief verstuurd is en niet op een antwoord zal wachten om de verbinding te verbreken. (Het bericht wordt achteraan de buffer toegevoegd en kan daar nog steeds zitten op het ogenblik dat de verbinding wordt afgesloten. ) De laatste drie velden worden gebruikt om de channels te beheren. Een kanaal kan worden afgesloten door het CloseChannel veld op true te plaatsen het ID van het kanaal mee te geven. Dit bericht zal resulteren in een antwoord bericht waar CloseChannel en ChannelID dezelfde waarden zullen behouden, maar waar het Done veld ook op true zal geplaatst worden. Opmerking: Het aanmaken van kanalen gebeurt simpelweg door een bericht te versturen over het kanaal. Dit wil zeggen door in het Channel veld het ID van het kanaal te plaatsen. 54

67 Hartbeat Hartbeat berichten worden gebruikt om de verbinding te testen. Standaard worden er geen berichten verzonden wanneer er geen data te versturen valt. Dit wil zeggen dat de socket totaal niet kan weten of de partner beschikbaar is of niet. Wanneer het nodig zou zijn om dit toch na te gaan, moet er gepolld worden door effectief data te (proberen) versturen. Uiteraard is het niet de bedoeling om veel data te versturen en moeten deze berichten zo klein mogelijk gehouden worden. Daarom bestaat dit type uit slechts een variabele Answer. Door dit veld op true te plaatsen, kan gevraagd worden om het Hartbeat bericht te beantwoorden met een nieuw Hartbeat bericht (waarbij het answer veld false is ). De reden waarom bevestiging gevraagd wordt is om er zeker van te zijn dat ook de verbinding met de applicatie nog werkt. Indien de bovenliggende applicatie in de problemen zou zitten, zal een poging om een antwoord te versturen er misschien toe lijden dat er een error gegenereerd wordt die op zijn beurt de verbinding afsluit, waardoor bij een volgend Hartbeat bericht een probleem gedetecteerd wordt. Dit zou er dan toe moeten leiden dat de verbinding gereset wordt en er enkele objecten opnieuw geïnitialiseerd worden. Uiteindelijk zou de applicatie als het ware gereset worden en terug functioneren. 55

68 FIGUUR 13: PRIVATE BERICHTEN 56

69 PUBLIEKE BERICHTEN Publieke berichten zijn berichten die worden verzonden tussen gebruikers van de netwerk module. Een voorbeeld van hoe publieke berichten kunnen worden gemaakt en verzonden kan terug gevonden worden in H abstract Alle publieke berichten erven van de abstracte klasse clsmessage. Deze klasse biedt enkele algemene functionaliteiten die voor alle publieke berichten van toepassing zijn. Deze klasse erft op zijn beurt van de abstracte klasse clsbasemessage, die hierboven reeds besproken werd. Er zijn slechts drie velden gedefinieerd in deze klasse, maar dit zijn dan wel zeer belangrijke velden die doorheen de applicatie intensief gebruikt worden en bedoeld zijn om snel een communicatie protocol te kunnen opstellen. De velden zijn als volgt: ARG (list<string>) [ARGuments] Channel (integer) ConversationCounter (integer) Het argument veld is misschien wel een van de handigste velden van deze klasse. Vooral door de uitgebreide functies die beschikbaar zijn gemaakt om dit veld in te vullen of te onderzoeken. Dit kan ook worden afgeleid uit de interface waar duidelijk veel functies in verband met het argument veld aanwezig zijn. Argumenten worden gezien als strings (tekst) die meestal, maar niet verplicht zal bestaan uit een sleutel en een waarde, gescheiden van elkaar door de volgende sequentie : (spatie dubbelpunt - spatie ) Hoewel hiervan kan worden afgeweken is dit hoe de standaard functies verwachten hoe de argumenten zijn opgebouwd. 57

70 Code 6: IclsMessage interface IclsMessage { int Channel { get; set; uint ConversationCounter { get; set; List<string> Arguments { get; set; void AddArgument(string Arg); void AddArgument(string Key, string value); string CreateArgument(string Key, string value, string splitter); string CreateArgument(string Key, string value); string GetArgumentKey(string Argument); string GetArgumentKey(string Argument, string splitter); string[] GetArgumentsByKey(string Key); string GetArgumentValue(string Argument); string GetArgumentValue(string Argument, string splitter); string GetValue(string Key); string Name { get; set; string ToString(); Opmerking: In code 6 kan er wat verwarring zijn omtrent het verschil tussen verschillende functies zoals GetValue(...) en GetArgumentValue(...), omdat de commentaren hier niet bijgeplaatst zijn. Het is zo dat de GetValue(...) functie zal zoeken in de argumenten lijst naar een argument met de opgegeven sleutel en daarvan de waarde zal weergeven terwijl de GetArgumentValue functie, de waarde zal opleveren van het opgegeven argument, eventueel gebruik makend van een opgelegde splitter sequentie. Het tweede veld Channel wordt gebruikt om data over virtuele kanalen te kunnen versturen. Dit is een functionaliteit die enkel bestaat voor publieke berichten. De private berichten kunnen hier geen gebruik van maken, maar dit is ook niet nodig gezien deze enkel dienen voor algemene berichten die op de verbinding in zijn geheel gaan. Het laatste veld ConversationCounter kan uiteindelijk gebruikt worden om berichten een uniek nummer mee te geven. De Message klasse heeft hier zelf echter geen invulling aan. Indien een cliënt dit veld wenst te gebruiken is deze zelf verantwoordelijk voor de invulling. 58

71 Object Het meest algemene bericht dat verzonden kan worden is het Object bericht. Het is mogelijk om gelijk welk object te versturen met deze berichten op voorwaarde dat het object serializable is. Verder zijn er absoluut geen beperkingen behalve dan misschien dat de klasse beter geen events bevat [23] gezien dit hoogst waarschijnlijk tot problemen zal leiden. Het object bericht type bevat slechts één veld: Body (object) Text Het tweede type publiek bericht is het Text type. Dit bericht werd gemaakt om op een eenvoudige manier de basis te kunnen aanbieden, namelijk het versturen van pure tekst. Eigenlijk is dit volledig gelijk aan het object bericht, maar dan met een beperktere input. Velden van het tekst bericht Value (string) File Het File bericht is het meest gespecialiseerde publieke bericht. Het werd speciaal ontwikkeld met het oog op geheugen management. Gezien de aard van de applicatie (bestanden versturen ) is de kans nogal groot dat er vroeg of laat meerder grote bestanden zullen moet worden verstuurd. Wanneer dit zou gebeuren in de vorm van een object bericht zou dit willen zeggen dat het bestand eerst zal moeten worden uitgelezen en in een byte array geplaatst worden. Deze byte array kan bijvoorbeeld de Body van het object bericht vormen. Dit wil echter wel zeggen dat het volledige bestand in het RAM geheugen moet worden ingeladen voor het verzonden wordt. Dit zou nu geen zodanig groot probleem zijn als men er zeker van zou kunnen zijn dat het bericht onmiddellijk daarna zal worden verzonden. Die zekerheid is er echter niet. Dit komt door de werking van de netwerk module, waar ieder bericht achteraan de buffer wordt toegevoegd die werkt met een FCFS principe (First Come First Serve). Dit wil zeggen dat als er reeds enkele grote berichten in de wachtrij zijn het RAM geheugen zwaar en nodeloos belast zal worden. Het zou beter zijn om de bestanden pas in te laden op het laatste ogenblik, namelijk vlak voor het bericht verzonden wordt. Dit kan echter enkel wanneer de Socket klasse die het eigenlijke zendwerk op zich neemt dit ook ondersteunt. Deze ondersteuning is er dus in de vorm van een speciaal File bericht. 59

72 Velden van het file bericht: Info (System.IO.FileInfo) File (byte array) CRC (integer) Het eerste veld bevat een object van het type FileInfo. Dit object zit standaard in de.net omgeving en houdt heel wat informatie bij over een bestand. Bij het initialiseren van een File bericht moet er een FileInfo object worden meegegeven, waarbij onmiddellijk zal worden gecontroleerd of het betreffende bestand ook effectief bestaat. Indien dit niet het geval is zal er een error worden gegenereerd. Bij het versturen van een File bericht zal de Socket klasse eerst controleren of de file reeds is ingeladen. Dit gebeurt door te controleren of het veld File <null> is of niet. Indien de file nog niet ingeladen is, dan wordt dit dan gedaan. Merk op dat het wel degelijk mogelijk is om een bestand eerder in te laden. Bijvoorbeeld wanneer de zender er niet zeker van is of het bestand nog steeds zal bestaan op het ogenblik dat het bericht ook effectief verzonden wordt. Door het bestand zelf in te laden wordt er echter wel een stuk afbreuk gedaan aan de oorspronkelijke redenen voor dit berichttype. Het laatste veld CRC wordt gebruikt om een speciale crc code mee te sturen om de correctheid van de ontvangen data te kunnen controleren bij ontvangst. Deze code werd niet zelf ontwikkeld, maar bestond al en is gekopieerd van Psi Control. De CRC wordt automatisch berekend bij het laden van de file, maar wordt niet automatisch gecontroleerd bij het ontvangen van het file bericht. 60

73 FIGUUR 14: PUBLIEKE BERICHTEN 61

74 12.5 SERVER De Server klasse wordt gebruikt om te luisteren naar binnenkomende oproepen. Wanneer de server een nieuwe TCP verbinding accepteert, wordt deze ingekapsuleerd in een cliënt klasse. Verder initieert de server de handshake procedure en op deze manier ook de authentificatie procedure. Cliënt klasses kunnen op zich geen nieuwe (binnenkomende) verbindingen accepteren. De server houdt een lijst bij van de verschillende aangemelde cliënts en een aparte lijst voor nog niet geauthentificeerde cliënts. Verder luistert de server naar de verschillende events van de cliënts om zo op de hoogte te blijven van de status van de cliënts. Deze lijsten kunnen ook gebruikt worden door externe klasses die willen weten welke Cliënts er allemaal zijn aangemeld, of een handle willen krijgen van een specifieke cliënt. Verder heeft de server ook een onkeyrequest event om de sleutels te kunnen opvragen van cliënts die zich willen aanmelden CLIËNT De Cliënt klasse is de interface tussen externe modules en de (abstracte ) Socket klasse. Een cliënt kan op twee manieren geïnstantieerd worden. Een eerste manier is door een externe klasse, die een verbinding wil maken met een server. In dit geval moet de poort en het IP adres van de server worden opgegeven. De tweede maner waarop een cliënt kan worden geïnitieerd is door de server wanneer deze een nieuwe connectie aanvaard. De cliënt klasse is verantwoordelijk voor het genereren van de events bij problemen of wanneer er nieuwe data ontvangen wordt. NewData events kunnen ook worden gebonden aan één specifiek kanaal. Indien echter geen enkele instantie gevolg geeft aan dit event, zal er ook een algemeen NewData event worden afgevuurd SOCKET De Socket klasse bevat alle intelligentie om berichten van het type clsbasemessage te versturen en te ontvangen. Verder worden er ook een aantal extras aangeboden die niet strikt noodzakelijk zijn, maar eventueel wel handig kunnen zijn om de gebruiker enige response te geven. Een voorbeeld hiervan is het opvragen van de naam van het bericht dat momenteel wordt verzonden. (Dit kan worden ingesteld bij het aanmaken van een bericht) en de vooruitgang die geboekt is bij het verzenden of ontvangen van een bericht (percentage ). 62

75 ONTVANGEN Het ontvangen gebeurd door op regelmatige basis te pollen naar data. De procedure staat afgebeeld op Figuur 15: Blokschema Pollen. De relevante code is ook toegevoegd in Code 7, Code 8: Function ReceiveMessage, Code 10: function RetrieveData & Code 9: Function GetBytes FIGUUR 15: BLOKSCHEMA POLLEN 63

76 Bij het ontvangen zijn er een aantal dingen zeer belangrijk. Het belangrijkste waarop gelet moet worden is dat de ontvanger de Poll procedure geen twee keer tegelijk mag aanroepen ( uitvoeren ). Gezien er met multithreading gewerkt wordt, kan dit in principe wel gebeuren. De kritische code (die de network stream aanspreekt ) moet dus beschermd worden met een lock statement. Door een lock statement te gebruiken, kan verhinderd worden dat de code op twee verschillende threads tegelijk wordt uitgevoerd, maar niet dat de code zal worden opgeroepen. Men moet er namelijk vanuit gaan dat het ontvangen van een bericht langer kan duren dan het interval van de timer. Om die reden moet de timer zo snel mogelijk worden gepauzeerd en mag deze pas opnieuw worden gestart nadat de volledige procedure is doorlopen. Men kan zich nu de vraag stellen hoe een tweede Poll procedure kan worden opgeroepen voor de vorige oproep afgehandeld is. Dit komt omdat een timer tick event op een background thread zal worden uitgevoerd. Wanneer er een nieuw tick event komt, zal deze een nieuwe thread creëren waar de code wordt uitgevoerd. Het is echter niet omdat de background thread werd aangemaakt dat deze ook onmiddellijk wordt uitgevoerd. Het is zo dat het programma maar een beperkt aantal threads ter beschikking heeft die gelijktijdig kunnen worden uitgevoerd (beheerd door een thread pool ) wanneer het programma reeds veel threads aan het uitvoeren is, kan het zijn dat een nieuwe thread in een wachtrij wordt geplaatst tot de vorige threads zijn afgelopen. Het kan dus gebeuren dat het zodanig druk is zodat de thread van de vorige oproep nog niet is gestart wanneer het interval van de timer afgelopen is. Op dat ogenblik zal er achteraan de wachtrij een tweede thread worden toegevoegd die dezelfde Poll procedure zal willen uitvoeren. Stel nu dat tijdens het volgende interval van de timer er veel van de active threads klaar zijn met hun opdracht, dan kunnen beide Poll procedures bijna tegelijk worden gestart. Beiden zullen proberen de timer te pauzeren en de data binnen te lezen, één van beide threads zal echter blokkeren dankzij het lock statement, tot de eerste thread de poll procedure volledig doorlopen heeft. 64

77 Code 7: Poll Function private void Poll() { //Stop timer if (!PauzeTimer()) return; //on error resume with normal procedure. try { object ReceivedMessage = null; bool IsEncrypted = false; lock (LockReceiving) { if (!_tcpclient.connected) { ContinueTimer(); return; ; NetworkStream Stream = _tcpclient.getstream(); //Is there data available (and can it be read?) if (Stream.CanRead && Stream.DataAvailable) { //Receiving IsReceiving = true; //Read incomming message ReceivedMessage = ReceiveMessage(Stream, ref IsEncrypted); //End receiving IsReceiving = false; if (ReceivedMessage!= null) HandleMessage(ReceivedMessage, IsEncrypted); catch { //Continue timer ContinueTimer(); 65

78 Code 8: Function ReceiveMessage private object ReceiveMessage( NetworkStream Stream, ref bool IsEncrypted) { //Get the header byte[] Header = GetBytes(Stream, 12); //Checks if the header is valid (error detection) -> // throws an exception on error detection CheckHeader(Header); //Get header parameters int DataLenght = (int)getdatalenght(header); IsEncrypted = IsEncryptedMessage(Header); //Receive Data: return RetrieveData(Stream, DataLenght, IsEncrypted); CODE 9: FUNCTION GETBYTES private byte[] GetBytes(NetworkStream Stream, int number) { //number of bytes that are correctly received int ReceivedBytes = 0; //the buffer used to store those bytes. byte[] Buffer = new byte[number]; //Read all bytes. while (ReceivedBytes < number) { ReceivedBytes = ReceivedBytes + Stream.Read( Buffer, ReceivedBytes, number - ReceivedBytes); return Buffer; 66

79 Code 10: function RetrieveData private object RetrieveData( NetworkStream Stream, int DataLenght, bool IsEncrypted) { using (MemoryStream MS = new MemoryStream(DataLenght)) { //initialize: int index = 0; int packetsize = packetsize(datalenght); //read data: while (index < DataLenght) { //make the packet size smaller if nessesary: if ((index + packetsize) >= DataLenght) packetsize = DataLenght - index; //Write the received data in a memory stream MS.Write(GetBytes(Stream, packetsize), 0, packetsize); //update index index = index + packetsize; //Update progress SetReceivingProgress(DataLenght, index); //Decrypt message if requierd if (IsEncrypted) { byte[] data; //Derypt the message. data = clssecurity.decrypt( MS.ToArray(), ReceiveSessionKey); MS.Position = 0; MS.Write(data, 0, data.length); //Deserialize message MS.Position = 0; return DeserializeMessage(MS); 67

80 VERZENDEN Het verzenden van berichten gebeurt door deze eerst in een buffer te plaatsen en indien de Socket niet aan het zenden is, de send() functie op te roepen. Het verzenden zelf gebeurt op een nieuwe thread om de thread die het bericht wil versturen niet te blokkeren. Zie Figuur 16: Blokschema Start sending procedure. Eenmaal de Socket aan het zenden is, zal deze alle berichten in de buffer onmiddellijk na elkaar versturen. Het verzenden gebeurt volgens de volgende schema: blokschema sending procedure. Op de figuur is te zien dat de Socket klasse bij het verzenden inderdaad een speciale ondersteuning heeft aan File berichten, zoals eerder gezien. Enkel publieke berichten en settings berichten kunnen worden geëncrypteerd. In de praktische uitwerking is de versleuteling van de publieke berichten uitgeschakeld op vraag van Psi Control, omdat dit een vertraging zou betekenen die in dit geval volledig overbodig is gezien alle verkeer op het eigen netwerk blijft. Settings berichten hebben echter een speciale property die de Socket kan verplichten om het bericht toch te versleutelen, ook als de algemene versleuteling is uitgeschakeld. Uit de figuur kan ook duidelijk worden afgeleid dat de header bytes nooit worden geëncrypteerd. FIGUUR 16: BLOKSCHEMA START SENDING PROCEDURE 68

81 FIGUUR 17: BLOKSCHEMA SENDING PROCEDURE 69

82 CODE 11: FUNCTION SENDMESSAGE private void SendMessage() { lock (LockSending) { lock (LockParameters) { _issending = true; clsbasemessage message = GetNextMessage(); while (message!= null) { try { SendingProgress = 0; SendingMessageName = message.tostring(); if (message is clsmessagefile) message = LoadFile(message as clsmessagefile); byte[] Data = SerializeMessage(message); bool IsEncrypted = false; if (message is clskeepalivemessage) goto labela; if (message is clsauthenticationmessage) goto labela; if (message is clssettingsmessage) if (((clssettingsmessage)message).encryptthismessage == false) goto labela; if (Encrypt) Data = EncryptMessage(ref Data, ref IsEncrypted); if (message is clssettingsmessage) { if ((clssettingsmessage)message).encryptthismessage == true & IsEncrypted == false) Data = EncryptMessage(ref Data, ref IsEncrypted); labela: byte[] Header = CreateMessageHeader( (long)data.length, IsEncrypted); SendBytes(ref Header, ref Data); catch(exception ex) { message = null; RemoveMessage(); message = GetNextMessage(); lock (LockParameters) { _issending = false; 70

83 Header Om ervoor te zorgen dat de ontvanger weet hoe lang het bericht is, moet er een aantal header bytes verzonden worden voor dat de echte data wordt verzonden. De header is hier altijd 12 bytes groot en bevat de lengte van het bericht, een byte die aangeeft of het bericht versleuteld is (met de sessie sleutel ) en een kleine checksum. In Code 12 staat de code die de header genereert. De eerste twee bytes zijn vastgelegd en moeten altijd dezelfde waarde hebben, dit gebeurt om de geldigheid van de header te testen. De volgende acht bytes bevatten de lengte van de data, exclusief de header lengte. Daarna volgt er nog één byte die aanduidt of de data versleuteld is en een byte die een korte checksum is van de eerst elf header bytes. Code 12: Function CreateMessageHeader private byte[] CreateMessageHeader(long StreamLenght, bool IsEncrypted) { //bitconverter.getbytes(long) heeft een array weer van 8 bytes. byte[] Lenght = BitConverter.GetBytes(StreamLenght); byte[] header = new byte[12]; //First 2 bytes: always the same header[0] = byte.parse("127"); header[1] = byte.parse("255"); //Next 8 bytes: Lenght of the message header[2] = Lenght[0]; header[3] = Lenght[1]; header[4] = Lenght[2]; header[5] = Lenght[3]; header[6] = Lenght[4]; header[7] = Lenght[5]; header[8] = Lenght[6]; header[9] = Lenght[7]; //Next byte : indicates wheter the message is encrypted or not. if(isencrypted) header[10] = 0x0f; // <- ' ' else header[10] = 0xf0; // <- ' ' //Next byte: simple error detection byte //-> error detected : close connection. int i = 0; header[11] = 0; while (i < 11) { header[11] += header[i]; i++; return header; 71

84 CHANNEL De cliënt biedt ook de mogelijkheid om berichten te versturen over een virtueel kanaal. Ieder kanaal heeft zijn eigen onnewdata event. Wanneer er data toekomt op een kanaal waarop niemand zich heeft ingeschreven, zal het algemeen onnewdata event worden opgeroepen. Het moet worden opgemerkt dat de data die via verschillende kanalen wordt verstuurd, uiteindelijk toch over dezelfde TCP verbinding zal worden verstuurd. Dit wil zeggen dat wanneer één kanaal een groot bericht verstuurt alle andere kanalen zullen moeten wachten tot dit bericht verzonden is alvorens hun bericht aan de beurt kan komen. Kanalen worden geïdentificeerd door een nummer (ID) en worden enkel gebruikt voor publieke berichten. Het kanaal met ID = 0 (nul) is het algemeen kanaal. De ID s waarvan de absolute waarde in het interval [1 : 20] ligt zijn gereserveerd voor speciale kanalen. Deze kanalen kunnen na initialisatie niet meer worden vrijgegeven. Kanalen met een ID boven de 20 zijn geïnitieerd door de server, kanalen waarvan het ID kleiner is dan -20 zijn geïnitieerd door de cliënt. Cliënt en Server hebben dus elk een eigen ID range die de administratie gemakkelijker maken. Een kanaal kan worden gereserveerd door de functie [clsclient]. GetChannel() op te roepen. Deze functie geeft een object weer dat kan gebruikt worden om in te schrijven op het onnewdata event van het kanaal en om het ID van het kanaal te achterhalen. Dit ID heb je nodig om uiteindelijk berichten te versturen over het kanaal. Wanneer de cliënt een kanaal reserveert, zal de server hiervan initieel niet op de hoogte gebracht worden. Het is pas nadat de server een eerste bericht ontvangt over dat kanaal dat de server zelf een eigen instantie van het kanaal zal onderhouden. Bij het afsluiten, wordt de server hier echter wel van op de hoogte gebracht. De server zal het afsluiten van een kanaal bevestigen en pas dan wordt het kanaal opnieuw vrijgegeven. Opmerking: De Socket klasse heeft zelf geen weet van de verschillende kanalen die gebruikt worden. 72

85 12.7 NETWERK PROPERTIES De netwerk properties klasse is bedoeld om algemene informatie over het netwerk beschikbaar te stellen. De klasse kan bijvoorbeeld een event afvuren wanneer de beschikbaarheid van een netwerk interface verandert. Gezien deze klasse algemene functie aanbiedt zijn alle functies static gedeclareerd. Functies van de Properties klasse zijn: GetIpAdress FilterIpAdress HostName LocalIPs IsLocal DomainName GetActiveTcpConnections GetActiveTcpListners Interfaces IsAvailable Statistics 73

86 12.8 AUTHENTIFICATION De authentification klasse, biedt de mogelijkheid (service ) om te controleren of een cliënt ook effectief is wie hij zegt te zijn. Hiervoor wordt gebruik gemaakt van Public-key cryptography, waarbij ervan uit gegaan wordt dat cliënt en server elkaars publieke sleutel kennen. Wanneer de cliënt verbinding maakt met de server zal de server naar de identiteit van de cliënt peilen door een handshake bericht te versturen. Wanneer de server de naam van de cliënt kent kan daarmee de bijhorende publieke sleutel uit de database worden gehaald. Nu de publieke sleutel gekend is, gebeurt de authentificatie als volgt: 1) Aanmaken van een (symmetrische) sessie sleutel (SK) 2) Aanmaken van een random token 3) Versleutelen van de sessie sleutel met de publieke sleutel van de cliënt 4) Versleutelen van de token met de sessie sleutel 5) Versturen van de token naar de cliënt Wanneer de cliënt het eerste Authentifcation bericht (AM) ontvangt van de server, zal deze een eigen instantie van de Authentification service (AS) creëren. Hiervoor wordt de publieke sleutel van de server opgehaald uit de database van de cliënt. De verdere verwerking van het AM bericht gebeurt als volgt: 1) De cliënt ontsleutelt de sessie sleutel 2) De sessie sleutel wordt gebruikt om de token van de server te ontsleutelen 3) De cliënt maakt zelf een cliënt token aan 4) De cliënt maakt een tijdelijke (symmetrische) sleutel aan (TK) 5) De cliënt versleutelt zijn eigen token en de token van de server met TK 6) De cliënt versleutelt TK asymmetrisch met de publieke sleutel van de server 7) De cliënt genereert een nieuw AM bericht met daarin de versleutelde TK en de versleutelde tokens. 8) Het nieuwe AM bericht wordt verstuurd naar de server. Nu de server een antwoord ontvangt van de cliënt wordt dit door de AS van de server behandeld. Waardoor de volgende stappen worden doorlopen: 1) De server ontsleutelt de TK met de eigen private sleutel. 2) De server ontsleutelt de tokens met TK 3) De server vergelijkt de ontvangen server token met de verzonden token 4) Indien de twee tokens niet gelijk zijn, wordt er een fout bericht verzonden naar de cliënt en wordt de verbinding verbroken. Indien de twee tokens gelijk zijn aan elkaar, aanvaardt de server de verbinding en stuur de server de cliënt token (versleuteld met de sessie sleutel) terug naar de cliënt. 74

87 Nu kan de cliënt twee berichten ontvangen: een fout bericht, waardoor ook de cliënt alle resources vrijgeeft en eventueel een tweede poging onderneemt, of de cliënt ontvangt een AM bericht en voert de volgende stappen uit: 1) Ontsleutelen van de (cliënt) token met de sessie sleutel 2) Vergelijken met de verzonden token 3) Indien beide tokens niet gelijk zijn, verbreekt de cliënt de verbinding en probeert eventueel opnieuw. In het andere geval, accepteert de cliënt de verbinding ENCRYPTION De encryption (versleuteling ) klasse werd ontwikkeld om alle taken die te maken hebben met het encryptie op zich te nemen en om zo de Authentification & Socket klasse te ontlasten. De klasse is in staat om RSA & Rijndael sleutels te genereren en om byte array s te versleutelen en te ontsleutelen met deze sleutels. Het RSA algoritme is enkel in staat om kleine byte array s te versleutelen ter grote van de sessie sleutel, maar werkt niet voor grotere array s. Het Rijndael algoritme genereert echter geen problemen met grotere byte array s en werkt ook een stuk sneller dan RSA. Opmerking: De standaard keysize van de RSA sleutels is 1024 bits MONITOR De monitor klasse is een vrij eenvoudige klasse, die op regelmatige wijze de verbinding test en een bericht verstuurt over de verbinding indien deze een tijdje ongebruikt is. Wanneer de verbinding verbroken is, zal de Socket klasse dit detecteren op het ogenblik dat deze het hartbeat bericht verstuurt. (ook wel keepalive bericht genoemd ) 75

88 H13 DATABASE MODULE De database module verzorgt de communicatie tussen de applicatie en de eigen database. Ongeveer alle informatie wordt bijgehouden in de database en bijna alle modules communiceren rechtstreeks met de database. Dit wil dan ook zeggen dat dit een vrij belangrijke module is in de applicatie WAAROM EEN DATABASE Wanneer er geen database zou gebruikt worden, zou het enige alternatief zijn om alle data te bewaren in bestanden die volgens eigen regels en inzicht zouden zijn opgemaakt. Dit is uiteraard perfect mogelijk door bijvoorbeeld de klasses die belangrijke informatie bevatten te serializeren en het resultaat op te slaan op de harde schijf. Alles in bestanden opslaan heeft echter wel enkele nadelen. Zo moet je constant zeer goed weten waar alles is opgeslagen, wat op zich nog niet zo moeilijk is, maar ook hoe je het er weer (snel ) uit kan halen. Dat laatste is al wat moeilijker te optimaliseren. Verder moet je er ook voor zorgen dat wanneer er naar een bestand wordt geschreven, geen enkele andere thread dit bestand gebruikt. Het OS zorgt hier automatisch voor tussen twee processen, maar de software ontwikkelaar is zelf verantwoordelijk voor deze beveiliging bij multithreading (= binnen een zelfde proces. ) Verder is het zeer moeilijk om er zeker van te zijn dat alle informatie juist is weggeschreven wanneer het programma op een onverwachte wijze zou worden weggeschreven. (bijvoorbeeld door een error) Zo is het mogelijk dat sommige bestanden niet zouden zijn vrijgegeven, waardoor je bij het heropstarten van de applicatie deze bestanden niet meer kan inlezen. Dit kan dan op zijn beurt een fout veroorzaken, waardoor je in een lus belandt die enkel kan worden doorbroken door de computer opnieuw op te starten. Dit is echter al een vrij drastische maatregel, die bij weinig gebruikers geliefd zal zijn. Los van het feit dat het ook daarna mogelijk nog steeds corrupte bestanden zijn VOORDELEN VAN EEN DATABASE Een eerste voordeel van een database is dat het ontwikkeld is door specialisten die hopelijk toch al enige ervaring hebben in verband met geheugenmanagement. Een tweede belangrijker voordeel is dat databases ontworpen zijn om zonder problemen meerdere aanvragen tegelijk te verwerken (= multi threading) en zeer snel data kunnen terugvinden. Verder heb je met databases minder tot geen last van gelijktijdige lees- en schrijfopdrachten en zal er niet snel corruptie optreden van de database door een onverwachte crash van de eigen applicatie. (Tenzij bij foutief gebruik ). 76

89 13.3 STRUCTUUR VAN DE DATABASE De database van de server is opgedeeld in de volgende acht verschillende tabellen UpdateContent Updates Settings Folder Clients Groups Log FileLog OMSCHRIJVING VAN DE TABELLEN UpdateContent Deze tabel bevat de informatie over de bestanden en mappen die tot een update behoren. De tabel houdt bij wat het lokale pad is van de file, wat het target pad is op de cliënt, of het gaat over een bestand of over een map en de status van het record tijdens het updaten (verstuurd, confirmed en het aantal retransmissies (errors)) Updates: Deze tabel houdt algemene informatie bij over een specifieke update. Zo wordt de update gelinkt aan één cliënt en wordt de datum waarop de update werd gegenereerd bijgehouden. Verder zijn er ook enkele booleans die aangeven hoe welke status de update heeft. (in volgorde: AllowExecution, IsStarted, Finished & IsExecuted ) Settings Deze tabel houdt instellingen bij ivm de applicatie en de verschillende cliënts. De instellingen kunnen algemeen zijn, of specifiek voor één cliënt gelden. Iedere setting bestaat uit een sleutel met daaraan gekoppeld een waarde en een target. Alle velden zijn van het type tekst. Het target veld kan de volgende waardes bevatten: [niets] (= ALL) ALL Het ID van de gelinkte cliënt De naam van de cliënt Folder De folder tabel houdt verschillende bestandstructuren bij. Zo hebben alle bestanden en mappen van alle groepen een eigen record in deze tabel en worden hier ook de indexen van alle cliënts bijgehouden. Er wordt onder andere bijgehouden of het record een bestand, een map, een drive of een virtuele map voorstelt. Verder wordt er ook bijgehouden of het om een lokaal of een remote item gaat. 77

90 Clients In deze tabel worden enkele algemene gegevens van cliënts bijgehouden. Dit zijn onder andere de naam en de publieke sleutel van de cliënt. Verder wordt hier ook bijgehouden tot welke groep de cliënt behoort en is er een verwijzing naar een record in de folder tabel waar de index van de cliënt wordt bijgehouden. Ook de server zelf staat in deze tabel omdat alles wat voor de cliënts bijgehouden moet worden ook voor de server moet worden bijgehouden. De andere gegevens van de server worden bijgehouden in de settings tabel, gelinkt aan het server record in de cliënts tabel. Daarom Met het isserver veld kan de server worden herkend Groups Deze tabel houdt de verschillende groepen bij die zijn geregistreerd. Een groep bestaat uit een naam en een verwijzing naar een folder record waarin alle root folders staan. Het folder record waarnaar het Folder veld verwijst is zelf dus geen root directory Log Deze tabel houdt algemene log berichten bij en foutmeldingen. Met algemene logberichten, worden berichten bedoeld die niet in de FileLog thuishoren zoals het ogenblik waarop de applicatie is opgestart, het ogenblik waarop een cliënt verbinding maakt enzovoort. Ook alle foutmeldingen worden hier gelogd. Een log bericht heeft een type zoals ERRor, EVEent, WARning en COMment. Het comment type is toegevoegd om extra uitleg informatie te kunnen loggen over een logbericht van een ander type. De log berichten hebben ook allemaal een eigen tijdsstempel die uniek is voor de tabel om zo met zekerheid alle logs te kunnen ordenen in de juiste chronologische volgorde FileLog In de filelog staan de wijzigingen van de bestanden die tot een groep behoren. Dit wil zeggen dat hier staat wanneer een bestand werd toegevoegd, en wanneer het werd verplaatst of verwijderd. Ieder record heeft een tijdsstempel die uniek is voor de tabel om zo alle wijzingen perfect chronologisch te kunnen ordenen. Verder bevat de tabel twee velden OldLocation & NewLocation die aangeven wat er gebeurd is. Bij het verwijderen van een bestand, zal OldLocation zijn ingevuld en NewLocation leeg zijn. Bij het aanmaken van een nieuw bestand (of map) zal het juist omgekeerd zijn. Meestal zullen items echter nooit worden verwijderd. In plaats daarvan zal het systeem de te verwijderen items verplaatsen naar de vuilbak. Merk op dat enkel wanneer bestanden worden verplaatst naar de vuilbak wijzigingen ongedaan gemaakt kunnen worden. Bij de cliënt wordt een ingekrompen database gebruikt waar de tabellen Clients, Groups en Folder zijn verdwenen. De tabelen Updates en UpdateContent hebber er een iets andere invulling gekregen. 78

91 FIGUUR 18: DATABASE SERVER FIGUUR 19: DATABASE CLIENT 79