Компјутерски мрежи

Аудиториски вежби 3
Апликациски слој (потсетување од
предавања)
цели:  учење на протоколите
 концептуални, аспекти на со анализа на
имплементација на популарни протоколи на
протоколи за мрежна апликацискиот слој
апликација  HTTP
 услужни модели на  FTP
транспортен слој  SMTP / POP3 / IMAP
 Клиент-сервер  DNS
парадигма
 peer-to-peer парадигма
 мрежи за дистрибуција
на содржина
2-2
Некои мрежни апликации

 електронска пошта  Видео стриминг

 Веб (YouTube, Hulu, Netflix)
 испраќање/примање на  voice over IP (на
пораки пример, Skype)
 далечинско најавување  Видео конференции во
(remote login) реално време
 P2P споделување на  Социјални мрежи
фајлови  пребарување
 мрежни игри со повеќе  …
корисници
2-3
Креирање на мрежна апликација
application
Програми кои: transport
network
data link
 работат на (различни) крајни системи physical

 комуницираат преку мрежа

 на пр., софтверот на Веб серверот
комуницира со софтверот на
пребарувачот

Не треба да се пишува софтвер за

уредите од јадрото на мрежата application
transport
network
 уредите од јадрото на мрежата не data link application
transport
physical
извршуваат кориснички апликации network
data link
physical
 овој дизајн допринесе за брз развој и
размножување на мрежните
апликации
2-4
Архитектура на апликациите
можна структура на апликациите:
 Клиент-сервер
 peer-to-peer (P2P)

2-5
Пример за HTTP (клиентска страна)
1. Telnet на омилениот Веб сервер:
telnet gaia.cs.umass.edu 80
отвора TCP конекција на порта 80
(стандардна HTTP сервер порта)
на gaia.cs.umass.edu.
Се што ќе се внесе се праќа на
порта 80 на gaia.cs.umass.edu

2. внесете GET HTTP request:

GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu Со впишување на ова (треба да се
притисне carriage return два пати)
се праќа ова минимално (но комплетно)
GET request до HTTP серверот

3. Видете ги одговорите испратени од HTTP серверот!

(или користете Wireshark за да ги видите фатените HTTP request/response)
2-6 Апликациски слој
HTTP response статус кодови
 кодот за статус се појавува на првата линија
од сервер-клиент response пораката.
 некои пример кодови:
200 OK
 барањето е успешно, бараниот објект е во пораката
301 Moved Permanently
 бараниот објект е преместен, новата локација е специфицирана
подолу во пораката (Location:)
400 Bad Request
 барањето не е разбрано од серверот
404 Not Found
 Бараниот документ не е пронајден на серверот
505 HTTP Version Not Supported
2-7 Апликациски слој
 Пример за Веб кеш (“proxy” сервер)
претпоставки:
 просечна големина на објекти: 100K bits
изворни
 просечна рата на барања од прелистувачот до
изворниот сервер:15/sec сервери
јавен
 просечна податочна рата до прелистувачот: 1.50 Интернет
Mbps
 RTT од институционалниот рутер до било кој
изворен сервер: 2 sec
 рата на пристапниот линк: 1.54 Mbps
1.54 Mbps
последици: пристапен линк
проблем!
 LAN искористеност: 15% мрежа на
 искористеност на пристапниот линк = 97% институција
10 Мbps LAN
 Вкупно доцнење = Интернет доцнење +
доцнење за пристап + LAN доцнење
= 2 sec + минути + μ секунди

2-8 Апликациски слој

 Пример за кеш: подобрен пристапен линк
претпоставки:
 просечна големина на објекти: 100K bits
 просечна рата на барања од прелистувачот до изворни
изворниот сервер:15/sec
сервери
 просечна податочна рата до прелистувачот: јавен
1.50 Mbps Интернет
 RTT од институционалниот рутер до било кој
изворен сервер: 2 sec
 рата на пристапниот линк: 1.54 Mbps
последици: 15.4 Mbps 1.54 Mbps 15.4 Mbps
пристапен линк
 LAN искористеност: 15% 9.7%
 искористеност на пристапниот линк = 97% мрежа на
институција
 Вкупно доцнење = Интернет доцнење + 10 Мbps LAN
доцнење за пристап + LAN доцнење
= 2 sec+ минути + μ секунди
m секунди
Цена: зголемена брзина на пристапниот линк (не е евтино!)
2-9 Апликациски слој
 Кеш пример: инсталација на локален сервер
претпоставки:
 просечна големина на објекти: 100K bits
 просечна рата на барања од изворни
прелистувачот до изворниот сервер:15/sec сервери
јавен
 просечна податочна рата до
Интернет
прелистувачот: 1.50 Mbps
 RTT од институционалниот рутер до било
кој изворен сервер: 2 sec
 рата на пристапниот линк: 1.54 Mbps 1.54 Mbps
пристапен линк
последици
мрежа на
 LAN искористеност: 15%
институција
 искористеност на пристапниот линк = ? 10 Мbps LAN
 Вкупно доцнење = ?
локален
Како да се пресмета искористеноста Веб кеш
на линкот и доцнењето?
Цена: Веб кеш (евтино!)
2-10 Апликациски слој
 Кеш пример: инсталација на локален сервер

Искористеност на пристапниот
линк и доцнење со кеш: изворни
 Претпоставена рата на успех е 0.4 сервери
јавен
 40% од барањата се услужени од кешот,
Интернет
60% од барањата од изворните сервери
 пристапен линк:
 60% од барањата користат пристапен линк
 Податочна рата до прелистувач 1.54 Mbps
пристапен линк
преку пристапен линк
= 0.6*1.50 Mbps = .9 Mbps мрежа на
 искористеност = 0.9/1.54 = .58 институција
10 Мbps LAN
 вкупно доцнење
 = 0.6 * (доцнење од изворни сервери) +0.4 * локален
(доцнење од кеш) Веб кеш
 = 0.6 (2.01) + 0.4 (~m сек) = ~ 1.2 сек
 Помалку отколку со 154 Mbps линк (и поевтино!)
2-11 Апликациски слој
SMTP (Алиса праќа порака до Боб)
1) Алиса користи кор. агент за
составување на порака “до”
bob@someschool.edu
2) кор. агент на Алиса праќа е-
пошта до нејзиниот е-пошта
сервер; пораките се ставаат во
редицата на пораки
3) клиентската страна на SMTP
отвора TCP
конекција со е-пошта серверот на
Боб
4) SMTP клиентот праќа порака до
Алиса користејќи TCP конекција
5) е-пошта серверот на Боб ја праќа
пораката до сандачето на Боб
6) Боб го отвора неговиот кориснички
агент за да ја прочита пораката

1 кор. е-пошта кор.

е-пошта агент
агент сервер сервер
2 3 6
4
5
е-пошта сервер е-пошта сервер
2-12 на Алиса Апликациски слој
на Боб
Пример SMTP интеракција
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

2-13 Апликациски слој

Пробајте сами SMTP интеракција:
 telnet servername 25
 гледајте 220 одговор од серверот
 внесете HELO, MAIL FROM, RCPT TO, DATA, QUIT
команди

Горните команди овозможуваат праќање на е-пошта без

користење на е-пошта клиент (читач)

2-14 Апликациски слој

 Пример за DNS
разрешување на име
root DNS сервер

2
TLD (top-level domain)
 домаќин cis.poly.edu 3
DNS сервер
сака IP адреса за 4
gaia.cs.umass.edu 5

локален DNS сервер

итеративно барање: dns.poly.edu
 Контактираниот сервер 7 6
1 8
одговара со името на
серверот кој треба да
авторитативен DNS сервер
се контактира dns.cs.umass.edu
 “Не го знам ова име, домаќин кој бара
но прашај го овој cis.poly.edu

сервер”
gaia.cs.umass.edu

2-15 Апликациски слој

Пример за DNS
разрешување на име
root DNS сервер

2 3
7
рекурзивно 6
барање: TLD DNS
серверr
 го става товарот на
контактираниот локален DNS сервер
dns.poly.edu 5 4
сервер
 Големо 1 8
оптоварување на
авторитативен DNS сервер
горните слоеви од dns.cs.umass.edu
хиерархијата? домаќин кој бара
cis.poly.edu

gaia.cs.umass.edu

2-16 Апликациски слој

Чиста P2P архитектура
 нема “секогаш вклучен” сервер
 произволни крајни системи
директно комуницираат
 “peers” наизменично се
поврзуваат и менуваат IP
адреси
примери:
 дистрибуција на фајлови
(BitTorrent)
 Стриминг (KanKan)
 VoIP (Skype)
2-17
 Дистрибуција на фајлови: клиент-
сервер vs P2P
Прашање: колку време е потребно да се дистрибуира
фајл (со големина F) од еден сервер до N peers?
 “upload/download” капацитетот на peer е ограничен ресурс
us: upload
капацитет на
серверот

di: peer i download

u1 d1 капацитет
фајл, us u2 d2
големина F сервер
di
uN мрежа (со голем
пропусен опсег) ui
dN
ui: peer i upload
капацитет

2-18
 Време за дистрибуција на фајл: клиент-
сервер
 Серверска трансмисија: мора
последователно да постави N F
us
копии од фајлот: di
 време за поставување на една мрежа
ui
копија: F/us
 време за N копии: NF/us
 клиент: секој клиент мора да симне копија
• dmin = минимална рата на симнување на клиент
• минимално време за симнување на клиент: F/dmin

време за дистрибуција на F
до N клиенти кои користат
клиент-сервер пристап Dc-s > max{NF/us,,F/dmin}
Се зголемува линеарно со N
2-19
 Време за дистрибуција на фајл: P2P
 Серверска трансмисија: мора
F
да постави најмалку една us
копија di
 време за една копија: F/us мрежа
ui
 клиент: секој клиент мора да симне копија
• мин. време за симнување на клиентот: F/dmin
 клиенти како збир мора да симнат NF битови
• Максимална рата на поставување (ограничувајќи ја
максималната рата на симнување) е us + Sui
време за дистрибуција
на F до N клиенти D
кои користат P2P
> max{F/us,,F/dmin,,NF/(us + Sui)}
P2P пристап
Се зголемува линеарно со N …
… но исто и овој член, бидејќи секој peer носи услужен капацитет
2-20
Клиент-сервер vs. P2P: пример
“upload” рата на клиент= u, F/u = 1 hour, us = 10u, dmin ≥ us
3.5
P2P
Minimum Distribution Time

3
Client-Server
2.5

1.5

0.5

0
0 5 10 15 20 25 30 35

21
P2P дистрибуција на фајлови: BitTorrent
 фајлот е поделен на 256Kb делови
 peers во torrent испраќаат/примаат делови од фајлови
tracker: ги следи peers torrent: група на peers кои
кои учествуваат во torrent разменуваат делови од
фајл

Алиса пристигнува…
… добива листа на
peers од tracker
… и почнува размена на
делови од фајлот соpeers
во torrent
2-22
 P2P дистрибуција на фајлови: BitTorrent

 peer кои се приклучуваат на torrent:

 немаат делови, но со тек на време
ќе ги акумулираат од други peers
 се регистрира со tracker за да добие
листа на peers, се поврзува со
подмножество на peers (“соседи”)

 додека симнува, peer поставува делови на други peers

 peer може да промени peers со кој си разменува делови
 churn: peers може да дојдат и да си одат
 откако еден peer го има целиот фајл, може (себично) да
напушти или (дарежливо) да остане на torrent
2-23 Апликациски слој
BitTorrent: барање, испраќање на
делови на фајл
барање на делови:
испраќање делови: tit-for-tat
 Алиса испраќа делови до
 во било кој момент, оние четворица peers кои
различни peers имаат моментно нејзе и испраќаат
различно подмножество делови со најголема брзина
• други peers се блокирани од
на делови од фајл Алиса (не добиваат делови од
 повремено, Алиса бара од нејзе)
• ре-евалуација на топ 4-те се
секој peer список на прави на секои 10 секунди
делови што ги имаат  секои 30 секунди: по случаен
избор се избира нов peer,
 Алис ги бара деловите
почува праќање на делови
што недостасуваат од • “оптимистички се одблокирува”
peers, почнујавќи од овој peer
• Ново избраниот peer може да се
најретките приклучи на топ 4-те
2-24
BitTorrent: tit-for-tat
(1) Алиса “оптимистички го одблокирува” Боб
(2) Алиса станува еден од најдобрите четири провајдери на Боб;
Боб возвраќа
(3) Боб станува еден од најдобрите четири провајдери на Алис

повисока upload рата: најди

подобар партнер, доби го
фајлот побрзо!
2-25
 Задачи и прашања

Компјутерски мрежи и безбедност

26
Пример 1
 Разгледајте ја сликата подолу,
каде што клиентот испраќа
HTTP GET порака до веб-
серверот, gaia.cs.umass.edu.
 Претпоставете дека HTTP
GET пораката од клиент до
сервер е следната:
GET /kurose_ross/interactive/quotation5.htm HTTP/1.1
Host: gaia.cs.umass.edu
Accept: text/plain, text/html, text/xml, image/png, image/jpeg,
audio/vnf.wave,
audio/mpeg, video/mp4, video/wmv, application/*, */*
Accept-Language: en-us, en-gb;q=0.3, en;q=0.5, fr, fr-ch, zh, fi, ar
If-Modified-Since: Wed, 09 Oct 2019 02:23:25 -0700
User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64;
Trident/5.0)

27
Пример 1
 Одговорете ги следните прашања:
 Кое е името на фајлот што се презема во оваа GET порака?
 решение: Фајлот е /kurose_ross/interactive/quotation5.htm
 Која верзија на HTTP користи клиентот?
 решение : Клиентот користи HTTP верзија 1.1.
 Што означуваат низите "application/*" и "*/*" кај Accept:
заглавјето?
 решение : “application/*” типот означува дека прелистувачот
ќе ги прифати сите подтипови од типот на апликацијата, а
“*/*” означува дека прелистувачот ќе ги прифати сите
типови и подтипови, така што “application/*” е излишно.

28
Пример 1
 Кои јазици прелистувачот означува дека е подготвен да ги
прифати?
 решение: Прифатени јазици се en-us (American English), en-gb
(British English), en (English), fr (French), fr-ch (Swiss French), zh
(Chinese), fi (Finnish), ar (Arabic).
 Кое е значењето на „факторот за релативен квалитет“, q,
поврзано со различната верзија на англиски јазик?
 решение: Релативниот фактор за квалитет, q, "укажува на
релативниот степен на претпочитање за тој опсег на
медиуми, користејќи ја скалата од 0 до 1" [RFC 2616].
Помала вредност на q означува дека прелистувачот
помалку го преферира тој подтип на медиум.

29
Пример 1
 Која е најпосакуваната верзија на англискиот јазик на клиентот?
Која е најмалку преферираната верзија на англискиот јазик на
прелистувачот?
 решение: Прелистувачот претпочита американски англиски,
бидејќи има имплицитна q вредност од 1, но ќе прифати или
британски англиски или ванила англиски. Најмалку посакуваната
верзија на прелистувачот на англиски јазик е британски
англиски, бидејќи има помала q вредност од ванила англискиот.
 Дали прелистувачот што ја испраќа HTTP пораката претпочита
швајцарски француски во однос на традиционалниот француски?
Објаснете.
 решение: Прелистувачот не прави разлика помеѓу ванила
француски или швајцарски француски, бидејќи нема
специфицирана q вредност.
30
Пример 1
 Дали клиентот веќе има (можеби застарена) копија на бараниот
фајл? Објаснете. Ако е така, приближно пред колку време
клиентот го примил фајлот, претпоставувајќи дека GET барањето
штотуку е издадено?
 решение: Времето означено во полето „If-Modified-Since“ од
прелистувачот е Wed, 09 Oct 2019 02:23:25 -0700, што покажува
дека има зачувана копија. Затоа, серверот ќе испрати копија од
бараното URL како одговор на оваа HTTP GET порака само ако
копијата на страната на серверот е изменета по Wed, 09 Oct
2019 02:23:25 -0700
 Кој е типот на прелистувач и оперативниот систем на клиентот?
 решение: User Agent: полето има вредност Mozilla/5.0 (compatible;
MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) што значи дека
клиентот користи IE 9.0, Win7 64-bit.
31
 Пример 2
 Серверот праќа HTTP
RESPONSE порака назад до
клиентот.
 Претпоставете дека HTTP
RESPONSE пораката е
следна:
HTTP/1.0 404 Not Found
Date: Wed, 09 Oct 2019 10:18:43
+0000
Server: Apache/2.2.3 (CentOS)
Content-Length: 274
Connection: Close
Content-type: image/html

32
Пример 2
 Одговорете ги следните прашања:
 Дали response пораката користи HTTP 1.0 или HTTP 1.1?
Објасни.
 решение: Серверот користи HTTP верзија 1.0.
 Дали серверот успешно го испратил документот?
Објаснете.
 решение: Не, серверот не бил во можност успешно да го
испрати документот. Кодот за статус “404 Not Found”
означува дека има грешка во трансферот на фајлот.
 Колку бајти има во документот што го враќа серверот?
 решение: Има 274 бајти во документот.

33
Пример 2
 Кој е стандардниот начин на поврзување за HTTP
протоколот? Дали конекцијата е постојана или
непостојана? Објаснете.
 решение: Стандардниот начин на поврзување на HTTP е
постојан. Конекцијата во одговорот е постојана, што се
покажува со полето Connection: Close.
 Кое е името на серверот и неговата верзија?
 решение: серверот што се користи е Apache/2.2.3.

34
 Пример 3
 Да претпоставиме дека во рамките на вашиот
Веб прелистувач ќе кликнете на линк за да
добиете Веб страница. IP адресата за URL-то
не е зачувана во вашиот локален домаќин,
затоа е потребно да се побара DNS
пребарување за да се добие IP адресата. Да
претпоставиме дека само еден DNS сервер,
локалниот DNS кеш, е посетен со RTT
доцнење од RTT0 = 2 msecs. Првично, да
претпоставиме дека веб-страницата поврзана
со линкот содржи точно еден објект, кој се
состои од мала количина на HTML текст. Да
претпоставиме дека RTT помеѓу локалниот
домаќин и веб-серверот што го содржи
објектот е RTTHTTP = 86 msecs.
35
Пример 3 – Задача 1
 Ако претпоставиме дека времето на трансмисија на
HTML објектот е нула, колку време поминува од кога
клиентот ќе кликне на линкот додека клиентот го
добие објектот?
 решение: Времето од кога барањето е направено во
прелистувачот, сè додека не се прикаже страницата во
прелистувачот, е: RTT0 + 2*RTTHTTP = 2 + 2*86 = 174
msecs. Забележете дека 2 RTTHTTPа се потребни за
HTML објектот - едно RTTHTTP за воспоставување TCP
конекција, а потоа едно RTTHTTP за извршување на
HTTP GET/response преку таа TCP конекција.

36
 Пример 3 – Задача 2
 Сега, да претпоставиме дека HTML референцира 9 многу мали објекти
на истиот Веб-сервер. Занемарувајќи ги времето на трансмисија,
колку време изминува од кога клиентот ќе кликне на линкот сè додека
основниот објект и сите 9 дополнителни објекти се примат кај
клиентот, под претпоставка дека се користи непостојан HTTP и нема
паралелни TCP врски?
 решение: Времето од кога ќе се направи барањето на прелистувачот
до прикажувањето на страната на прелистувачот е: RTT0 + 2*RTTHTTP +
2*9*RTTHTTP = 2 + 2*86 + 2*9*86 = 1722 msecs. Забележете дека два
RTTHTTP се потребни за основниот HTML објект - еден RTTHTTP за
воспоставување на TCP конекција и еден RTTHTTP за испраќање на
HTTP request, и примање на HTTP reply. Потоа, сериски, за секој од 9-
те вградени објекти, има доцнење од 2*RTTHTTP , едно RTTHTTP за
воспоставување TCP конекција и едно RTTHTTP за извршување на
HTTP GET/response преку TCP конекцијата.
37
 Пример 3 – Задача 3
 Повторете го претходниот пример, но претпоставете дека клиентот е
конфигуриран така да може да поддржи максимум 5 паралелни TCP
конекции, со непостојан HTTP.
 решение: Времето од кога ќе се направи барањето на прелистувачот до
прикажувањето на страната на прелистувачот е : RTT0 + 2*RTTHTTP +
2*RTTHTTP + 2*RTTHTTP = 2 + 2*86 + 2*86 + 2*86 = 518 msecs. Како и
претходно, два RTTHTTP се потребни за основниот HTML објект - еден
RTTHTTP за воспоставување на TCP конекција и еден RTTHTTP за испраќање
на HTTP request, и примање на HTTP reply. Откако ќе се прими основниот
објект кај клиентот, максимум 5 барања може паралелно да се пратат, секој
барјќи еден од 9-те објекти. За секое (паралелно) барање треба два
RTTHTTP - едно RTTHTTP за воспоставување TCP конекција, и едно RTTHTTP за
извршување на HTTP GET/response за објектот. Откако првите 5 објекти ќе
се добијат, останатите 4 се бараат исто така паралелно. Втората рунда на
HTTP GET/response за добивање на останатите 4 објекти одзема уште две
RTTHTTP .
38
 Пример 3 – Задача 4
 Повторете ја задача 2, но претпоставете дека клиентот е конфигуриран
така да може да поддржи максимум 5 паралелни TCP конекции, со
постојан HTTP.
 решение: Времето од кога ќе се направи барањето на прелистувачот до
прикажувањето на страната на прелистувачот е : RTT0 + 2*RTTHTTP + RTTHTTP +
RTTHTTP = 2 + 2*86 + 86 + 86 = 346 msecs. Како и претходно, два RTTHTTP се
потребни за основниот HTML објект - еден RTTHTTP за воспоставување на
TCP конекција и еден RTTHTTP за испраќање на HTTP request, и примање на
HTTP reply. Но, со постојан HTTP, оваа TCP конекција останува отворена за
наредни HTTP requests. Откако ќе се прими основниот објект кај клиентот,
максимум 5 барања може паралелно да се пратат, секој барајќи еден од 9-те
објекти. Секое (паралелно) барање одзема еден RTTHTTP за извршување на
HTTP GET/response за објектите. Откако првите 5 објекти ќе се добијат,
останатите 4 се бараат исто така паралелно. Втората рунда наHTTP
GET/response за добивање на останатите 4 објекти одзема само едно
RTTHTTP , бидејќи TCP конекцијата останува отворена.
39
Пример 3 – Задача 5
 Што забележувате за целокупните доцнења (земајќи
ги предвид и доцнењата на DNS и HTTP) што сте ги
пресметале во задачите 2, 3 и 4 од овој пример?
 решение: Доцнењето во случајот 4 е помало од
доцнењето во случајот 3, што е помало од доцнењето
во случајот 2.

40
 Пример 4
 Проблемот е да се дистрибуира фајл со големина F = 4 Gbits на секој
од 7 корисници (peers). Претпоставете дека серверот има upload рата
од u = 82 Mbps, и дека 7-те peers имаат upload рата од:
u1 = 26 Mbps, u2 = 20 Mbps, u3 = 16 Mbps, u4 = 20 Mbps, u5 = 20 Mbps,
u6 = 15 Mbps, u7 = 10 Mbps,
и download рати од:
d1 = 24 Mbps, d2 = 27 Mbps, d3 = 40 Mbps, d4 = 28 Mbps, d5 = 31 Mbps,
d6 = 34 Mbps, d7 = 14 Mbps

41
Пример 4 – П1
 Кое е минималното време потребно за
дистрибуирање на овој фајл од централниот сервер до
7-те peers со помош на моделот клиент-сервер?
 решение: Минималното време за дистрибуција на
овој фајл со клиент-сервер моделот е 341.46 secs.

42
Пример 4 – П2
 За прашање 1, кој е главниот фактор за ова
минимално време: upload ратата на серверот или
download ратата на некој клиент (ако да, на кој?).
Објаснете.
 решение: Главниот фактор е upload ратата на серверот.
Користејќи ја равенката од слајд 8, минималното
време за дистрибуција на фајлот е Dcs = max{NF/us ,
F/dmin} = max{ 341.46, 285.71 }

43
Пример 4 – П3
 Кое е минималното време потребно за
дистрибуирање на овој фајл со помош на моделот
P2P?
 решение: Минималното време за дистрибуција на
овој фајл со P2P моделот е 285.71 secs.

44
Пример 4 – П4
 За прашање 3, кој е главниот фактор за ова
минимално време: upload ратата на серверот или
download ратата на некој клиент (ако да, на кој?) или
сумата на upload ратите на серверот и на peers?
Објаснете.
 решение: Главниот фактор за ова минимално време е
download ратата на одреден клиент – клиент 7.
Користејќи ја равенката од слајд 9, минималното
време е DP2P = max{F/us , F/dmin , NF/(us + ∑ui)} = max{
48.78, 285.71 , 133.97}

45
 Пример 5
 Проблемот е да се дистрибуира фајл со големина F = 7 Gbits на секој
од 8 корисници (peers). Претпоставете дека серверот има upload рата
од u = 75 Mbps и дека 8-те peers имаат upload рата од :
u1 = 23 Mbps, u2 = 13 Mbps, u3 = 12 Mbps, u4 = 16 Mbps, u5 = 28 Mbps,
u6 = 15 Mbps, u7 = 29 Mbps, u8 = 10 Mbps,
и download рати од:
d1 = 17 Mbps, d2 = 10 Mbps, d3 = 17 Mbps, d4 = 29 Mbps, d5 = 20 Mbps,
d6 = 23 Mbps, d7 = 34 Mbps, d8 = 32 Mbps

46
Пример 5 – П1
 Кое е минималното време потребно за
дистрибуирање на овој фајл од централниот сервер до
8-те peers со помош на моделот клиент-сервер?
 решение: Минималното време за дистрибуција на
овој фајл со клиент-сервер моделот е 746.67 secs.

47
Пример 5 – П2
 За прашање 1, кој е главниот фактор за ова
минимално време: upload ратата на серверот или
download ратата на некој клиент (ако да, на кој?).
Објаснете.
 решение: Главниот фактор е upload ратата на серверот.
Користејќи ја равенката од слајд 8, минималното
време за дистрибуција на фајлот е Dcs = max{NF/us ,
F/dmin} = max{ 746.67, 700 }

48
Пример 5 – П3
 Кое е минималното време потребно за
дистрибуирање на овој фајл со помош на моделот
P2P?
 решение: Минималното време за дистрибуција на
овој фајл со P2P моделот е 700 secs.

49
Пример 5 – П4
 За прашање 3, кој е главниот фактор за ова
минимално време: upload ратата на серверот или
download ратата на некој клиент (ако да, на кој?) или
сумата на upload ратите на серверот и на peers?
Објаснете.
 решение: Главниот фактор за ова минимално време е
download ратата на одреден клиент – клиент 2.
Користејќи ја равенката од слајд 9, минималното
време е DP2P = max{F/us , F/dmin , NF/(us + ∑ui)} = max{
93.33, 700 , 253.39}

50