Projektuppgift

Projektuppgift (LAB2 2,0 hp) Projektuppgiften består av en större programmeringsuppgift. Detta moment ger 2 hp, och kan ges betyg A, B, C eller E.

Det har kommit ett antal frågor om projektuppgiften. De återfinns tillsammans med sina svar på en QA-sida. Om ni har frågor som inte besvaras av denna sida, skicka ett mail till kursansvarig eller skriv er fråga på KTH Social. Frågor med förväntat allmänintresse kommer att läggas till på QA-sidan.

Betyg E För betyg E på detta moment krävs att man presenterat en godkänd projektplan (E1) och redovisat ett program som uppfyller samtliga specifikationer (E2). Precis som i labbarna krävs att båda i gruppen kan redogöra för alla delarna av uppgiften, och förklara vad olika delar av koden gör och varför ni har valt att göra som ni gör.

Bonuspoäng Godkänd redovisning av moment E1 senast den 31:a 30:e januari ger ett bonuspoäng till del I på tentamen, godkänd redovisning av moment E2 senast den 6:e mars ger ett bonuspoäng till del I. Totalt kan alltså projektuppgiften ge 2 bonuspoäng till del I.

E1 Projektplan Er projektplan ska presenteras med en beskrivning av ert GUI, med bilder. Förklara hur användaren interagerar med programmet vid användningen av olika funktioner, och hur detta hanteras intern i programmet. Projektplanen ska dessutom innehålla en komplett UML-beskrivning av hur det färdiga programmet förväntas se ut. UML-diagrammet ska beskriva samtliga klasser som man har konstruerat själv, inklusive deras fält och metoder. Om det behövs för överskådlighet kan man göra flera UML-diagram - dels ett överskådligt som visar de stora sambanden men utelämnar detaljerna, och ett eller flera detaljerade som beskriver de olika delarna. Om ni anser att ni behöver ytterligare diagram eller texter för att förklara er kod får ni givetvis göra det. Som riktlinje kan ni ha att er redovisning av planen ska vara tillräcklig för att en programmerare på samma nivå som en genomsnittlig kursdeltagare ska kunna implementera ert projekt.

E2 Programspecifikationer Projektuppgiften går ut på att skriva ett program som gör så att man kan skicka textmeddelanden mellan två olika datorer, sk IM (Instant Messaging). Programmet ska uppfylla följande krav:

* Programmet ska ha ett grafiskt användargränsnitt för all funktionalitet
* Det ska gå att ange om man vill att programmet ska köra som server eller som klient.
* Som server ska man kunna ange en specifik port där programmet lyssnar på inkommande upkopplingar. Programmet ska upprätta kontakt med ett annat program som kopplar upp sig mot denna port.
* Som klient ska man kunna ange en nätverksadress och en port att ansluta sig till. Om det finns en väntande server på den angivna adressen skall en kontakt upprättas.
* Det ska finnas ett textfält där man kan mata in text som skickas till programmet man är uppkopplad mot.
* Det ska finnas ett annat textfält där man kan se dels det man själv skickat, och dels det som skickats från det program man är uppkopplad mot.
* Man ska kunna ange sitt eget namn, och för alla textmeddelanden som visas så ska namnet på den som skrivit det skrivas ut.
* Man ska kunna ange vilken färg man vill att ens text ska ha, och texten ska visas i denna färg både i det egna programmet och hos mottagaren. exempel på hur det kan se ut: Putte: Hej! Hur står det till? Anna: Hej själv! Bara bra Putte: Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. Anna: TL;DR Anna: Nu måste jag sova. Hej då Putte: Hejdå!
* Kommunikationen ska ske med TCP/IP sockets, och alla meddelanden skickas som XML. Giltiga tags som måste kunna hanteras är:
* <message></message> - detta tag-par skall innesluta hela meddelandet, och kan ta attributet sender="namn", där namn förstås är namnet på den som skickat meddelandet.
* <text></text> - detta tagpar skall innesluta den del av meddelandet som innehåller text som skickas, och kan ta attributet color="#RRGGBB", där #RRGGBB är färgen angiven som RGB-värde i hexadecimalkod.
* Om man vill får man använda stiltaggarna <fetstil></fetstil> och <kursiv></kursiv>, men det är inte ett krav. Om man inte tänker hantera dessa taggar skall de ignoreras, och texten mellan dem skall visas i vanlig stil.
* Ert program behöver inte kunna visa meddelanden som innehåller trasig XML-kod, dvs med omatchade taggar, omatchade citat-tecken eller omatchade par av '<' och '>'. Om det kommer ett trasigt meddelande kan ni välja att inte visa det alls, utan bara ange ett felmeddelande (t.ex "Nu kom det ett trasigt meddelande!"), eller försöka visa så mycket som möjligt av meddelandet, tillsammans med en varningstext om att meddelandet var trasigt och kanske inte visas korrekt. Notera att ni måste hantera all tänkbar text som användare skriver in så att denna inte genererar trasig XML, utan kommer fram som avsett. Om användaren vill skicka text som innehåller XML, t.ex för att förklara XML-syntax för en kompis, så måste man kunna göra det. Använd er av de konventioner som finns i HTML för att konvertera relevanta tecken. Dvs, > kodas som &gt; och < kodas som &lt; osv.
* Meddelande-delar som innesluts av okända tag-par (eller som inte innesluts av något tag-par alls) ska ignoreras helt. Okända attribut i kända taggar skall också ignoreras, och taggarna hanteras som om de inte hade dessa attribut. Detta gör att erat program kan kommunicera med mer avancerade versioner utan att haverera.

* Det ska finnas en avstängningsknapp. När ett program stängs av skall programmet man är uppkopplad mot visa detta på ett lämpligt sätt, t.ex genom att skriva ut "Putte har loggat ut". Detta möjliggörs genom att man skickar ett nerkopplingsmeddelande innan man kopplar ner. Detta har de vanliga <message>-taggarna, och inkluderar den ensamma taggen <disconnect /> inne i meddelandet.
* Koden skall följa gängse stilkonventioner! Detta inkluderar vettiga kommentarer.
Betyg A, B och C För betyg C krävs det dels att man uppfyller alla krav för betyg E, och dels att man uppfyller kravspecifikationerna för minst en av extrauppgifterna C1 och C2 nedan. För betyg B krävs det dels att man uppfyller alla krav för betyg E, och dels att man uppfyller kravspecifikationerna för extrauppgiften B1 nedan. Om man uppfyller kraven för samtliga extrauppgifter (C1, C2 och B1) får man betyget A på detta moment. När man redovisar sin projektplan ska den även innehålla alla extrauppgifter man tänker göra.

C1 Kryptering I denna extrauppgift ska ni förse ert program med möjligheten att kryptera meddelanden. För att få godkänt på denna uppgift krävs att programmet upfyller följande specifikationer:

* Man ska kunna välja mellan minst två olika sorters kryptering
* Ett av de valbara kryptona ska vara AES, ett ska vara ett Caesarkrypto
* Ett krypterat meddelande ska ha ett okrypterat tagpar av typen <message> som innesluter meddelandet. De delar av meddelandet som krypteras ska inneslutas i (det okrypterade) tagparet <encrypted></encrypted>, som tar attributet type="XXXX", där XXXX är namnet på kryptot som används. Giltiga namn är t.ex "AES", "blowfish", "caesar", "RSA". Vill ni kunna använda andra krypton får ni använda valfria namn, men meddela gärna kursledaren, så lägger jag till dem till listan, så att ni kan skicka krypterade meddelanden till varandra. Ett annat attribut som ni kan ange är key="YYYY", där YYYY är nyckeln. För caesarkrypto bör det vara ett heltal, och för krypton med privata och publika nycklar bör ni ange den publika nyckeln här.
* Krypterade meddelandedelar, liksom kryptonycklar, kan innehålla godtyckliga tecken. För att förenkla meddelande-parsningen ska alla nycklar eller kryperade meddelandedelar konverteras till hexadecimalkod och skickas som en textsträng bestående av tecknen '0'-'9' 'A'-'F' Varje byte kodas alltså med två tecken. Hexadecimalkoden koverteras tillbaka till bytes innan man avkrypterar. Använd UTF-8 för teckenkonvertering.
* För att få reda på en annan användares publika nyckel kan man skicka ett meddelande innehållandes en <keyrequest>, med attributet type="XXXX", som tar samma värden som ovan. Man ska kunna skicka med ett meddelande inneslutet i keyrequest-taggparet som visas för motparten. Om motparten inte har skickat ett svar innehållandes en publik nyckel av rätt sort inom en minut skall den anses inte kunna hantera krypton av den aktuell sorten. Detta ska framgå för användaren, så att denne inte kan försöka skicka krypterade meddelanden till någon som inte kan ta emot dem. Ett program som stöder kryptering skall givetvis skicka ett lämpligt svar på en nyckelbegäran.
* Det ska gå att byta mellan olika krypton, och mellan krypterat/okrypterat när som helst. Ett meddelande kan innehålla flera delar med olika kryptering av olika delar. Ert program behöver inte kunna hantera nästade krypton, dvs att man krypterad delar inuti ett redan krypterat meddelande.
* Om ni siktar på A-betyg och gör uppgift B1 också, måste man förstås kunna hålla reda på vilken kryptering som gäller för vilken mottagare.
OBS Kryptering är en svår konst. Inom ramarna för den här kursen gör vi inte riktig säker kryptering. För de som vill lära sig att kryptera saker på riktigt rekommenderas kursen DD2448 Kryptografins Grunder.

C2 Filöverföring I denna extrauppgift ska ni lägga till möjligheten att skicka filer mellan olika användare. För att få godkänt på denna uppgift krävs att programmet upfyller följande specifikationer:

* Om man är uppkopplad i konversation med en annan anvämndare ska man kunna välja att skicka en fil till denne.
* Man ska kunna välja en fil från sitt filsystem med ett GUI. När man väljer att skicka en fil ska man kunna skicka med en egen text om filen.
* När man har valt en fil att skicka ska ens program först skicka ett meddelande till motparten för att fråga om denne vill ta emot filen. Detta meddelande skall förstås vara inneslutet i sedvanliga <message>-taggar.
* Själva förfrågan ska inneslutas i tagparet <filerequest>, som tar attributen name="filnamn", där filnamn är namnet på filen man vill skicka. Vidare finns attributet size="XXXX", där XXXX är filens storlek i Byte. Texten mellan taggparen är användarens text om filen.
* En användare som får en filförfrågan skickad till sig ska få upp all information om filen, och kunna välja att tacka ja eller nej till att ta emot filen, och ges möjligheten att lägga till ett eget textmeddelande, tex. "tack gärna!", eller "filen är för stor, skicka en mindre!".
* Svaret på en filförfrågan ska använda sig av <fileresponse>-taggparet, med attributen reply="X", där X kan vara antingen "yes" eller "no", och port="XXXX", där XXXX är portnummret.
* Om man har fått svaret "yes" skall filen skickas. Om man fick svaret "no" skall filen inte skickas.
* Medan man väntar på svar angående filen måste man kunna ta emot vanliga meddelanden och visa dessa.
* Om man inte har fått ett giltigt svar angående filen inom en minut skall det klassas som om ett "no"-svar har angetts
* När/om filen skickas skall både avsändaren och mottagaren få se en 'progress bar' som visar hur stor del av filen som skickats. Det är frivilligt att lägga till information om hur lång tid som filskickandet hittills har tagit, och/eller hur lång tid som tros vara kvar.
* Själva filsändandet ska gå över en separat uppkoppling över en separat socket, så att man fortfarande kan kommunicera medan filen sänds. Filen kan sändas som en ström av Bytes, och behöver inte paketeras i XML;
* Om ni siktar på A-betyg och gör uppgift B1 också, måste man kunna välja vilken av de andra användarna som en fil ska skickas till. Filöverföring i multipartläge sker bara mellan multipartservern och någon av klienterna. Vill de anslutna klienterna skicka filer till varandra får de upprätta en egen direktkontakt.
* Om ni siktar på A-betyg och gör uppgift C1 också, får man göra så att det går att kryptera själva filen. Då får man lagga till attributen type och key i <filerequest>-taggen. Det är lämpligt att den som svarar på filförfrågan anger sin publika nyckel i svaret på filförfrågan. Det är inte ett krav att implementera krypterad filöverföring.
B1 Flera användare Denna uppgift går ut på att göra det möjligt att ansluta till flera andra användare samtidigt. För godkänt på denna extrauppgift krävs att ens program uppfyller följande:

* Man ska kunna ansluta till minst 3 andra användare.
* Ni ska kunna ha separata textfält för konversationer med de olika användarna. Rätt text ska skickas till rätt motpart.
* Ert program ska dessutom kunna fungera som en server för sk multipart-konversationer, dvs alla meddelanden som skrivs av någon användare skall ses av alla. Detta ska fungera även om alla andra användare använder den enklare versionen av programmet från del E.
* Det ska gå att koppla bort en enskild annan användare utan att kommunikationen med de andra störs. Detta ska fungera oavsett vem som kopplade ner (man själv eller motparten). Om man kopplar ner fullständigt bryts förstås kontakten med alla uppkopplade.
* Ens program ska fungera både som klient och server, dvs, det ska kunna hantera inkommande uppkopplingsförsök när som helst, och det ska kunna koppla upp sig mot andra program när som helst.
* När ett annat program vill koppla upp sig ska användaren av ert program kunna se vem som försöker koppla upp sig, och kunna välja att tillåta eller inte tillåta en uppkoppling. För att underlätta detta ska ni använda ett alternativ XML-tagpar, <request> </request>. Texten som innesluts av detta taggpar ska visas för användaren när denne bestämmer om hen ska tillåta uppkopplingen. Om någon försöker ansluta med en klient som inte implementerar uppgift B1, så ska användaren ges ett meddelande om att det verkar som om en enklare klient vill ansluta, och fråga om hen vill tillåta detta.
* Om man svarar ja ska en koppling upprättas, och om man svarar nej ska ett meddelande med <request>-taggar och attributet reply="no" skickas tillbaka. Detta kräver förstås att en tillfällig uppkoppling upprättas. Om förfrågan kom från en klient utan stöd för del B1, skall svaret skickas som ett vanligt textmeddelande.
* Om det finns en övre gräns på hur många andra användare som får ansluta sig, och denna redan är nådd, ska ett automatgenererat nejsvar skickas tillbaka. Användaren ska meddelas om att någon har försökt ansluta sig.