Tomas Larsson 760519-7016 (tln99006@student.mdh.se) Handledare ABB: Stefan Wedin Mats Rubin 630104-1411 (mrn99009@student.mdh.se) Handledare MdH: Magnus Larsson IDT - Institutionen för Datateknik Examinator: Ivica Crnkovic Licensserver För flytande licenser Examensarbete 10p 2000-09-17 Västerås
2 Förord Denna rapport är gjord som en del av ett 10 poängs examensarbete inom området datateknik och innefattar dels en marknadsundersökning av licenssystem samt utvecklingen av vårt egna License Manager system. Examensarbetet har utförts till största del på ABB Automation Systems AB samt en mindre del på Mälardalens Högskola, båda belägna i Västerås. Vi vill här också passa på att tacka våra handledare Magnus Larsson (Mälardalens Högskola, IDt) och Stefan Wedin (). Vi vill även tacka Stefan Bengtzing () för att ha gett oss möjligheten att genomföra detta examensarbete på ABB, Mika Holm () och Erik Johansson (ABB Automation Systems) för deras stöd och support under utvecklingens gång. Tomas Larsson Mats Rubin
3 Sammanfattning Idag är det inte många som reagerar när någon säger att de har kopierat den nyaste Windowsversionen eller något webdesign-program, helt gratis. Det kallas piratkopiering och har ständigt ökat genom åren. Detta är ett problem för programvaruutvecklarna och innebär att de måste skydda sina program på något sätt, t ex genom licenser. Ett bra sätt är att skapa en licensserver som dynamiskt kan hålla reda på vilka som använder ett program just för ögonblicket, samt neka de som inte borde använda det, med allt vad det innebär. Denna rapport beskriver inte bara de system på marknaden idag som är byggda för just det ändamålet, utan även vårt eget License Manager system som designats och implementerats. I det senare fallet visas hur licensnyckelgenerering går till, hur applikationer kommunicerar med licensservrar samt en hel del annat.
4 Innehållsförteckning 1 BAKGRUND... 6 1.1 PIRATKOPIERING... 6 1.1.1 Business Software Alliance... 6 1.2 LICENSMODELLER... 8 1.2.1 Flytande licenser... 8 1.2.2 Nodbaserade licenser... 8 1.2.3 Nätverkslicens... 8 1.2.4 Evaluerande eller tidsbegränsade licenser... 8 1.2.5 Evaluerande licens med förfluten tidsperiod... 9 1.2.6 Hårdvarulås... 9 1.3 SYFTET FÖR ABB?... 9 1.4 INTRODUKTION TILL UPPGIFTEN... 9 2 MARKNADSUNDERSÖKNING... 10 2.1 ABB:S KRAVSPECIFIKATION... 10 2.2 FLEXLM... 10 2.3 ARGUS LICENSE MANAGER... 11 2.3.1 Argus licensfil... 11 2.4 SENTINELLM... 13 2.5 ÖVRIGA SYSTEM... 14 2.6 FÖR- OCH NACKDELAR... 14 3 ANALYS... 15 3.1 C-28... 15 3.2 LÖSNINGEN... 16 3.3 INTERFACET MOT KLIENTEN... 18 3.4 LICENSKLASSERNA... 18 3.4.1 ProgramLicenseList... 18 3.4.2 LicenseList... 18 3.4.3 License... 19 3.4.4 Klassernas beroenden... 20 3.5 KEYCLASS... 20 4 DESIGN... 21 4.1 LICENSEMANAGER (LM) API... 21 4.2 LICENSFILEN... 22 4.3 LAGRINGEN AV UTCHECKADE LICENSER PÅ SERVERN... 22 4.4 HUR ANVÄNDS SYSTEMET?... 22 4.4.1 License Generator... 23 4.5 ALGORITMER... 23 4.5.1 Kodgenerering... 23 4.6 DATASTRUKTURER... 25 5 SLUTSATSER... 27 5.1 BEGRÄNSNINGAR...27 5.2 FÖRDELAR... 27 5.3 NACKDELAR... 27 5.4 HAR MÅLET NÅTTS?... 27 5.5 FÖRBÄTTRINGAR... 28 6 REFERENSER... 29
5 Figurförteckning Figur 1-1 Piratkopieringens utbredning per land (BSA [01])...7 Figur 2-1 Formatet på Argus licensfil [03]...12 Figur 2-2 Exempel på Argus licensfil [03]...12 Figur 3-1 C-28 övergripande beskrivning...16 Figur 3-2 Översikt av licenssystemet...16 Figur 3-3 UML [12] för klassen ProgramLicenseList...18 Figur 3-4 UML [12] för klassen LicenseList...19 Figur 3-5 UML [12] för klassen License...19 Figur 3-6 UML [12] för de tre licensklasserna...20 Figur 3-7 UML [12] för klassen KeyClass...20 Figur 4-1 License Generator - används för att generera licensfiler...23
Bakgrund - Piratkopiering 6 1 Bakgrund Sedan en ganska lång tid tillbaka så har datorprogram utvecklats för att underlätta för oss människor i olika situationer. Det kan vara allt från att skriva dokument, sköta bokföringen till att skapa 3d-ritningar med hjälp av CAD. Alla företag som utvecklar dessa program har en sak gemensamt; de vill tjäna så mycket pengar som möjligt. När företagen sätter priser på sina produkter så försöker man lägga sig på en rimlig nivå i kundens ögon och det kan t ex vara utvecklingskostnaden plus några procent i ren vinst för att det ska löna sig i slutänden. 1.1 Piratkopiering Nu finns det en hel del kunder/användare som anser att priserna är alldeles för dyra på programvaror och helt enkelt piratkopierar 1 dem av andra som köpt eller kopierat det i sin tur. På det här sättet så sprids produkterna på ett okontrollerat sätt och marknaden mättar sig självt mer eller mindre. Det finns en lag i Sverige som säger att om man kopierar ett program så är det stöld och kan ge upp till 2 års fängelse, vilket kan verka långsökt för en del eftersom det inte är någon direkt hårdvara som stjäls, men det man menar är att den som kopierar är ansvarig för att utvecklaren går miste om inkomst. Det är oftast företag som orsakar de största förlusterna för programleverantörerna eftersom de kanske köper in en licens och kommer på vid ett senare tillfälle att de behöver fler. Då är det väldigt lätt att installera programmet på några extra datorer utan att beställa nya licenser. Det är också vanligt att man sprider programvaran vidare till anställdas privata datorer hemma, där de kan nyttja det både i jobbet men även privat. Cheferna eller VD:n är ofta medvetna om att kopieringen förekommer men det är sällan någonting görs åt det. Det är inte ens säkert att de anställda vet om de har lagliga kopior eller inte, så det kan innebära problem att visa att de var ovetande när man står innanför rättens dörrar. 1.1.1 Business Software Alliance Business Software Alliance (BSA) [01] är ett företag som specialiserat sig på bekämpning av piratkopiering. De redovisar siffror som talar om utbredningen av den både globalt och per land. Värst i hela världen är Kina, där det av alla program som används är hela 96 % som är piratkopierade. I Figur 1-1 visas en sammanställning av piratkopieringens utbredning och även förlorad inkomst per land som BSA har gjort. Siffrorna gäller 1997. Ser man till den globala aspekten på problemet så redovisar BSA att under 1997 så var den totala förlorade inkomsten $11 000 000 000 vilket motsvarar nästan 100 miljarder svenska kronor. 1 Kopierad programvara som används utan att upphovsmannen fått någon ersättning motsvarande värdet.
Bakgrund - Piratkopiering 7 Land Förlorad inkomst i miljarder svenska kronor Andel piratkopior av alla använda programvaror USA 25.4 27% Kina 12.7 96% Japan 7.3 32% Korea 5.5 67% Tyskland 4.6 33% Frankrike 3.6 44% Brasilien 3.6 62% Italien 2.7 43% Kanada 2.7 39% Storbritannien 2.7 31% Figur 1-1 Piratkopieringens utbredning per land (BSA [01]). Detta är anledningen till att de flesta programvaruföretag har infört licensskydd för att skydda sig mot just denna typ av problem. Grundidén är att när man köper en produkt så köper man ett visst antal licenser. En licens är en rättighet att använda en programvara och vanligtvis så köper företag flera stycken för att kunna jobba flera samtidigt med samma program. Rent praktiskt så är en licens ofta en kodnyckel som följer med programmet vid leverans som har till syfte att låsa upp det. Utan nyckeln så startar inte programmet alls, eller alternativt i ett begränsat läge där vissa funktioner är avstängda. Det innebär alltså att om ett företag bestämmer sig för att köpa en programvara till 10 personer som behöver arbeta med det, så får dom också 10 licensnycklar skickade till sig. Dessa nycklar är unika d v s de fungerar endast ihop med sitt respektive exemplar av programmet. Det är här som problematiken kommer in i bilden. Antag att företaget har 20 användare av ett program, men de kommer aldrig vara fler än 10 stycken som jobbar med det samtidigt. Då skulle det rent principiellt räcka med 10 licenser för att täcka behovet, men eftersom de sitter på 20 olika datorer så tillåts man inte att lägga in programmet på fler än hälften av dem. Det betyder att de blir tvungna att köpa det dubbla antalet licenser bara för att kunna använda det i den mån som behövs, vilket naturligtvis medför en hel del extrakostnader. En lösning på problemet är att skapa ett system som kan hålla reda på s.k. flytande licenser vilket innebär att man inte är bunden till en specifik dator. När man startar sitt program så kontaktar det en server som kontrollerar hur många som just nu använder programmet, och om det finns lediga platser så tilldelas man en licens. Skulle det vara fullt så nekas man godkännande, eller alternativt möjlighet att köra vidare mot att programvaruföretaget debiterar en extra kostnad i efterhand för överskridande av antalet licenser. Det senare kan vara bra i krissituationer och liknande.
Bakgrund - Licensmodeller 8 1.2 Licensmodeller Normalt när man köper ett licenssystem kan man välja mellan en rad olika modeller som man kan använda vid licensiering av sina produkter. I detta avsnitt tas de vanligaste modellerna upp och beskrivs lite kortfattat. 1.2.1 Flytande licenser Flytande licenser är tillgängliga för samtliga användare inom nätverket, oberoende av vilken nod man sitter på. Vilken användare som helst inom nätverket kan bli tilldelad en licens för den aktuella applikationen så länge licensservern inte har delat ut sitt maximala antal som får användas samtidigt. En flytande licens kan kombineras med en nätverkslicens om man vill begränsa sig till en viss adressrymd. Engelska uttryck som används för att beskriva denna typ av licensiering är floating-, concurrent- samt network-licensing. 1.2.2 Nodbaserade licenser En nodbaserad licens är tillgänglig för en användare av en nod med ett specifikt ID eller IPadress. I en klient/server miljö garanteras en användare, på en specificerad nod, en licens så länge man inte överstiger det maximala antalet tillåtna licenser. 1.2.3 Nätverkslicens En nätverkslicens används för att kunna begränsa antalet noder i ett system som skall kunna ha tillgång till en licens genom att specificera en aktuell adressrymd som skall gälla. Den tillåtna adressrymden kan antingen anges med en specifik IP-adress relativt serverns adress, eller med en explicit adressrymd. I det första fallet gäller att alla adresser mellan serverns IP och den adress man har specificerat är giltiga, medan i det andra gäller allt mellan två direkt angivna IP-adresser. Man kan i många fall också genom maskning av en IP-adress specificera en absolut adressrymd, ex. 130.237.70.*. Detta innebär att alla användare mellan 130.237.70.1 och 130.237.70.255 på nätverket kan bli tilldelade en licens så länge man inte överstiger det maximala antalet. 1.2.4 Evaluerande eller tidsbegränsade licenser En evaluerande licens innebär att en applikation är licensierad men endast för en begränsad period. Detta används ofta för att kunna erbjuda en möjlig köpare att få testa programvaran i sin helhet. När den begränsande tiden har tagit slut så måste köparen skaffa sig en ny licens för att kunna fortsätta använda applikationen. Alla användare med behörighet kan tilldelas en licens så länge man inte överstiger det maximala antalet eller att tidsbegränsningen har nått sitt slut.
Bakgrund - Syftet för ABB? 9 1.2.5 Evaluerande licens med förfluten tidsperiod Detta är en annan typ av evaluerande licens och med denna kan man även specificera en förfluten tidsperiod, eller deltatid som det brukar kallas, för tillåten användning för exempelvis 10 dagar från det att man börjat använda programvaran. Oftast så specificerar man både en deltatid och en absolut tid (ett slutdatum) där licensen slutar gälla oberoende av vilken som inträffar först. Den här typen av licens brukar inte ha några begränsningar när det gäller antalet samtidiga användare eftersom man kan hålla ner användandet genom att ange en kortare period. 1.2.6 Hårdvarulås Detta är en helt annan variant av skydd som bygger på en liten enhet som man sätter i datorn. Om applikationen inte hittar den så fungerar inte programmet. De brukar oftast vara byggda på ett sådant sätt att man inte kan bygga egna enheter på ett enkelt sätt. 1.3 Syftet för ABB? För ABB:s del så är inte tanken att förhindra att produkterna sprids till privata användare av den anledningen att de utvecklar styrsystem som är anpassade för industrin. Snarare är syftet att se till att inte fler personer nyttjar det på arbetsplatsen än det finns licenser för. Priset på produkterna som ABB säljer är baserade på antalet samtidiga användare av systemet, och inte på antalet datorer som det finns installerat på. Därför är det viktigt att man kan kontrollera användandet så det inte överskrids. Men även, som nämnts tidigare, så måste möjligheten finnas att kunna överskrida den begränsningen om något skulle inträffa. Kanske någon del av ett system har havererat och man blir tvungen att sätta in extra personal för att hitta felet, och då behöver nyttja ett licensierat program. Då har man inte tid att vänta dagar eller veckor på att få några licensnycklar skickade till sig, utan betalar hellre lite extra för att kunna köra direkt. Det ultimata för ABB vore att göra ett system som är så pass generellt så att det kan hantera licenser för samtliga av deras produkter och som dessutom har enkel funktionalitet för administrering av licenserna. Det är ganska ofta som kunden vill ha några extra licenser och då får det inte innebära för mycket administrering för att skaffa fram dem, utan en tänkbar lösning vore t ex att via Internet logga in på deras licensserver och lägga till några stycken. 1.4 Introduktion till uppgiften Uppgiften består av att utföra en marknadsundersökning där befintliga licensprodukter skall jämföras mot varandra. En egenutvecklad design för ett licensserversystem, som hanterar flytande licenser, skall arbetas fram. Med designen som grund skall prototyper för klient och server tas fram där klienten kan kvittera ut licenser om lediga finns. Om det inte finns lediga licenser, skall det vara möjligt att tvinga fram licenser. Ett plattformsoberoende system är en bonus men inget krav.
Marknadsundersökning - ABB:s kravspecifikation 10 2 Marknadsundersökning Om man sammanställer vilka licensserversystem som finns tillgängliga på marknaden, och som dessutom uppfyller de krav som ABB ställer på det, inser man snart att det finns ett ganska begränsat utbud. 2.1 ABB:s kravspecifikation För att systemet ska vara anpassat för ABB:s behov ställs följande krav: Systemet ska kunna leverera flytande licenser. Möjlighet att när man uppnått det maximala antalet licenser kunna välja mellan att överskrida det under kontrollerade former, eller att bli direkt nekad ett överskridande. Detta kallas overdraft. Det är en bonus om systemet är plattformsoberoende d v s att man ska kunna köra servrar och klienter i vilken miljö som helst och ändå kunna ha en fungerande kommunikation mellan dem. Det finns några lösningar som stöder samtliga krav och de kommer att presenteras lite mer ingående nedan. 2.2 FLEXlm FLEXlm är ett licenssystem som är byggt för att vara så generellt som möjligt. Det innebär att det går att integrera i princip vilken programvara som helst. När man köper programmet så får man en dll-fil (alternativt andra filer för UNIX etc.) som skall länkas med i sitt projekt. Genom den filen så får man ett API 1 mot licenssystemet som erbjuder ett antal tjänster. Det kan t ex vara utcheckning av licenser, kontroll av licensnycklar etc. Systemet har ett brett utbud av olika typer av licenslösningar. Man kan ha både flytande och nodbaserade licenser eller i kombination. Möjligheten att överskrida det maximala antalet licenser för en kort stund (d v s overdraft) finns också. Systemet har stöd för samtliga 5 licensmodeller som beskrevs i avsnitt 1.2. Därmed stöds samtliga krav i avsnitt 2.1. FLEXlm bygger på en huvudserver som startas på en eller flera noder (redundans stöds). Sedan finns det ett antal underservrar, en för varje programvara som man vill skydda, som endast håller reda på information rörande ett specifikt program. Huvudservern i sin tur, håller reda på var alla underservrar finns någonstans på nätverket och startar/stoppar dem vid behov. När man sedan som användare startar en applikation anropas först huvudservern för att få reda på var den specifika underservern finns, som sedan frågas om det finns lediga licenser. Varje användare har en licensfil på sin dator där programvaran kan hitta information om var 1 Application Programming Interface
Marknadsundersökning - Argus License Manager 11 huvudservern finns. Där finns också information om alla eventuella andra redundanta huvudservrar. Det finns egentligen inga nackdelar med FLEXlm som man kan se direkt, utan verkar snarare vara det system som andra sneglar på vid utvecklingen av egna lösningar. Därför är också FLEXlm marknadsledande med över 2000 bolag som använder det, och i o m det även beprövat i de flesta former. Det enda som eventuellt skulle kunna vara till en nackdel är priset men eftersom vi inte lyckats komma i kontakt med Globetrotter [11] som tillverkar programmet så har vi heller ingen prisinformation att rapportera. Däremot har vi tittat på ett prisexempel [02] som finns på deras hemsida om ett exempelföretag där 20-25 personer behöver kunna använda en produkt. Det visar sig att i det långa loppet så vinner FLEXlm prismässigt över motståndarsystemet då det är billigare per licens, även då den totala kostnaden hamnade $6.500 över sin konkurrent. FLEXlm har en licensfil där information lagras om vilken programvara licensen gäller för, hur många kopior man har rätt att starta samtidigt, eventuellt mellan vilka datum den ska gälla samt en licensnyckel som är genererad med hjälp av denna information. Vid uppstart av programmet så kontrolleras licensnyckeln i filen mot serverns genererade nyckel för att se om de är lika. Ändrar man det minsta på den känsliga informationen i licensfilen, t ex antalet licenser, så kommer inte den nyckeln att stämma överens med den genererade och användaren nekas godkännande. Licensnyckeln i filen är alltså genererad enligt någon algoritm av programvaruföretaget som sedan skickas med programmet, och utan den går det inte att starta. 2.3 Argus License Manager Argus är designat för att enkelt kunna integreras i en applikation och för att man skall kunna anpassa de olika licensmodellerna efter behov, allt för att slutkunden skall kunna installera det på ett enkelt sätt. Man kan nyttja sig av licensskyddet i sitt program med endast ett par funktionsanrop och man kan dessutom anpassa många av licensmodellerna genom att nyttja de tjänster som Argus API erbjuder. Dessutom är källkoden tillgänglig och det innebär att man har möjligheter att ändra i den om man har speciella krav som inte finns med från början. Argus har stöd för samtliga licensmodeller som beskrevs i avsnitt 1.2. Argus kan användas i applikationer som körs i klient/server-system samt där ingen licensserver används, och man använder sig av samma funktionsanrop och kommandon i båda fallen. Systemet som tillverkas av Scientific Toolworks [03] har ett fast pris på $2,995 och i det priset ingår, förutom de körbara för Windows och Unix, även källkoden. Några nackdelar med systemet har inte upptäckts. De krav som ställs i avsnitt 2.1 stöds d v s flytande licenser, möjlighet till overdraft och plattformsoberoende. Egna lösningar kan konstrueras i o m att källkoden medföljer. 2.3.1 Argus licensfil Licensfilen definierar vilken programvara som licensen gäller för, vilka maskiner som tillåts att köra, slutdatum för tidsbegränsade licenser, antalet samtidigt tillåtna användare och ett valfritt fält vilket kan fyllas i med något specifikt data av programvaruförsäljaren. Sökväg och
Marknadsundersökning - Argus License Manager 12 namn på licensfilen specificeras av programvaruförsäljaren. Formatet på licensfilen ser ut på följande sätt. Figur 2-1 Formatet på Argus licensfil [03] Kommentarer kan göras efter tecknet ; eller # som ovan. Alla rader som inleds med nyckelordet Server: definierar namn, id och IP-port på den server som kör licenshanteringen. I denna version, Argus 1.0, så stöds inte redundanta servrar. För applikationer som kör utan server så används inte Server: utan all kontroll av licenser utförs automatiskt av applikationen. Här följer några exempel på olika sätt att identifiera en server. Server: Lestrade f1d33b0b 8555 Server: 207.121.65.44 f1d33b0b 8555 server: watson 690c3268 4321 SERVER: UNITY 8D3EBFDA 7777 Varje funktion eller mjukvaruprodukt som anges i licensfilen har sina begränsningar, slutdatum för tidsbegränsningen, antalet samtida licenser och valfri data från programvaruförsäljaren. En funktion kan behöva multipla poster i licensfilen. Licenshanteraren väljer då den mest passande när licensen checkas ut för användning. En * asterisk kan också användas för att specificera ett funktionsnamn. Om det finns en giltig licens som matchar funktionsnamnet i licensfilen så kommer alltid att väljas för en licens med en sådan asterisk specificerad. Figur 2-2 är ett exempel på en licensfil med tre permanenta nodbaserade licenser för en funktion samt ett valfri funktionalitet som är giltig under en begränsad tid. Figur 2-2 Exempel på Argus licensfil [03] Argus är plattformsoberoende d v s klient- och serverprogram kan användas i alla kombinationer av tillåtna plattformar. Exempelvis så kan licensservern på en Solarismaskin kommunicera med en Windows NT-klient. Argus använder sig av IP-protokollet. Följande plattformar stöds av Argus: Windows 95 Windows 98 Windows 2000
Marknadsundersökning - SentinelLM 13 Windows NT Linux Solaris SunOS IRIX OSF AIX HP-UX 2.4 SentinelLM Det här systemet är det enklaste hittills, i den bemärkelsen att man inte behöver göra speciellt mycket för att komma igång. Enligt Rainbow Technologies [04], som tillverkar produkten, kan man vara igång redan efter en dag. När man köper systemet kan man välja mellan ett API som man sedan kan nyttja, eller ett skal som man integrerar med sitt projekt och detta utan att man behöver skriva en enda kodrad. Det går t o m att skydda program som man inte har källkoden till med den senare modellen. Systemet har all den funktionalitet som ABB kräver i avsnitt 2.1 och mer därtill. Både flytande och nodbaserade licenser stöds. Möjligheten att överskrida det maximala antalet licenser finns också. SentinelLM har även stöd för redundanta servrar, både när det gäller att ersätta en kraschad server men också i lastbalanseringssyfte. Om en server blir för hårt belastad under körning kommer den automatiskt att distribuera ut en del licenser till någon annan mindre belastad server, för att på så sätt fördela lasten jämnt. SentinelLM har även möjlighet att i kombination med övriga lösningar använda hårdvarulås. Att använda den typen av skydd i kombination med flytande licenser är dock ingen bra lösning eftersom det då krävs en enhet på samtliga datorer, och då tappar man idén med flytande licenser. Att systemet är plattformsoberoende är heller ingen nackdel. Det går att använda i vilka kombinationer som helst mellan UNIX, WindowsNT och Java. De har också utvecklat ett elektroniskt licenssystem som dom kallar för Electronic License Distribution (ELD). Det fungerar så att slutkunden kan ladda hem programvaran från programvaruutvecklarens hemsida och sedan prova på den under en tidsperiod för att se hur det fungerar. Väljer man sedan att köpa produkten tar det bara några sekunder att öppna programmet med den licensmodell som man önskar, allt detta sköts fjärrstyrt. Skulle man vara missnöjd med produkten efter testperioden har gått ut är ingen skada skedd och man behöver inte returnera programmet etc. Även betalningen görs över Internet och är därför smidig. Även här har det varit svårt att komma i kontakt med företaget för information om prissättningen. Det finns heller inget exempel som man kan titta på för att se ungefär var det ligger, och det är svårt att sätta ett generellt pris eftersom det varierar beroende på vilken lösning man har tänkt sig. På samma sätt som FLEXlm i avsnitt 2.2 är den enda nackdelen att vi inte lyckats få prisuppgifter men det behöver inte betyda att systemet är dyrare än de andra.
Marknadsundersökning - Övriga system 14 2.5 Övriga system Det finns också en del programvaror och system som delvis eller inte alls uppfyller ABB:s krav, men som fortfarande är licensserver-system. Därför tas de endast upp med en kort beskrivning om varför de inte räcker till. VTProtect, som tillverkas av HALLoGRAM [05], är ett system som använder nodbaserad licensiering och företaget har dessutom utvecklat ett eget fingerprint system som anpassar sig om användaren gör mindre förändringar i sin dator. Det brukar annars vara ett problem med nodlösningar om man t ex byter nätverkskort så ser licenssystemet plötsligt en ny användare eftersom hostnamnet ofta är kopplat till nätverkskortets unika nummer. Programmet stöder dock inte flytande licenser vilket gör det obrukbart för ABB. KeyServer som tillverkas av Sassafras [06], är ett licenssystem som klarar de flesta av kraven men räcker inte riktigt till när det gäller plattformsdelen. Det går visserligen att köra servern i de flesta OS men klienterna är begränsade till att köras i Windows eller MacOS miljö. Det är också oklart om stöd finns för s.k. overdraft vilket innebär överskridande av det maximala antalet licenser för en kortare stund. Nedan följer fyra system som alla har den begränsningen att de endast fungerar på Windows-plattformen. Privilege Licenser från Aladdin [07]. Distinct License Manager från Distinct [08]. SafeSerial från Sikander Soft [09]. Protection PLUS från MARX Software Security [10]. 2.6 För- och nackdelar En av fördelarna med att skapa en egen licensserver för flytande licenser, istället för någon av ovanstående produkter, är att man får skräddarsy den efter de behov man har. Då behöver man inte få med en massa funktioner som man inte kommer att utnyttja. En annan fördel är att kostnaderna kan hållas nere vilket är en följd av att man skapar en egen licensserver. Detta med tanke på de få krav som ställs på licensservern, flytande licenser och möjlighet till att överskrida det maximala antalet licenser under kontrollerade former. Man betalar enbart för det som man behöver. Nackdelarna med att skapa en egen licensserver är att den inte är testad på samma sätt som de befintliga produkter som presenterats här ovan samt att det tar längre tid att skapa något eget än att köpa en befintlig produkt. Kostnader för personal och underhåll av systemet är också en nackdel.
Analys - C-28 15 3 Analys Man inser ganska snart att när man skapar klient/server system så passar det bra att göra det med en komponentbaserad struktur. Valet står då mellan att använda COM/DCOM eller CORBA men eftersom tiden inte räcker till att sätta sig in i båda så har vi beslutat oss för att endast titta på en variant. Det visade sig dock att det inte blev någon av de två ovanstående, utan istället ett framework 1 som ABB har tagit fram som går under arbetsnamnet C-28. 3.1 C-28 C-28 är ett framework som har lånat idéer från både COM och CORBA. Det och har till uppgift att förenkla hanteringen av just klient/server system i olika bemärkelser. Dels vill man som programmerare helst slippa tänka på kommunikations-hanteringen mellan processer och komponenter utan man vill helt koncentrera sig på att lösa huvudproblemet, dvs licenssystemet i vårt fall. Då antar man helt enkelt att man kan kommunicera klient och server emellan via RPC 2. Man definierar sitt interface med hjälp av CORBA IDL-filer som sedan skickas till en egenutvecklad IDL 3 kompilator för att generera två klasser, en proxy och en stubbe. Klientdelen av systemet instansierar ett objekt av proxyklassen och servern instansierar motsvarande objekt av stubbklassen. Därefter kan man från klienten göra vad som ser ut som lokala anrop till proxyn som sedan skickas över nätverket via stubben och in i servern för att utföras. Returvärden (om sådana finns) går samma väg tillbaka och returneras till klienten från proxyn. Användaren märker inte någon skillnad mot att göra ett lokalt anrop (förutom möjligtvis att det tar något längre tid). 1 Ramverk på svenska. Ett sätt att tillhandahålla funktionalitet utan att användaren behöver sätta sig in i hur dess struktur eller implementation ser ut. 2 Remote Procedure Call 3 Interface Definition Language.
Analys - Lösningen 16 Interface description (IDL-file) IDL Compiler Node A (e.g. Win NT) Node B (e.g. Unix) Applications Applications Client Proxy Marshalling Server User Stub added code Framework services Framework services Name Server Name Server Figur 3-1 C-28 övergripande beskrivning Det finns också, som visas i Figur 3-1, nameservrar i systemet som har till uppgift att hitta objekt åt en klient som frågar. När man startar en nameserver på en nod så kontaktar den samtliga andra nameservrar och synkroniserar sig så att alla vet var samtliga objekt implementeras. 3.2 Lösningen Efter erfarenhet från de system som behandlats i marknadsundersökningen skissades följande grova struktur fram. Klient (Applikation) 1. Skicka förfrågan 7. Vidtag åtgärd. "Black Box" 2. Vidarebefordra till servern 6. Skicka returvärdet till klienten. Licensserver 3. Leta på om "Appname.dat" finns som licensfil. 4. Om den finns kontrollera att nyckeln är korrekt. 5. Om 3 och 4 stämmer och lediga licenser finns returnera sant. Figur 3-2 Översikt av licenssystemet Här representeras den svarta lådan av C-28 som sköter kommunikationen helt transparent.
Analys - Lösningen 17 En klient gör en förfrågan om en licens och skickar med vilken applikation det gäller. Den svarta lådan kontaktar sedan servern som och ser till att anropet genomförs. Servern letar efter applikationsnamn.dat och ser efter så att licensnyckeln i den filen stämmer överens med det övriga innehållet. Om allt är OK så skickas ett sant värde hela vägen tillbaka till klienten, och skulle något ha gått snett så skickas naturligtvis ett falskt värde. Klienten vidtar sedan den åtgärd som är nödvändig. Meningen är alltså att användaren av systemet inte ska behöva sätta sig in i vad som händer mellan klienten och servern utan helt enkelt kunna anropa och ta hand om returvärdet. Anledningen att vi har valt att låta licensfilen endast ligga på servernoden är enkel; det blir mindre administration vid förändringar. I fallet med de flesta licenssystem vi har tittat på så ligger licensfilen istället på varje klient och medför då att om man vill uppdatera någon av dem så måste man göra det på samtliga noder. Nackdelen med att ha filen på servern är att man inte så enkelt kan begränsa vem eller vilka som får använda det aktuella programmet. Man skulle kunna tänka sig att skicka med användarnamn eller liknande i förfrågan och på det sättet styra om den personen är behörig eller inte, men det medför också en del overhead på servern. Enligt avsnitt 1.4 så ska även prototyper implementeras. En klient- och en server-programvara ska kunna kommunicera med varandra via ett LAN 1. Flera klienter ska kunna begära licenser till olika program från samma server. 1 Locale Area Network
Analys - Interfacet mot klienten 18 3.3 Interfacet mot klienten lmcheckout() Kvitterar ut en licens från servern om lediga finns. lmforcecheckout() Kvitterar ut en licens från servern oavsett om lediga finns eller inte. Loggning sker vid overdraft. lmcheckin() Återlämnar en förbrukad licens till servern. 3.4 Licensklasserna Man behöver också på något sätt hålla reda på vilka licenser som är utcheckade för ögonblicket och den lagringen bör ligga på serversidan. Därför har 3 behållarklasser tagits fram för just detta ändamål. 3.4.1 ProgramLicenseList Denna klass har till uppgift att bygga upp en lista av alla program som har licenser ute just nu. Varje sånt program kan även ha flera licenser ute så därför blir det en lista av LicenseList objekt. ProgramLicenseList -list : LicenseList +AddLicense() +ForceAddLicense() +RemoveLicense() Figur 3-3 UML [12] för klassen ProgramLicenseList 3.4.2 LicenseList Här lagras vilka licenser som finns utcheckade just nu av ett specifikt program. Information som lagras är vilket namn applikationen har, maximalt antal som får vara ute samtidigt samt det nuvarande antalet utcheckade licenser. Det byggs upp med en lista av License objekt.
Analys - Licensklasserna 19 LicenseList -list : License -GetLicenseInfo() -Log() +SetAppName() +GetAppName() +SetCurrentAmount() +GetCurrentAmount() +SetMaxAmount() +GetMaxAmount() +GetAmountAvailable() +isempty() +Add() +Remove() Figur 3-4 UML [12] för klassen LicenseList 3.4.3 License Den här klassen håller reda på vem som har en specifik licens, dvs nodnamnet på den maskin som nyttjar den. License -Hostname : Char* +SetHostName() +GetHostName() Figur 3-5 UML [12] för klassen License
Analys - KeyClass 20 3.4.4 Klassernas beroenden ProgramLicenseList -list : LicenseList +AddLicense() +ForceAddLicense() +RemoveLicense() n LicenseList -list : License -GetLicenseInfo() -Log() +SetAppName() +GetAppName() +SetCurrentAmount() +GetCurrentAmount() +SetMaxAmount() +GetMaxAmount() +GetAmountAvailable() +isempty() +Add() +Remove() n License -Hostname : Char* +SetHostName() +GetHostName() Figur 3-6 UML [12] för de tre licensklasserna 3.5 KeyClass Denna klass har till uppgift att kontrollera att licensnyckeln som finns i licensfilen verkligen stämmer. Det gör den genom att använda en viss algoritm på den information som står i licensfilen och sedan kontrollera att den uträknade nyckeln överensstämmer med den nyckel som finns i licensfilen. KeyClass -FillString() -SumString() +CodeGenerator() +GetCode() Figur 3-7 UML [12] för klassen KeyClass