JOTI:

1.

Verkko:          130.     233.      46.      64
Binäärinä:  10000010.11101001.00101110.01000000
Netmask/26: 11111111.11111111.11111111.11000000

/26 tarkoittaa, että 26 bittiä osoitteesta on verkko-osaa, loput 6 bittiä 
koneosaa. Verkko-osan bitit ovat pysyvät aina samoina. Verkko-osoite on verkon 
ensimmäinen osoite, eli sen koneosan bitit ovat nollia. Broadcast-osoitteessa 
koneosan bitit ovat kaikki ykkösiä.

Netmaskin perusteella tiedetään, että vapaana on on kuusi bittiä eli 64 (2^6) 
osoitetta. Aloitetaan osoitteiden jako suurimmasta verkosta. 

Työasemat:

Työasemia on 28, joten ne sopivat /27-verkkoon (5 bittiä eli 32 osoitetta).

130.233.46.64/27
broadcast: 130.233.46.95
netmask: 255.255.255.224

Osoitteet .64-.95 on nyt jaettu. Vapaana on /27-verkko 130.233.46.96/27. 
Jatketaan varaamalla puolet siitä palvelimille.

Palvelimet ym:

130.233.46.96/28
broadcast: 130.233.46.111
netmask: 255.255.255.240

Vapaana on vielä verkko 130.233.46.112/28 eli 16 osoitetta. Jaetaan jäljelle 
jäänyt verkko kahteen 8 osoitteen palaseen WLANia ja opetusluokkaa varten.

WLAN-tukiasemat/opetusluokka:

130.233.46.112/29
broadcast: 130.233.46.119
netmask: 255.255.255.248

opetusluokka/WLAN-tukiasemat:

130.233.46.120/29
broadcast: 130.233.46.127
netmask: 255.255.255.248


2.

a. 

Whoisin toiminta eri käyttöjärjestelmien välillä poikkeaa jonkin verran. 
Vastaukseen vaikuttaa myös se, millä tasolla osoitetta tutkii. Tehtävässä 
haluttiin saada tietoja IP-verkosta, joten ensimmäiseksi piti selvittää, mikä 
on ripe.netiä vastaava IP-osoite. Esimerkiksi digillä, hostilla 
tai nslookupilla saadaan vastaukseksi 193.0.19.25 (tai jotain muuta, kuten 
tehtävän traceroutessa näkyy. Tehtävän kannalta ei ole kauhean oleellista, 
mikä osoite sattuu olemaan).

Esimerkiksi Kekkosella whois 193.0.19.25 antaa suoraan tarvittavat tiedot. 
Muilla koneilla saattaa joutua tekemään hieman enemmän töitä. Esimerkiksi 
koshin whois ei anna tulosta ripe.netin IP:llä, ellei ohjaa whoisiä käyttämään 
sopivaa whois-palvelinta (esimerkiksi whois.ripe.net). Oikea vastaus riippuu 
siitä, mitä whois-palvelinta käyttää. Ripen palvelin kertoo osoitteen kuuluvan 
verkkoon 193.0.18.0/23, mutta korkeammalta taholta kysellessä saadaan suurempi 
osoiteavaruus. Kumpikin vastaus on oikein, mutta pisteet luonnollisesti 
tulevat perusteluista.

Whois-tiedoista selviää myös, että osoite kuuluu RIPE Network Coordination 
Centrelle, joka toimii Amsterdamissa Hollannissa. Ripen webbisivuja lukemalla 
selviää, että Ripe vastaa IP-osoitteiden jakamisesta Euroopassa.

b.

Tracrouten rivit sisältävät IP-osoitteen, vastaavan DNS-nimen (mikäli 
sellainen on olemassa) ja kolme aika-arvoa. Ajat ovat paketin matkaan 
käyttämiä aikoja. Koska traceroute testaa kolmella paketilla, on aikojakin 
kolme (mikäli kaikki paketit pääsivät sinne ja takaisin). Maarajoja voi 
päätellä domain-nimistä. Joskus myös ajallisesti pitkät hypyt voivat vihjata 
esimerkiksi valtameren alituksesta. 

c.

Tracerouten tulos on melko varmasti erilainen kaikilla niillä, jotka 
asuvat jossain muualla kuin HOASilla Otaniemen ulkopuolella. Erot johtuvat 
eri aloituspaikasta ja eri palveluntarjoajasta. Myös kuormantasaus voi 
aiheuttaa eroja.


3.

a.

Jos lähetyksessä on jotain interaktiivista (esimerkiksi 
puhelintoivekonsertti), tarvitaan UDP:tä pitämään latenssi alhaisena (samoin, 
jos aiotaan käyttää multicastingia, koska TCP ei tue sitä). Jos tarkoitus on 
vain lähettää, käy TCP:kin vallan hyvin, vaikka kyseessä olisikin suora 
lähetys mikrofonista verkkoon. Puskuroimalla lähetystä muutaman sekunnin 
verran vastaanottaja selviytyy pienestä pakettihävikistäkin. Lähettäjän täytyy 
kuitenkin pitää enemmän lähetysdataa muistissa, kuin UDP:n tapauksessa.

Podcast: Siirretään tiedostoja -> TCP järkevä. 

b.

Aikamerkillä siis tarkoitetaan sellaista tasatunnein tulevaa piipitystä. 
Haussa ei siis ole mikään timestamp.

TCP-pohjaisen nettiradiosoftan kannattaa puskuroida enemmän, kuin 
UDP-pohjaisen. TCP uudelleenlähettää puuttuvan datan, joten katkojen 
välttämiseksi muistissa täytyy olla sen verran dataa, että uudelleenlähetys 
ehditään tehdä. UDP:n kanssa puskuroinnista ei ole juuri apua. Jos pakettia ei 
näy ajoissa, se tuskin tulee enää sekunnin tai parin päästä. Paketin 
puuttuminen aiheuttaa pienen katkon ääneen (ellei protokollassa ole 
virheenkorjausta, joka taas tuhlaa kapasiteettia hyvillä yhteyksillä). TCP:ssä 
koko tietovirta pysähtyy, jos välistä puuttuu tavukin. 

Yleisesti ottaen UDP-pohjaisen nettiradion aikamerkkiin voi siis luottaa 
paremmin. Kumpikin ovat kuitenkin epäluotettavampia, kuin perinteinen 
analoginen radio.

c.

Sovellukset erotellaan porttien avulla, IP osaa toimittaa paketit perille vain 
koneelle saakka, mutta ei ole kiinnostu sovelluksesta, jolle paketti on 
menossa.