ELEC-C7241 Tietokoneverkot Ohjelmointiprojekti

Transkriptio

1 ELEC-C7241 Tietokoneverkot Ohjelmointiprojekti Pasi Sarolahti,

2 Tentti ti klo 13 Paikkana AS2 Kesto 2 tuntia Neljä kysymystä Laskinta saa käyttää Alue Kolme ensimmäistä osiota (sovellukset, ohjelmointi, kuljetuskerros), niihin liittyvät tehtävät ja kirjan sisältö

3 Järjestelyt Tehdään pareissa Parit saa itse muodostaa Ilmoita ryhmä ja aihe web-lomakkeella ti mennessä Mikäli sinulla ei ole paria: Ruksaa Etsin paria nappi (etsimme sinulle kaverin) Työn saa tehdä yksin, ei vaikutusta arviointiin ( Teen yksin nappi) Deadline: pe 7.4. Sallitut ohjelmointikielet: C, C++, Python, Java

4 Tuotettavat materiaalit Toteutus Koostuu asiakasohjelmasta ja palvelinohjelmasta Mukana oltava selkeät ohjeet ohjelman kääntämiseen ja käyttöön Mieluiten Makefile tai vastaava Toimittava Aallon Linux-järjestelmissä (esim. kosh) Dokumentaatio (n. 10 sivua) Ohjelman suunnittelun ja toteutuksen dokumentaatio Käytetyn protokollan dokumentaatio Analyysi tietoliikenteen ja ohjelman toiminnasta

5 Aiheet 1) Tiedostonjako 2) Keskusteluohjelma 3) Monen pelaajan peli

6 Aihe 1: Tiedostonjako Asiakasohjelma voi lähettää ja vastaanottaa tiedostoja palvelimelle (ja palvelimelta) Tuettava vähintään 1 MB tiedostoja, sekä teksti- että binääritiedostot (esim. kuvat) Protokollavaihtoehdot HTTP/1.1 (ei saa käyttää HTTP-kirjastoja) Itse määritelty protokolla Plussaa Tiedostopalvelun hajautus Peer-to-peer - toiminnallisuus

7 Aihe 2: Keskusteluohjelma Asiakasohjelmat voivat keskustella keskenään palvelimen välityksellä Tuettava vähintään kolmea yhtäaikaista asiakasta Protokollavaihtoehdot IRC Itse määritelty protokolla Plussaa Useamman hajautetun palvelimen yhteistoiminta Tiedostojen välitys keskustelun lomassa

8 Aihe 3: Monen pelaajan peli Yksinkertainen ASCII-pohjainen peli, jossa pelaajat pelaavat toisiaan vastaan palvelimen välityksellä Tuettava vähintään kolmea yhtäaikaista asiakasta Esim. Multiplayer Nethack, strategiapeli, korttipeli Plussaa Reaaliaikaisuus Hajautus usealle palvelimelle / pelilobby

9 Vaatimuksia toteutukselle Tulee toimia tyydyttävästi useammalla kuin yhdellä yhtäaikaisella asiakkaalla Voit perehtyä hyödyllisiin mekanismeihin: select, säikeet, tms Rinnakkaisuuden järjestely UDP:llä saattaa olla helpompaa Mutta muista UDP:n rajoitteet luotettavuuden suhteen Robusti poikkeuskäsittely Mitä jos yhteys menetetään? Mitä jos asiakasohjelma tai serveri tekee jotain odottamatonta?

10 Dokumentaatio Dokumentissa tulee olla seuraavat osat 1) Ohjelman toteutuksen ja rakenteen kuvaus 2) Käännös- ja käyttöohjeet 3) Käytetyn protokollan kuvaus Jos toteutettu jokin(jotkin) RFC, kerro rajaus: mitkä osat toteutettu, mitkä ei Jos oma protokolla: kuvaile protokollan toiminta: sanomanvaihto, käytetyt viestit ja viestiformaatit 4) Testaus: miten asiakasta ja palvelinta on testattu Erityisesti kommunikaatiotoimintojen osalta 5) Analyysi (seuraava kalvo) 6) Työloki: kuinka työmäärä jakautui (ajallisesti / työparin kesken) Evidenssi työnjaosta, esim. versionhallintaloki liitteenä on plussaa

11 Analyysissä käsiteltävät aiheet Kustakin aiheesta vähintään kappaleen verran tekstiä 1) Perustele kuljetuskerroksen protokollan valintaa. Miksi et valinnut jotain muuta (eli sitä toista) protokollaa? 2) Kuinka toteutus toimii IPv6 osoitteiden kanssa? Onko asiaa testattu? Voisiko jotain tehdä paremmin? 3) Mitä tapahtuu kun asiakas sammuttaa äkisti koneensa kesken yhteyden? Toimiiko palvelin? Onko toimintaa testattu? 4) Mitä tapahtuu kun palvelimelle tulee suunnilleen samaan aikaan useita (esim. 5) samanaikaisia asiakkaita? Pystyykö palvelin palvelemaan kaikkia tyydyttävästi?

12 Arviointi 60% toteutuksen toiminnallisuus 5: selviää poikkeustilanteista, hallitsee mielivaltaisen määrän käyttäjiä, joitain plussaominaisuuksia toteutettu 3: toimii perustapauksissa, ja kykenee toimimaan usean käyttäjän kesken 1: toimii joten kuten, ongelmia virheenhallinnan ja usean käyttäjän tapauksissa 0: ohjelma on testauskelvottomassa kunnossa 40% dokumentti ja analyysi 5: kaikki vaaditut osiot on kuvattu selkeästi ja yksityiskohtaisesti. Analyysi on kattavaa ja pohtii annettuja aiheita kattavasti 3: vaaditut osat on dokumentoitu, mutta kuvaus on paikoitellen epätarkkaa, eikä dokumentoi kommunikointitoiminnallisuutta tyydyttävästi 1: dokumentti on toimitettu, mutta siitä puuttuu vaadittuja osia ja se on epätarkka

13 Vinkkejä Aloita yksinkertaisesti Ensin yksinkertainen asiakas-palvelin pari Aloita hyvissä ajoin Riittävästi aikaa ongelmien ratkomiseen Jätä myös dokumentoinnille aikaa Apua saatavilla normaaleina laskariaikoina

14 Client-Server Model 1. Server creates socket and sets it listening at given port (and address) Server 14

15 Client-Server Model Client 3. Server accepts the incoming connect request, a new socket descriptor is created for reading and writing 2. Client creates socket and issues connect to port set by server. TCP SYN is sent. Server 15

16 Client-Server Model Client The listening socket can continue accepting new connection requests Client Server Client (listening socket cannot be used for reading or writing) 16

17 Different Uses of bind() function Server Choosing the local port the most common use Choosing the local address Client Choosing the local port (is this useful?) Choosing the local address Automatic bind If bind has not been called explicitly System picks port and address when first packet is sent out 17

18 Setting a Passive Socket int listen (int sockfd, int backlog) Returns 0 on success, -1 on failure Sets up a backlog queue for pending (not yet accepted) incoming connections Backlog: length of the queue Listening socket is called passive socket Only the local port (and possibly address) is specified SYN SYN SYN Backlog queue SYN/ACK TCP SYN TCP ACK listen accept 18

19 Bind, Listen, Accept *,80 bind ,61246 listen accept connect ,80 Automatic bind: ,

20 Select call Largest FD + 1 sockfd NULL 3 sec. select(maxfd, readset, writeset, exceptset, timeout) 2 Number of bits in resulting mask