4η Γραπτή Εργασία ΠΛΗ...

Click here to load reader

  • date post

    10-Jan-2020
  • Category

    Documents

  • view

    0
  • download

    0

Embed Size (px)

Transcript of 4η Γραπτή Εργασία ΠΛΗ...

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    1

    4η Γραπτή Εργασία ΠΛΗ 23 Ακαδημαϊκό Έτος 2011 - 2012

    ( Τόμος Β’, Κεφάλαια 4 – 8 και Τόμος Γ’ ) Ημερομηνία Παράδοσης 06.05.2012

    ΕΝΔΕΙΚΤΙΚΕΣ ΑΠΑΝΤΗΣΕΙΣ

    Άσκηση 1

    Επέκταση συστήματος διαδραστικού ημερολογίου με χρήση XML/XSL

    Στην Άσκηση αυτή ζητείται να προσθέσετε κάποιες λειτουργίες στο σύστημα που αναπτύχθηκε στα πλαίσια της 3ης Εργασίας. Μπορείτε να χρησιμοποιήσετε είτε το σύστημα που αναπτύξατε εσείς, είτε το σύστημα των υποδειγματικών απαντήσεων.

    Υποθέστε ότι ένας χρήστης θέλει να εξάγει τη λίστα των υπενθυμίσεων που έχει καταχωρήσει στην πλατφόρμα που έχετε αναπτύξει, ώστε να την αποθηκεύσει τοπικά στο σύστημά του. Η εξαγωγή θα γίνεται με χρήση XML αρχείων που περιέχουν κατάλληλα δομημένα τα δεδομένα αυτά. Για το σκοπό αυτό θα πρέπει:

    (a) (Ερώτηση 1) Να περιγράψετε τη δομή του XML αρχείου, ορίζοντας το κατάλληλο σχήμα με χρήση DTD. Επίσης, να παρουσιάσετε ένα παράδειγμα ενός σωστά δομημένου και έγκυρου XML αρχείου.

    (b) (Ερώτηση 2) Στην αρχική σελίδα του ημερολογίου, θα πρέπει να προστεθεί μία επιλογή με την οποία θα εμφανίζεται σε νέο παράθυρο το XML αρχείο (το οποίο θα δημιουργείται δυναμικά) μορφοποιημένο κατάλληλα με XSL. Η λίστα των υπενθυμίσεων στο XML αρχείο εκτός από τον τίτλο της κάθε υπενθύμισης, θα πρέπει να περιλαμβάνει και τις υπόλοιπες πληροφορίες, δηλαδή την ημερομηνία και ώρα, την περιγραφή και τη λίστα των ετικετών που τη χαρακτηρίζουν. Οι υπενθυμίσεις θα πρέπει να εμφανίζονται με αντίστροφη χρονολογική σειρά, δηλαδή από τη νεότερη στην παλαιότερη.

    (c) (Ερώτηση 3) Πριν την εμφάνιση των XML αρχείων με τη χρήση XSL, θα πρέπει να προστεθεί έλεγχος του παραγόμενου XML με βάση το DTD του (a). Σε περίπτωση λάθους, θα πρέπει να εμφανίζεται αντίστοιχο μήνυμα στο χρήστη. Τέλος, στην κορυφή της τροποποιημένης σελίδας (b) θα πρέπει να εμφανίζεται ο συνολικός αριθμός των υπενθυμίσεων που έχουν καταχωρηθεί στο ημερολόγιο. Η λειτουργία αυτή θα πρέπει να υλοποιηθεί είτε με συνάρτηση της XSL, είτε με χρήση DOM.

    Για την ανάγνωση ενός XML αρχείου, η PHP προσφέρει διάφορες βιβλιοθήκες (http://gr.php.net/manual/en/refs.xml.php).

    DOMDocument (http://gr.php.net/manual/en/class.domdocument.php).

    SimpleXML (http://gr.php.net/manual/en/book.simplexml.php).

    http://gr.php.net/manual/en/refs.xml.phphttp://gr.php.net/manual/en/class.domdocument.phphttp://gr.php.net/manual/en/book.simplexml.php

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    2

    Η βιβλιοθήκη DOM δίνει τη δυνατότητα ελέγχου του XML αρχείου με βάση το DTD για την εγκυρότητα ή όχι της δομής: http://php.net/manual/en/domdocument.validate.php Επίσης, για έλεγχο της εγκυρότητας του XML με βάση το DTD στην SimpleXML, δείτε εδώ: http://www.phpbuilder.com/columns/adam_delves20060719.php3 Εναλλακτικά, ο έλεγχος μπορεί να γίνει με JavaScript όπως περιγράφεται εδώ : http://www.w3schools.com/dtd/dtd_validation.asp Οι βιβλιοθήκες DOMDocument και SimpleXML της PHP, υποστηρίζουν Ελληνικούς χαρακτήρες με χρήση της κωδικοποίησης UTF-8. Αν χρησιμοποιείτε διαφορετική κωδικοποίηση, χρήσιμη θα σας φανεί η συνάρτηση iconv().

    Παραδοτέα:

    Ο DTD ορισμός της δομής και τουλάχιστον ένα XML αρχείο που θα λειτουργεί σωστά με την εφαρμογή σας (a).

    Ο HTML/PHP κώδικας της εφαρμογής που υλοποιεί τα (b) και (c).

    Τα XSL αρχεία (b), (c).

    Screenshots από τη λειτουργία της εφαρμογής.

    Στόχος: Η κατανόηση και η πρακτική εφαρμογή των τεχνικών προγραμματισμού εφαρμογών παγκόσμιου ιστού με χρήση XML, DTD, DOM, XSL. Απαραίτητες γνώσεις: Για την καλύτερη κατανόηση των εννοιών και των προγραμματιστικών τεχνικών, είναι χρήσιμη η παρακολούθηση των παρουσιάσεων web casts No 8 – 11, καθώς και η μελέτη του «UNIT23 - Book2 - HT2» και του νέου ΕΔΥ με hypertext υλικό για «Μετασχηματισμό XML αρχείων με χρήση XSL, μέσω PHP» από το 2ο CD του ΕΔΥ. Επίσης, βοηθητική είναι και η χρήση των σχετικών χρήσιμων δικτυακών τόπων από τη σελίδα της Θ.Ε.

    http://php.net/manual/en/domdocument.validate.phphttp://www.phpbuilder.com/columns/adam_delves20060719.php3http://www.w3schools.com/dtd/dtd_validation.asp

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    3

    ΑΠΑΝΤΗΣΕΙΣ ΑΣΚΗΣΗΣ 1

    (a) Ερώτηση 1.

    Η δομή του XML αρχείου είναι η εξής:

    To DTD που καθορίζει τη μορφή του παραπάνω XML αρχείου έχει την παρακάτω δομή:

    ]>

    Το παραπάνω DTD δηλώνει ότι το root element θα είναι το calendar, το οποίο μπορεί να έχει κανένα, ένα ή περισσότερα παιδιά, εδώ το element reminder. Δηλαδή μπορεί το ημερολόγιο να έχει ή να μην έχει υπενθυμίσεις. Εν συνεχεία δηλώνει ότι το κάθε element reminder θα έχει παιδιά τα εξής elements: title (τουλάχιστον 1), description (τουλάχιστον 1), tags (μπορεί να έχει ή και να μην έχει κανένα), date(τουλάχιστον 1), time(τουλάχιστον 1)). Το κάθε ένα από αυτά τα elements θα είναι της μορφής περιεχομένου (#PCDATA). Το tags επίσης αν υπάρχει θα έχει παιδί το tag (θα υπάρχει τουλάχιστον ένα tag).

    (b) Ερώτηση 2.

    Στην αρχική σελίδα του ημερολογίου προσθέσαμε ένα button με τίτλο XML, όπου πατώντας το, εμφανίζονται σε νέο παράθυρο όλες οι υπενθυμίσεις από τη νεότερη στην παλαιότερη με την κατάλληλη μορφοποίηση του XML με τη χρήση XSL. Για την εισαγωγή του button προσθέσαμε στο αρχείο index.php στη γραμμή 47 τον εξής κώδικα:

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    4

    που οδηγεί στην εμφάνιση του παρακάτω κουμπιού στην κεντρική σελίδα της εφαρμογής (Εικόνα 1):

    Εικόνα 1. Εμφάνιση XML button

    Με το onclick καλούμε τη συνάρτηση xml_remider() την οποία έχουμε φτιάξει στο αρχείο edit.js:

    //Εμφάνιση με XML των υπενθυμίσεων function xml_reminder() { var str="./xml_reminder.php"; window.open(str); }

    Έτσι, όταν πατάμε το κουμπί, εμφανίζεται ένα νέο παράθυρο με τις υπενθυμίσεις, με τη μορφή που έχει δοθεί από το παρακάτω XSL αρχείο:

    Υπενθύμιση Περιγραφή Ετικέτες Ημερομηνία

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    5

    Ώρα

    Έχουν καταχωρηθεί συνολικά υπενθυμίσεις

    Το αρχείο calendar.xsl δηλώνει ότι οι υπενθυμίσεις θα εμφανίζονται σε έναν πίνακα όπου κάθε στήλη θα αντιστοιχεί στον τίτλο της υπενθύμισης, στην περιγραφή της, στις ετικέτες, στην ημερομηνία και στην ώρα. Αυτό θα γίνεται για όλες τις υπενθυμίσεις που υπάρχουν, γι’ αυτό χρησιμοποιείται η for-each. Τέλος, έχει προστεθεί ένας μετρητής count(/calendar/reminder) ο οποίος μετράει πόσες φορές θα εμφανιστεί το element reminder στο XML, δηλαδή, όσες υπενθυμίσεις θα υπάρχουν κιόλας. ( Ερώτηση 3.) Πατώντας το κουμπί «XML», εμφανίζεται η παρακάτω εικόνα (Εικόνα 2) σε νέο παράθυρο:

    Εικόνα 2. Εμφάνιση υπενθυμίσεων με XML

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    6

    Για να εμφανιστούν οι υπενθυμίσεις κατά αντίστροφη χρονολογική σειρά, στο αρχείο xml_reminder.php όπου γίνεται το query για να πάρουμε τις υπενθυμίσεις, γίνεται order by date DESC.

    $query = "SELECT * FROM reminder as a LEFT JOIN reminder_tag as b ON a.id_rem=b.id_rem LEFT JOIN tag as c ON c.id_tag=b.id_tag ORDER BY date DESC";

    (c) Ερώτηση 3.

    Για την εμφάνιση του XML, χρειάστηκε να δημιουργηθεί ένα αρχείο xml_reminder.php στο οποίο έχουμε δηλώσει τη μορφή του DTD για το XML αρχείο. Η υλοποίηση ελέγχου επικύρωσης της δομής του αρχείου που εμφανίζεται, σύμφωνα με το DTD που έχουμε ορίσει στην Ερώτηση 1, γίνεται με τον παρακάτω κώδικα:

    $doc = new DOMDocument(); $xsl = new XSLTProcessor(); $doc->load($xsl_filename); $xsl->importStyleSheet($doc); $doc->loadXML($create_xml); if(!$doc->validate()){ echo "

    Το αρχείο δεν είναι έγκυρο σύμφωνα με το DTD

    "; } else { $calendar = $doc->getElementsByTagName('reminder'); //Το $calendar είναι ένα DOMNodeList echo $xsl->transformToXML($doc);

    Δημιουργούμε ένα νέο αντικείμενο της κλάσης Dom Document ($doc = new DOMDocument();) και κάνουμε validate ((!$doc ->validate()). Αν δεν είναι σωστό, τότε εμφανίζεται μήνυμα λάθους στο χρήστη για τη μορφή του DTD. Επίσης, στον κώδικα χρησιμοποιούμε τη συνάρτηση getElementsByTagName η οποία επιστρέφει μια λίστα των στοιχείων “reminder” που υπάρχουν στο αρχείο που δημιουργήθηκε.

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    7

    Άσκηση 2

    Απόδοση του πρωτοκόλλου HTTP και Caching

    Εισαγωγή Σκοπός της παρούσας άσκησης, είναι η μέτρηση της απόδοσης του πρωτοκόλλου HTTP αλλά και των διαδικασιών caching που πραγματοποιούν οι browsers που χρησιμοποιούμε καθημερινά.

    Ερώτηση 1 Για την εκτέλεση της Ερώτησης 1 θα πρέπει να χρησιμοποιήσετε το εργαλείο Wireshark, το οποίο είναι δωρεάν διαθέσιμο στο http://www.wireshark.org/download.html για λειτουργικά συστήματα Windows/Linux/Mac. To Wireshark είναι ένα εργαλείο το οποίο “συλλαμβάνει” και εμφανίζει την κίνηση του δικτύου στον υπολογιστή σας. Για τη χρήση του εργαλείου Wireshark θα πρέπει να επιλέξετε την κατάλληλη διεπαφή που χρησιμοποιείται για την πρόσβασή σας από τη διαθέσιμη λίστα του εργαλείου, όπως εμφανίζεται στην παρακάτω εικόνα:

    Επίσης, για τους σκοπούς της παρούσας ερώτησης, στο πεδίο του φίλτρου “σύλληψης” το οποίο εμφανίζεται στην παρακάτω εικόνα

    θα πρέπει να συμπληρώσετε την IP διεύθυνση του διακομιστή που σας ζητείται στα παρακάτω ερωτήματα στο πεδίο ip.addr, καθώς και το όρισμα http (ακριβώς όπως παρουσιάζεται στην εικόνα παραπάνω), ώστε το Wireshark να καταγράφει μόνο κίνηση που αφορά το διακομιστή της άσκησης καθώς και το πρωτόκολλο HTTP.

    1. Εκκινήστε το εργαλείο Wireshark, εκκινήστε τη “σύλληψη” κίνησης στη διεπαφή (interface) του δικτύου σας και ρυθμίστε το φίλτρο να εμφανίζει μόνο την HTTP κίνηση από και προς το διακομιστή με διεύθυνση 62.217.125.90 (όπως περιγράφηκε παραπάνω). Επισκεφθείτε για πρώτη φορά από το φυλλομετρητή σας τη σελίδα images.html στον παραπάνω διακομιστή (http://62.217.125.90/images.html) και παρατηρήστε την κίνηση που καταγράφει το Wireshark. Στη συνέχεια προσπελάστε ξανά τον παραπάνω διακομιστή εκτελώντας ανανέωση (refresh) στο φυλλομετρητή σας και παρατηρήστε ξανά την καταγραφή του Wireshark. Καταγράψτε τις διαφορές που παρατηρείτε μεταξύ των δύο αιτημάτων που εκτελέσατε. Παραθέστε χαρακτηριστικά screenshots από το Wireshark και εξηγείστε που οφείλονται οι διαφορές που παρατηρείτε.

    http://www.wireshark.org/download.htmlhttp://62.217.125.90/images.html

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    8

    2. Καταγράψτε και συγκρίνετε τους χρόνους ολοκλήρωσης των δύο παραπάνω αιτημάτων του υποερωτήματος 1. Εξηγήστε που οφείλεται η διαφορά στους δύο παραπάνω χρόνους που καταγράψατε.

    3. Καταγράψτε αναλυτικά τα πεδία των HTTP αιτημάτων GET (παραθέστε το αντίστοιχο screenshot) που αποστέλλει ο φυλλομετρητής σας στο διακομιστή κατά τη δεύτερη προσπέλαση (ανανέωση) της σελίδας και εξηγήστε τι περιγράφει το κάθε πεδίο. Επίσης, αναφέρετε τις επιλογές που μπορεί γενικά να θέσει ο client στο πεδίο Cache-Control.

    ΠΡΟΣΟΧΗ: Για την εκτέλεση της Ερώτησης 1, θα πρέπει να βεβαιωθείτε πως η λειτουργία του caching στο φυλλομετρητή σας δεν είναι απενεργοποιημένη.

    Ερώτηση 2 Καταγράψτε τις βασικές διαφορές και περιγράψτε τις βελτιώσεις που σχετίζονται με τη διαχείριση του caching μεταξύ της έκδοσης 1.0 και της έκδοσης 1.1 του πρωτοκόλλου HTTP.

    Ερώτηση 3 Έστω ένας χρήστης του διαδικτύου ζητάει καθημερινά μία σελίδα η οποία βρίσκεται σε έναν απομακρυσμένο web server που είναι πάντα διαθέσιμος. Caching της συγκεκριμένης σελίδας γίνεται ιεραρχικά: στο φυλλομετρητή του χρήστη (browser cache), στην cache που προσφέρει ο ISP (proxy cache) και τέλος σε μία cache που προσφέρει ο διαχειριστής της σελίδας (reverse proxy cache).

    Στις τελευταίες 50 φορές που προσπέλασε ο χρήστης τη σελίδα, κατέγραψε τα εξής: 7 φορές περίμενε περίπου 0,4 sec για να «κατεβεί» η σελίδα, 13 φορές περίμενε περίπου 1,6 sec, 25 φορές περίπου 2,4 sec και τις υπόλοιπες φορές χρόνο μεγαλύτερο των 6 sec.

    Ζητούνται τα παρακάτω:

    Υπολογίστε την πιθανότητα η σελίδα να βρίσκεται: (i) στη browser cache του χρήστη, (ii) στην proxy cache του ISP, (iii) στη reverse proxy cache που χρησιμοποιεί η σελίδα.

    Πως μεταβάλλονται οι παραπάνω πιθανότητες σε περίπτωση που ο διαχειριστής της σελίδας καταργήσει το reverse proxy caching που προσφέρει;

    Υπολογίστε το ελάχιστο bandwidth (δηλαδή το bottleneck) της σύνδεσης από το PC του χρήστη έως την cache του ISP (proxy cache).

    Δίνεται ότι το πλήθος των μεταβάσεων με επιστροφή που χρειάζονται για να «κατεβεί» η σελίδα είναι Ν = 25, ενώ το RTT από το PC του χρήστη έως την cache του ISP έχει μετρηθεί 20 msec και το μέγεθος της σελίδας είναι 812 kB.

    Στόχος: Βασικός στόχος της συγκεκριμένης άσκησης είναι η μέτρηση της απόδοσης του πρωτοκόλλου Internet HTTP, η κατανόηση της διαδικασίας caching, αλλά και η κατανόηση στοιχείων που έχουν να κάνουν με διάφορους τρόπους αποθήκευσης δεδομένων από τους φυλλομετρητές. Απαραίτητες γνώσεις: Για την καλύτερη κατανόηση των εννοιών, είναι χρήσιμη η μελέτη των Κεφαλαίων 5 και 6 του Τόμου Β’ και η αξιοποίηση των σχετικών Παράλληλων Κειμένων και των Χρήσιμων Δικτυακών Τόπων από τη σελίδα της Θ.Ε.

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    9

    ΑΠΑΝΤΗΣΕΙΣ ΑΣΚΗΣΗΣ 2

    Ερώτηση 1

    (a) Κατά την πρώτη προσπέλαση της σελίδας images.html, το εργαλείο Wireshark καταγράφει την παρακάτω κίνηση:

    Κατά την επόμενη προσπέλαση (refresh) της συγκεκριμένης σελίδας (με την προϋπόθεση πως το caching του φυλλομετρητή είναι ενεργοποιημένο), το Wireshark καταγράφει την παρακάτω κίνηση:

    Όπως μπορούμε να παρατηρήσουμε από τα δύο παραπάνω στιγμιότυπα (πριν και μετά την ανανέωση στο φυλλομετρητή), οι διαφορές αφορούν το αποτέλεσμα των αιτημάτων GET που αποστέλλονται στο διακομιστή.

    Συγκεκριμένα, ενώ κατά την πρώτη προσπέλαση τo status code των αιτημάτων GET είναι 200 OK, που σημαίνει πως το περιεχόμενο του αιτήματος GET ολοκληρώθηκε με επιτυχία (δλδ. έγινε

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    10

    λήψη του περιεχομένου της σελίδας που ζητήθηκε), κατά τη δεύτερη προσπέλαση (ανανέωση) το αποτέλεσμα των ίδιων αιτημάτων GET είναι το status code 304 Not Modified, που σημαίνει πως το περιεχόμενο του αιτήματος GET δεν έχει τροποποιηθεί από την τελευταία του προσπέλαση.

    Προφανώς, με την προϋπόθεση πως η cache του φυλλομετρητή είναι ενεργή, κατά τη δεύτερη προσπέλαση της ίδιας σελίδας, βρέθηκε ένα έγκυρο περιεχόμενο αυτής στην cache, με αποτέλεσμα ο διακομιστής να αποκρίνεται με το HTTP response 304 Not Modified.

    (b) Όπως μπορούμε να παρατηρήσουμε από την καταγραφή του Wireshark, για το (a) ερώτημα κατά την πρώτη προσπέλαση της σελίδας, απαιτήθηκε χρόνος περίπου ίσος με 17,41 sec (18.75 sec - 1.34 sec) για την ολοκλήρωση του αιτήματος, ενώ για την ολοκλήρωση της δεύτερης προσπέλασης (ανανέωση) απαιτήθηκε χρόνος περίπου ίσος με 0.2 sec (516,07 sec - 515,88 sec).

    Η μεγάλη αυτή διαφορά στους χρόνους ολοκλήρωσης του ίδιου αιτήματος είναι απόρροια της λειτουργίας caching, όπως περιγράφηκε στο ερώτημα (a). Πιο συγκεκριμένα, κατά τη δεύτερη προσπέλαση της σελίδας, εφόσον το περιεχόμενο της σελίδας είχε ήδη ανακτηθεί κατά την αρχική προσπέλασή της και η τοπική έκδοσή της ήταν ανανεωμένη, πραγματοποιήθηκε μόνο η μεταφορά των HTTP requests και responses που κατέγραψε το Wireshark στο ερώτημα (a) και όχι η ανάκτηση του περιεχομένου της σελίδας από το διακομιστή της. Δεδομένου λοιπόν, του περιεχομένου της σελίδας (περιέχει μία εικόνα υψηλής ανάλυσης), η μεγάλη διαφορά στους δύο χρόνους ολοκλήρωσης είναι αναμενόμενη.

    (c) Τα πεδία του HTTP αιτήματος GET, όπως καταγράφονται από το Wireshark, κατά τη δεύτερη προσπέλαση της σελίδας, είναι τα παρακάτω:

    Host

    User-Agent

    Accept

    Accept-Language

    Accept-Encoding

    Connection

    If-Modified-Since

    If-None-Match

    Cache-Control

    όπως αυτά παρουσιάζονται και στο παρακάτω screenshot από το Wireshark.

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    11

    Αναλυτικά, το πεδίο Host προσδιορίζει τη διεύθυνση και τη θύρα του διακομιστή όπου βρίσκεται το περιεχόμενο που ζητείτε στο αίτημα, όπως αυτά προκύπτουν από το αρχικό URI που όρισε ο χρήστης. Το πεδίο User-Agent περιέχει πληροφορίες, κυρίως για στατιστικούς σκοπούς, σχετικά με την εφαρμογή του χρήστη από την οποία πραγματοποιήθηκε το αίτημα. Το πεδίο Accept χρησιμοποιείται για να καθοριστούν συγκεκριμένοι τύποι δεδομένων που είναι αποδεκτοί για το συγκεκριμένο αίτημα. Ομοίως με το πεδίο Accept, το πεδίο Accept-Language χρησιμοποιείται για να περιοριστεί το σύνολο των γλωσσών της απόκρισης του αιτήματος και το πεδίο Accept-Encoding για να περιορίσει τις κωδικοποιήσεις του περιεχομένου της απόκρισης. Το πεδίο Connection επιτρέπει στον αποστολέα να ορίσει διάφορες επιλογές για τη σύνδεση που αφορά το συγκεκριμένο αίτημα. Το πεδίο If-Modified-Since καθορίζει πως εάν η έκδοση του περιεχομένου του αιτήματος δεν έχει τροποποιηθεί από τη χρονική στιγμή που καθορίζει το συγκεκριμένο πεδίο, δεν θα πρέπει να ανακτηθεί το περιεχόμενο από το διακομιστή αλλά αντ' αυτού θα επιστραφεί το response με status code 304 Not Modified. Γενικά, σκοπός του συγκεκριμένου πεδίου είναι η αποδοτική διαχείριση της λειτουργίας του caching. Επιπλέον, το πεδίο If-None-Match έχει κι αυτό σκοπό την αποδοτική διαχείριση του caching, καθώς μπορεί να περιέχει μία λίστα με αναγνωριστικά cached εκδόσεων, ώστε να εξακριβωθεί εάν κάποια από αυτές τις εκδόσεις είναι ίδια με την τρέχουσα έκδοση του περιεχομένου που ζητείται.

    Το πεδίο Cache-Control χρησιμοποιείται για να καθορίσει τις οδηγίες που πρέπει να τηρούνται από όλους τους μηχανισμούς caching που υπάρχουν στο “μονοπάτι” του αιτήματος/απόκρισης.

    Οι οδηγίες που μπορεί να τεθούν στο πεδίο Cache-Control στη συγκεκριμένη περίπτωση και δεδομένου πως χρησιμοποιείται η έκδοση 1.1 του HTTP πρωτοκόλλου, είναι οι παρακάτω:

    no-cache

    no-store

    max-age

    max-stale

    min-fresh

    no-transform

    only-if-cached

    και τέλος με χρήση της δυνατότητας cache-extension

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    12

    ΠΑΡΑΤΗΡΗΣΗ: Σημειώνεται πως η αλλαγή του διακομιστή που φιλοξενούσε τη σελίδα, δεν επηρεάζει την έκβαση της άσκησης, καθώς οι μόνες διαφορές παρατηρούνται στη διεύθυνση του διακομιστή της σελίδας και στο περιεχόμενο αυτής (ονομασία αρχείων εικόνας) και οι χρόνοι που θα καταγραφούν εξαρτώνται από τη σύνδεση του κάθε χρήστη.

    Ερώτηση 2

    Το HTTP/1.0 παρέχει έναν απλοϊκό μηχανισμό διαχείρισης του caching. Συγκεκριμένα, ένας διακομιστής μπορεί απλώς να “μαρκάρει” μία απόκριση, με χρήση του πεδίου Expires, με μία χρονική στιγμή έως την οποία μία cache μπορεί να ικανοποιήσει το εκάστοτε αίτημα “διαφανώς”. Επίσης, μία cache μπορεί να ελέγξει την ισχύ μίας απόκρισης κάνοντας χρήση ενός αιτήματος “υπό όρους” (conditional request), δίνοντας τη δυνατότητα στο διακομιστή να αποκριθεί είτε με το status code 304 Not Modified (ορίζοντας πως η έκδοση της cache είναι έγκυρη), είτε με το σύνηθες status code 200 OK (αντικαθιστώντας την έκδοση της cache). Επίσης το HTTP/1.0 παρέχει ένα μηχανισμό, μέσω του πεδίου Pragma: no-cache, όπου μπορούσε να οριστεί σαφώς πως το αίτημα δεν πρέπει να εξυπηρετηθεί από cache. Προφανώς, η έκδοση 1.0 του HTTP προσφέρει πολύ φτωχές δυνατότητες διαχείρισης του caching, ένα κενό που προσπαθεί να συμπληρώσει η έκδοση 1.1.

    Το HTTP/1.1 προσπαθεί να παρέχει ρητές και επεκτάσιμες λειτουργίες στη διαχείριση του caching. Ενώ διατηρεί το βασικό σχεδιασμό του HTTP/1.0, τον ενισχύει τόσο με νέα χαρακτηριστικά αλλά και με πιο ρητές προδιαγραφές των υπαρχουσών λειτουργιών.

    Σύμφωνα με το HTTP/1.1 η έκδοση της cache είναι “έγκυρη” μέχρι το χρόνο λήξης της. Μετά τη λήξη της, η cache δεν είναι απαραίτητο να απορρίψει την παλιά πλέον έκδοση, αλλά συνήθως πρέπει να την επαναεπικυρώσει από το διακομιστή πριν αποκριθεί με αυτήν την έκδοση σε ένα αίτημα. Ωστόσο, η έκδοση 1.1 επιτρέπει τόσο στους διακομιστές όσο και στους clients να παρακάμψουν αυτόν τον κανόνα.

    Στο HTTP/1.0, η cache επαναεπικυρώνεται χρησιμοποιώντας το πεδίο If-Modified-Since. Αυτό το πεδίο χρησιμοποιεί timestamps με ευαισθησία δευτερολέπτου, γεγονός που μπορεί να οδηγήσει σε εσφαλμένο caching είτε λόγω σφαλμάτων συγχρονισμού, είτε λόγω έλλειψης μεγαλύτερης ακρίβειας. Το HTTP/1.1 εισάγει τη γενική έννοια της “αδιαφανούς” επικύρωσης της cache, με χρήση της entity tag. Δηλαδή, εάν δύο αποκρίσεις για την ίδια οντότητα έχουν την ίδια entity tag, τότε θα πρέπει εξ ορισμού να είναι και ίδιες. Επειδή ακριβώς λοιπόν η entity tag είναι “αδιαφανής”, ο διακομιστής μπορεί να χρησιμοποιήσει όποια πληροφορία κρίνει αναγκαία (π.χ. ένα timestamp) για να τη δημιουργήσει, εφ 'όσον πληρείται η μοναδικότητα αυτής. Οι clients μπορούν να συγκρίνουν τις entity tags για ομοιότητα, αλλά δεν μπορούν να τις χειριστούν για άλλο σκοπό. Να σημειώσουμε πως HTTP/1.1 διακομιστές εισάγουν τις entity tags στις αποκρίσεις τους με χρήση του πεδίου Etag.

    Επίσης, το HTTP/1.1 εισάγει ένα πλήθος από νέα υπό συνθήκη αιτήματα (conditional requests), εκτός από τo If-Modified-Since του HTTP/1.0. Το πιο βασικό είναι το If-None-Match, το οποίο επιτρέπει σε έναν client να χρησιμοποιήσει μία ή περισσότερες entity tags από τις καταχωρήσεις της cache του για μία συγκεκριμένη οντότητα. Το HTTP/1.1 έχει και νέες προϋποθέσεις, χρήσιμες σε πιο σύνθετες περιπτώσεις με τα conditional headers If-Unmodified-Since και If-Match.

    Τέλος, για να γίνουν οι προδιαγραφές του caching πιο ρητές, το HTTP/1.1 εισάγει το νέο πεδίο

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    13

    Cache-Control, επιτρέποντας την επιλογή από ένα εκτενές σύνολο ρητών οδηγιών, τόσο για τα αιτήματα, όσο και για τις αποκρίσεις. Το σύνολο των οδηγιών αυτών είναι αρκετά μεγάλο, δίνοντας τη δυνατότητα να αντιμετωπιστούν επιτυχώς τα θέματα συγχρονισμού, εξασφάλισης της ιδιωτικότητας, καθώς και της αποδοτικής διαχείρισης της χωρητικότητας των συνδέσμων που χρησιμοποιούνται για την ανταλλαγή δεδομένων, θέματα που αδυνατούσε να διαχειριστεί το HTTP στην έκδοση 1.0.

    Ερώτηση 3

    (a) Ζητούνται τα hbc, hpc και hrc που είναι οι πιθανότητες να βρίσκεται η σελίδα στην cache του φυλλομετρητή, στην proxy cache του ISP και στη reverse proxy cache της σελίδας αντίστοιχα.

    Μας δίνονται κατάλληλα δεδομένα από τα οποία μπορούμε να υπολογίσουμε εύκολα τα Pbc, Ppc και Prc, δηλαδή τις πιθανότητες επιτυχούς ανεύρεσης της σελίδας στην cache του φυλλομετρητή, στην proxy cache του ISP και στη reverse proxy cache σύμφωνα με το ιεραρχικό σύστημα caching της εκφώνησης.

    Από τους χρόνους που δίνονται, μπορούμε να συμπεράνουμε πως υπάρχουν τέσσερις (4) περιπτώσεις επιτυχούς ανεύρεσης της σελίδας, με χρόνους απόκρισης από 0.4 sec (7 φορές στις 50), 1.6 sec (13 φορές στις 50), 2.4 sec (25 φορές στις 50) και μεγαλύτερο των 6 sec (τις υπόλοιπες 5 φορές από τις 50), που αντιστοιχούν στην ανάκτηση της σελίδας από την browser cache, την proxy cache, τη reverse proxy cache και τέλος τον web server της σελίδας αντίστοιχα, αφού αναμένεται οι χρόνοι απόκρισης να είναι μεγαλύτεροι όσο πιο απομακρυσμένο είναι το “σημείο” ανάκτησης της σελίδας.

    Συνεπώς:

    Pbc = 7 / 50 = 0.14

    Ppc = 13 / 50 = 0.26

    Prc = 25 / 50 = 0.5

    Pserver = 5 / 50 = 0.1

    Από τους τύπους που συνδέουν τα P με τα h στο ιεραρχικό σύστημα caching, έχουμε:

    hbc = Pbc = 0.14

    Ppc = hpc (1 - Pbc)

    0.26 = hpc (1 – 0.14)

    Άρα: hpc = 0.3023

    Prc = hrc (1 – Ppc - Pbc) ή 0.5 = hrc (1 – 0.26 – 0.14)

    Άρα: hrc = 0.8333

    Pserver = hserver (1 – Prc - Ppc - Pbc)

    0.1 = hserver (1 – 0.5 - 0.26 – 0.14)

    Άρα προφανώς (σαν επαλήθευση): hserver = 1

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    14

    Συνεπώς, οι ζητούμενες πιθανότητες είναι:

    hbc = 0.14 για την browser cache,

    hpc = 0.3023 για την proxy cache και

    hrc = 0.8333 για τη reverse proxy cache.

    (b) Στην περίπτωση που η reverse proxy cache καταργηθεί, οι πιθανότητες επιτυχούς ανεύρεσης της σελίδας μεταβάλλονται ως εξής:

    Pbc = 7 / 50 = 0.14

    Ppc = 13 / 50 = 0.26

    Prc = 0 / 50 = 0

    Pserver = 30 / 50 = 0.6

    καθώς είναι προφανές πως εάν σε κάποιο επίπεδο δεν πραγματοποιείται caching οι πιθανότητες επιτυχούς ανεύρεσης της σελίδας μεταφέρονται στα υψηλότερα επίπεδα της ιεραρχίας.

    Αντίστοιχα με το ερώτημα (a) έχουμε από τις νέες πιθανότητες επιτυχούς ανεύρεσης:

    hbc = Pbc = 0.14

    Ppc = hpc (1 - Pbc)

    0.26 = hpc (1 – 0.14)

    Άρα: hpc = 0.3023

    Prc = hrc (1 – Ppc - Pbc)

    0 = hrc (1 – 0.26 – 0.14)

    Άρα: hrc = 0

    Pserver = hserver (1 – Prc - Ppc - Pbc)

    0.6 = hserver (1 – 0 - 0.26 – 0.14)

    Άρα: hserver = 1

    Συνεπώς, τώρα οι ζητούμενες πιθανότητες γίνονται:

    hbc = 0.14 για την browser cache,

    hpc = 0.3023 για την proxy cache και

    hrc = 0 για τη reverse proxy cache.

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    15

    (c) Ισχύει από τη σχέση (5.1) του Τόμου Β:

    όπου: Tr: είναι ο χρόνος απόκρισης και στην περίπτωσή μας ισούται με 1.6 sec για την απόκριση από

    την proxy cache του ISP [δίνεται] S: είναι το συνολικό μέγεθος της σελίδας: 812 kB [δίνεται] N: είναι το πλήθος μεταβάσεων με επιστροφή: 25 [δίνεται] RTT: είναι ο χρόνος μετάβασης με επιστροφή από το PC ως την proxy cache του ISP: 20 msec

    [δίνεται] PC + PS: είναι ο συνολικός χρόνος επεξεργασίας: 0.4 sec όπως συνάγεται από το γεγονός ότι είναι

    ο συνολικός χρόνος “κατεβάσματος” της σελίδας από το PC [δίνεται]

    Cmin: είναι η μικρότερη χωρητικότητα συνδέσμου, η οποία είναι το ζητούμενο του ερωτήματος. Αντικαθιστώντας στη σχέση (1) έχουμε:

    Επομένως, το ελάχιστο bandwidth (bottleneck) της σύνδεσης από το PC ως την proxy cache του ISP, είναι 9502.72 kbps ή περίπου 9.5 Mbps.

  • ΕΛΛΗΝΙΚΟ ΑΝΟΙΚΤΟ ΠΑΝΕΠΙΣΤΗΜΙΟ

    16

    Κριτήρια αξιολόγησης

    Άσκηση 1 (Σύνολο) 70

    Ερώτηση 1 15

    Ερώτηση 2 30

    Ερώτηση 3 25

    Άσκηση 2 (Σύνολο) 30

    Ερώτηση 1 10

    Ερώτηση 2 5

    Ερώτηση 3 15

    Σύνολο 100

    Ο συνολικός βαθμός θα διαιρεθεί δια 10, ώστε να προκύψει ο τελικός βαθμός της εργασίας.