• Nem Talált Eredményt

7. Hálózati réteg

N/A
N/A
Protected

Academic year: 2022

Ossza meg "7. Hálózati réteg"

Copied!
68
0
0

Teljes szövegt

(1)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

7. Hálózati réteg

Dr. Bilicki Vilmos

Szoftverfejlesztés Tanszék

(2)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

A hálózat működése

 A hálózati réteg feladat:

■ Egy hierarchikus címzés segítségével azonosítani a hálózat egyes szegmenseit

■ Megkeresni közöttük a legkedvezőbb útvonalat

■ Legjobb szándék szerint kézbesíteni az adat csomagokat

 Elemei:

■ Forgalomirányítók

Több logikai vagy fizikai interfész és képes átvinni a forgalmat közöttük

■ Hostok, Állomások

Egy vagy több logikai vagy fizikai interfész és nem képes átvinni a forgalmat közöttük

 Forgalom típusok:

■ Normál (Unicast)

■ Töbesküldés (Multicast)

(3)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv4 – TCP/IP Internet réteg

Kézbesítés:

Legjobb szándék szerint (Best effort), nincs garancia

Elemei

IP csomagok

TCP UDP ICMP IGMP

Egyéb csomagok

ARP RARP

IP címzés

Hierarchikus cím tartomány

A cím és a topológia és a cím tartomány együtt van definiálva

Forgalomirányítók

Tipikusan a csomag cél címe alapján hozzák meg döntéseiket Minden csomagot külön kezelnek

Kommunikációs módok:

Pont – Pont (Unicast)

Üzenetszórás (Broadcast)

Többesküldés (Multicast)

(4)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv4 csomag felépítése

Fejléc

Verzió: 0100

Fejléc hossz: min. 20 oktet max. 24 oktet

Type of Service: Általában két részre osztják:

Precedencia (Prioritás)

TOS (Késleltetés, Sávszélesség, Megbízhatóság, Pénz) Diffserv-nél használják

Csomag hossz: max 64K, tipikusan 1500 Byte

Azonosító (a darabolt csomag részek azonosítója)

Jelző zászlók: nem darabolható (MTU tesztelés), darab jön még

Time-to-Live: Hurkok kezelése, implementáció függő, tarceroute!

Protocol: ICMP, IGMP, TCP, UDP, RSVP, OSPF, …

Fejléc ellenőrző kód

Opciók:

Laza forrás forgalomirányítás Szigorú forgalom irányítás Útvonal naplózása

Időbélyeg rögzítés

Tartalom

(5)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Fragmentálás és összefűzés

 Maximal Transfer Unit – MTU

 Fejléc mezők

■ Az eredeti csomag azonosítása (ID bitek)

■ A darab csomag helyének azonosítása (8 bájtonként)

 Ha egy darab

elveszik, az egész

kidobható!!!!

(6)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv4 címek

 32 bites címek

 Minden eszköznek egyedi IP cím (elvileg ->

NAT/PAT, Proxy,…)

 Hierarchikus címzés

Hálózat cím - a hálózatot azonosítja

Host cím – a hálózatra kötött eszközt azonosítja az adott hálózaton belül

 Ábrázolása:

Bináris (időnként jobban megérthető, valójában ezt látja a forgalomirányító)

100000000100000000100000000100000000

Decimális (leggyakoribb) 128.128.128.128

Hexadecimális (ritkán pl.: SNMP ábrázolás) 80:80:80:80

(7)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Cím tartományok

Cím osztályok

Első oktet szabály:

A 1000 – 0 - 127 B 11xx – 128 -191 C 1110 – 192 - 223

A osztályú címek nagy hálózatoknak, B osztály címek

közepes hálózatoknak, C osztályú címek kicsi hálózatoknak

Cím maszk (Address mask) a hálózati és a host részt különíti el

Típusai:

A osztályú címek: 8 bit -> 255.0.0.0 = /8

B osztályú címek: 16 bit -> 255.255.0.0 = /16 C osztályú címek: 24 bit -> 255.255.255.0 = /24

A cím és a maszk logikai és kapcsolata adja meg a hálózati címet

(8)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Alhálózat

Az előző felosztásban egy B osztályú cím esetében egy hálózaton 65000 eszköz lenne ez egy kicsit sok…

Alhálózatok segítségével lehet tovább osztani a nagy címtartományokat

A host részből is hozzácsapunk néhányat bitet a hálózati részhez

Alhálózati maszkkal határozzuk ezt meg (subnet mask) (hosszabb mint a hálózati maszk! További

álatalánosítás osztály mentes címzés clasless)

IP cím:

Hálózat

Alhálózat

(9)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IP cím osztályok

 A,B,C,D,E osztályú címek

 Foglalt címek:

■ Host rész 1 – broadcast

■ Host rész 0 – network address

 Privát cím tartományok

(10)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Forgalomirányító

 Általában a cél IP cím és a

forgalomirányító táblája alapján hozza

meg döntéseit

(11)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

ARP

 Az IP cím nem elegendő a kommunikációhoz

 Szükség van 2 rétegbeni címre is

■ Átjáró címe

■ A cél címe

 Address Resolution Protocol (ARP)

■ IP címhez keresünk MAC címet

(12)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

ICMP

Internet Control Message Protocol

RFC 792, RFC 1700

Faladata a hálózat menedzselése

Az ICMP üzenetek

elvesztése nem jár újabb ICMP üzenetek kiküldésével

Típusai:

Hiba üzenetek

Kérdések

Válaszok

Gyakran használt ICMP üzenetek:

Echo request – echo reply ->

Ping

Echo request – echo reply +

(13)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

A cél elérhetetlen

 Destination unreachable

(14)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Példa

Hálózat R 128.135.0.0

Hálózat 128.140.0.0

H H

H H H

R = router

Interfész cím

128.135.10.2 Interfész cím 128.140.5.35

128.135.10.20 128.135.10.21 128.135.40.1

128.140.5.36 128.140.5.40

A host részen csak 0-t tartalmazó cím a hálózat cím

(15)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Alhálózatok kialakítása

 Egy új szintet ad

 Transzparens a távoli hálózatok számára

 Az alhálózati maszk segítségével azonosítják

(16)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Példa

Van egy B osztályú címünk: (16 host ID bit) a hálózati cím: 150.100.0.0

Osszuk fel úgy alhálózatokra, hogy 100 cím jusson mindegyikre

7 bit elég minden alhálózatra

16-7=9 bit az alhálózatok azonosítására

Az alhálózati maszk segítségével tudjuk kideríteni egy IP cím alhálózatát

Példa: 150.100.12.176

IP cím = 10010110 01100100 00001100 10110000

Maszk = 11111111 11111111 11111111 10000000

ÉS = 10010110 01100100 00001100 10000000

Alhálózat = 150.100.12.128

(17)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

R1

H1 H2

H3 H4

R2 H5

To the rest of the Internet

150.100.0.0

150.100.12.128

150.100.12.0

150.100.12.176 150.100.12.154

150.100.12.24 150.100.12.55

150.100.12.1

150.100.15.54

150.100.15.0

150.100.15.11 150.100.12.129

150.100.12.4

Alhálózat példa

(18)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Forgalomirányítás alhálózatokkal

 Az IP réteg egy forgalomirányító táblát menedzsel

 A forrás: Az IP csomag elküldése előtt megnézi a forgalomirányító táblát

■ Amennyiben a cél cím ugyanazon a hálózaton van akkor elküldi az adatkapcsolati címre

■ Egyébként indirekt módon a tábla jelzi a következő ugrást ami egy forgalomirányító

 Forgalomirányító: Megnézi a cél címet és:

■ Ha a sajátja akkor feldolgozza, ha nem akkor a

forgalomirányító táblájában kikeresi a következő

ugrás cél címét

(19)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Forgalomirányító tábla

 Az alábbiakat

tartalmazhatja minden sor:

■ Cél IP cím

■ A következő ugrás IP címe

■ Fizikai cím

■ Statisztikai információk

Forgalomirányító tábla keresési sorrend és akció

Teljes cél cím; a következő ugrásra küldi

Cél hálózati cím; a

következő ugrásra küldi

Alapértelmezett útvonal bejegyzés; a következő ugrásra küldi

A csomag kézbesíthetetlen;

Egy ICMP “host

unreachable error” csomagot küld a forrás címre

(20)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Példa H5-H2 kommunikáció

R1

H1 H2

H3 H4

R2 H5

To the rest of the Internet

150.100.0.1

150.100.12.128

150.100.12.0

150.100.12.176 150.100.12.154

150.100.12.24 150.100.12.55

150.100.12.1

150.100.15.54

150.100.15.0

150.100.15.11 150.100.12.129

150.100.12.4

Destination Next-Hop Mask Net I/F 127.0.0.1 127.0.0.1 8 lo0

default 150.100.15.54 0 emd0

150.100.15.0 150.100.15.11 24 emd0

H5 forgalomirányító tábla

150.100.12.176

(21)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Példa H5-H2 kommunikáció

R1

H1 H2

H3 H4

R2 H5

To the rest of the Internet

150.100.0.1

150.100.12.128

150.100.12.0

150.100.12.176 150.100.12.154

150.100.12.24 150.100.12.55

150.100.12.1

150.100.15.54

150.100.15.0

150.100.15.11 150.100.12.129

150.100.12.4

Destination Next-Hop Mask Net I/F 127.0.0.1 127.0.0.1 8 lo0

default 150.100.12.4 0 emd0

150.100.15.0 150.100.15.54 24 emd1

150.100.12.0 150.100.12.1 23 emd0

R2 forgalomirányító tábla 150.100.12.176

(22)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Példa H5-H2 kommunikáció

R1

H1 H2

H3 H4

R2 H5

To the rest of the Internet

150.100.0.1

150.100.12.128

150.100.12.0

150.100.12.176 150.100.12.154

150.100.12.24 150.100.12.55

150.100.12.1

150.100.15.54

150.100.15.0

150.100.15.11 150.100.12.129

150.100.12.4

Destination Next-HopMask Net I/F 127.0.0.1 127.0.0.1 8 lo0

150.100.12.128 150.100.12.129 23 emd0 150.100.12.0 150.100.12.4 23 emd1 150.100.15.0 150.100.12.1 24 emd1 R1 forgalomirányító tábla

150.100.12.176

(23)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Proxy-ARP

 A hostokon a netmask 0 –azaz minden címet a saját hálózatukon lévőnek gondolnak

 A forgalomirányító figyeli az ARP kéréseket és amikor látja, hogy valami nincs a hálózaton akkor saját MAC címét adja vissza.

 Előny:

Az alapértelmezett átjáró láthatatlanul cserélhető

Multihoming

 Hátrány:

Sok ARP kérés

Biztonsági problémák

Nagy ARP táblák

(24)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Cím duplikálás ellenőrzése

 Node Solicitation ICMP a Solicited node multicast csoportnak

(FF02::1:FFXX:XXXX)

■ Forrás IP ::

■ ICMP target az ellenőrizendő IP

 Ha valaki magára ismer:

■ Neighbor Advertisement a FE02::1 csoportnak

– Proxy esetén O=0

(25)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

A 90-es években ezek a problémák jelentkeztek:

Az IP címek kifogyóban voltak

A forgalomirányító táblák nagyon nagyra nőttek

IP cím kimerülés

A, B, és C cím osztályok nem voltak hatékonyak

A B osztály túl nagy a legtöbb szervezetnek A C túl kicsi

A B osztály foglalás a címek kifogyását vetítette előre

Az IP forgalomirányító tábla mérete

A hálózatok számának növekedése a bejegyzések számának növekedésével járt

1991-től 1995-ig 10 havonta megduplázódott a méretük

Komoly kihívás a forgalomirányítóknak (memória, feldolgozási kapacitás)

Megoldás:

Osztálymentes Tartományközi Forgalomirányítás (Classless Interdomain Routing (CIDR), RFC 1518)

Új cím allokációs szabályok (RFC 2050)

Privát cím tartományok

Hosszú távú megoldás: IPv6

Problémák az IPv4-es címzéssel

(26)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

A & B cím tartományokat csak nagyon indokolt esetben osztanak

Egymás után következő C

osztályú címeket osztana(max. 64 blokkot)

Egy tartományba eső IP címek közös előtaggal rendelkeznek, minden ezzel az előtaggal

rendelkező IP cím ebbe a tartományba esik

Tetszőleges előtag hossz, hatékonnyá teszi a cím kihasználást

A C osztályú címek alsó része ki lett osztva regionális

hatóságoknak

Sokkal hierarchikusabb cím kiosztás

Igény Kiosztás

< 256 1 Class C 256<,<512 2 Class C 512<,<1024 4 Class C 1024<,<2048 8 Class C 2048<,<4096 16 Class C 4096<,<8192 32 Class C 8192<,<16384 64 Class C

Új IP cím kiosztási szabály

(27)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Szuperhálózatok (Supernetting)

Egy folyamatos C osztályú cím csoportot egy változó hosszúságú maszkkal azonosítunk

Példa: 150.158.16.0/20

IP cím (150.158.16.0) & maszk hossz (20)

IP cím = 10010110 10011110 00010000 00000000

Maszk = 11111111 11111111 11110000 00000000

16 osztályú blokkot tartalmaz:

Kezdete 10010110 10011110 00010000 00000000

Pl.: 150.158.16.0

Vége 10010110 10011110 00011111 00000000

Pl.: 150.158.31.0

(28)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Classless Inter-Domain Routing

CIDR megoldás a forgalomirányító tábla robbanásra

A hálózatok előtaggal és maszkkal vannak azonosítva

A CIDR előtt: Egy 16 folyamatos C blokkot tartalmazó hálózathoz 16 bejegyzés kellett

A CIDR után: Egy 16 folyamatos C blokkot tartalmazó hálózathoz 1 bejegyzés kell

Megoldás: Maszk alapján nem az osztály alapján történik a forgalomirányítás

A forgalomirányító tábla bejegyzés: <IP cím, hálózati maszk>

Példa: 192.32.136.0/21

11000000 00100000 10001000 00000001 min cím

11111111 11111111 11111--- --- maszk

11000000 00100000 10001--- --- IP előtag

11000000 00100000 10001111 11111110 max cím

11111111 11111111 11111--- --- maszk

11000000 00100000 10001--- --- ugyanaz az előtag

(29)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

0000 0001 0010 0011

0100 0101 0110 0111

1100 1101 1110 1111 1000

1001 1010 1011

R1 R2

1

2 5

4 3

00 1 01 3 10 2 11 3

00 3 01 4 10 3 11 5

(a)

0000 0111 1010 1101

0001 0100 1011 1110

0011 0101 1000 1111 0011

0110 1001 1100

R1 R2

1

2 5

4 3

0000 1 0111 1 1010 1

0001 4 0100 4 1011 4

(b)

Hierarchikus forgalomirányítás

(30)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Cím aggregálás

(31)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

CIDR allokációs szabályok (RFC 1518-1520)

Az IP cím kiosztás a fizikai topológiát követi

A hálózati topológia nemzeti/kontinentális határokat követi

Az IP címeket ezek szerint kell kiosztani

Áthaladó forgalomirányító tartományok (Transit routing domains (TRDs)) saját IP előtaggal rendelkeznek

IP forgalmat szállít tartományok között

Nem feltétlenül hierarchikus, nemzetközi összeköttetések

A legtöbb forgalomirányító tartomány single-homed (egy TRD)

Ezen tartományok a TRD előtg darabját kaphatják

A TRD kifelé 1 bejegyzést hirdet

Megvalósítás BGPv4 (RFC 1520)

(32)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Miért használhatjuk a CIDR-t?

 Az Internet többé-

kevésbé hierarchikus

■ Felhasználók (cégek is)

■ Internet szolgáltatók

■ Regionális Internet szolgáltatók

■ Nemzetközi hálózat szolgáltatók

(33)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Leghosszabb előtag egyezés

 A CIDR befolyásolja a forgalomirányítást és a továbbítást

 A forgalomirányító tábláknak/protokolloknak foglalkoznia kell a címmel és a maszkkal is

 Több bejegyzés is megfelelhet egy cél címnek

 PL: A forgalomirányító tábla tartalmazhatja

■ 205.100.0.0/22 mely megfelel az adott szupernetnek

■ 205.100.0.0/20 mely nagyobb számú cél összefogásával jött létre

■ A csomagot a legjobban egyező irányba kell továbbítani (leghosszabb előtag egyezés)

 Több gyors leghosszabb előtag egyezés

algoritmus is ismert

(34)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

Problémák a CIDR-al

 Adminisztratív:

■ Multi homed forgalomirányító tartomány

■ Szolgáltató váltás (/19-es szabály)

 Forgalomirányítás pontatlanság

■ Aszimmetrikus forgalom

(35)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv6

Filozófiája: Az IPv4-en alapuló Internet nem lett volna ilyen sikeres, ha nem lett volna jó megoldás

Az IPv4-el kapcsolatos tapasztalatokat azonban beleépítették

Fix fejléc

Nincs fejléc ellenőrző összeg

Nincs ugrásonkénti darabolás

Probléma az IPv4-el: a cím tartomány kimerülőben van

IPv4 32 bites címtartomány

IPv6 128 bites címtartomány

Kommunikációs módok:

Unicast

Multiast

Anycast

(36)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv6 fejléc

 64 bites, fix méretű

 Verzió (Version) - 0110

 Osztály (Class) – Forgalom típus

 Folyam címke (Flow Label) – azonos elbánásmód

 A tartalom hossza (Length of the payload)

■ 64k de van Jumbogramm opció

 A következő fejléc típusa (Type of next header)

 Maximális ugrásszám (Hop limit)

(37)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv6 opcionális fejlécek

Routing

Laza forrás forgalomirányítás

Szigorú forrás forgalomirányítás

Fragment

A host darabolja

A címzett összerakja

Authentication

Encrypted security payload

Destination options

Csak a cél fogja feldolgozni

Tetszőleges információt hordozhat a jövőbeni bővíthetőség érdekében

Hop-by-Hop

Ugyanaz mint az előző csak minden ugrásnál feldolgozzák

Pl.: Jumbo payload

(38)

UNIVERSITY OF SZEGED Department of Software EngineeringUNIVERSITAS SCIENTIARUM SZEGEDIENSIS

IPv6 címek

128 bit

8x16 bites hexa számként ábrázolják:

FEDC:BA94:7654:3210:FEDC:BA98:7654:3210

A vezető nullák elhagyhatók:

FEDC:0094:0004:0000:000C:BA98:7654:3210

FEDC:94:4:0:C:BA98:7654:3210

A 16 bites nullákat tartalmazó részek kihagyhatóak ha egymás után vannak, max egy tömb hagyató ki:

FEDC:0000:0000:0000:000C:BA98:0000:3210

FEDC::C:BA98:0000:3210

Egyes IPv6-os címek IPv4-ből származnak ekkor megengedett:

0:0:0:0:0:0:A00:1

::10.0.0.1

Prefixek jelölése:

FEDB:ABCD:ABCD::/48

FEDB:ABCD:AB00::/40

Hivatkozások

KAPCSOLÓDÓ DOKUMENTUMOK

UNIVERSITY OF SZEGED Department of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS..

UNIVERSITY OF SZEGED Department of Software Engineering VERSITAS SCIENTIARUM SZEGEDIENSIS..

UNIVERSITY OF SZEGED Department of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS6.

UNIVERSITY OF SZEGED Department of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS.. Mobil alkalmazásfejlesztés - UI alapok

UNIVERSITY OF SZEGED Department of Software Engineering IVERSITAS SCIENTIARUM SZEGEDIENSIS.. Mobil alkalmazásfejlesztés -

UNIVERSITY OF SZEGED Department of Software Engineering UNIVERSITAS SCIENTIARUM SZEGEDIENSIS.. Mobil alkalmazásfejlesztés -

UNIVERSITY OF SZEGED Department of Software Engineering SITAS SCIENTIARUM SZEGEDIENSIS setMinimumLatency(long minLatencyMillis). ● A befejezés előtt megvárt minimális

UNIVERSITY OF SZEGED Department of Software Engineering SITAS SCIENTIARUM SZEGEDIENSIS.. Mobil alkalmazásfejlesztés