Report: Added intro and DSL
This commit is contained in:
@@ -282,7 +282,6 @@ The generated Python is the only executable Mininet backend.
|
||||
a raw dictionary.
|
||||
`topology_parser.py` provides `parse_topology(raw)`, which converts that dictionary
|
||||
into a typed `Topology`.
|
||||
The loader's convenience API, `load(path)`, performs both operations.
|
||||
Neither stage depends on Mininet.
|
||||
|
||||
The semantic model uses dataclasses for `Topology`, `Node`, `Interface`, `Link`,
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
# LaTeX auxiliary files
|
||||
*.aux
|
||||
*.log
|
||||
*.out
|
||||
*.synctex.gz
|
||||
_minted*/*
|
||||
|
||||
|
||||
Binary file not shown.
@@ -0,0 +1,324 @@
|
||||
% !TEX TS-program = xelatex
|
||||
% !TEX encoding = UTF-8 Unicode
|
||||
% !TEX spellcheck = el-GR
|
||||
%
|
||||
% Compiter Networks II report
|
||||
%
|
||||
% Requires compilation with pdfLaTeX or XeLaTeX
|
||||
%
|
||||
% authors:
|
||||
% Χρήστος Χουτουρίδης ΑΕΜ 8997
|
||||
% cchoutou@ece.auth.gr
|
||||
|
||||
%
|
||||
% Options:
|
||||
%
|
||||
% 1) mainlang=<language>
|
||||
% Default: english
|
||||
% Set the default language of the document which affects hyphenations,
|
||||
% localization (section, dates, etc...)
|
||||
%
|
||||
% example: \documentclass[mainlang=greek]{AUThReport}
|
||||
%
|
||||
% 2) <language>
|
||||
% Add hyphenation and typesetting support for other languages
|
||||
% Currently supports: english, greek, german, frenc
|
||||
%
|
||||
% example: \documentclass[english, greek]{AUThReport}
|
||||
%
|
||||
% 3) short: Requests a shorter title for the document
|
||||
% Default: no short
|
||||
%
|
||||
% example: \documentclass[short]{AUThReport}
|
||||
%
|
||||
\documentclass[a4paper, 11pt, mainlang=greek, english]{AUThReport/AUThReport}
|
||||
|
||||
\CurrentDate{\today}
|
||||
|
||||
% Document setup
|
||||
%---------------------------------
|
||||
|
||||
% \WorkGroup{Ομάδα Χ}
|
||||
|
||||
\AuthorName{Χρήστος Χουτουρίδης}
|
||||
\AuthorMail{cchoutou@ece.auth.gr}
|
||||
\AuthorAEM{8997}
|
||||
|
||||
%\CoAuthorName{Όνομα Επίθετο}
|
||||
%\CoAuthorAEM{AEM}
|
||||
%\CoAuthorMail{xxx@ece.auth.gr}
|
||||
|
||||
\DocTitle{Αυτοματοποιημένη Ανάπτυξη Τοπολογίας και Ανάλυση Πρωτοκόλλων στο Mininet}
|
||||
%\DocSubTitle{Ανάλυση και υλοποίηση του αλγόριθμου bitonic sort για υποσύστημα γραφικών με χρήση CUDA}
|
||||
|
||||
\Department{Τμήμα ΗΜΜΥ. Τομέας Ηλεκτρονικής}
|
||||
\ClassName{Δίκτυα Υπολογιστών ΙΙ}
|
||||
%
|
||||
\InstructorName{Αναστάσιος Ντελόπουλος}
|
||||
\InstructorMail{antelopo@ece.auth.gr}
|
||||
|
||||
\CoInstructorName{Εμανουήλ Τσαρδουλιάς}
|
||||
\CoInstructorMail{etsardou@ece.auth.gr}
|
||||
|
||||
|
||||
% Local package requirements
|
||||
%---------------------------------
|
||||
|
||||
\usepackage{enumitem}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{array}
|
||||
\usepackage{multirow}
|
||||
\usepackage{float}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{soul}
|
||||
\usepackage{amsmath}
|
||||
\usepackage{footnote}
|
||||
\usepackage{footmisc}
|
||||
|
||||
|
||||
%\definecolor{red-highlight}{rgb}{1.0, 0.11, 0.0}
|
||||
\definecolor{red-highlight}{rgb}{1.0, 0.31, 0.0}
|
||||
\definecolor{green-highlight}{rgb}{0.0, 0.62, 0.42}
|
||||
|
||||
\newcommand{\bxrd}[1]{\colorbox{red-highlight}{#1}}
|
||||
\newcommand{\bxgr}[1]{\colorbox{green-highlight}{#1}}
|
||||
|
||||
\newcommand{\trd}[1]{\textcolor{red-highlight}{\textbf{#1}}}
|
||||
\newcommand{\tgr}[1]{\textcolor{green-highlight}{\textbf{#1}}}
|
||||
|
||||
% “virtual” cites
|
||||
% ----------------------------------------
|
||||
%\newcommand{\citeKnuthACM}{%
|
||||
% Donald E. Knuth, \emph{Structured Programming with go to Statements}, ACM Computing Surveys, vol. 6, no. 4, 1974
|
||||
%}
|
||||
|
||||
% Links
|
||||
% Repository links
|
||||
% ----------------------------------------
|
||||
\newcommand{\repoGithub}{https://github.com/hoo2/Computer-Networks-II}
|
||||
\newcommand{\repoGitea}{https://git.hoo2.net/hoo2/Computer-Networks-II}
|
||||
|
||||
\newcommand{\topologyJsonUrl}{\repoGithub/blob/HEAD/exercise/topology.json}
|
||||
\newcommand{\buildNetworkUrl}{\repoGithub/blob/HEAD/source/build_network.py}
|
||||
\newcommand{\resultsUrl}{\repoGithub/tree/HEAD/exercise/results}
|
||||
|
||||
\newcommand{\dslDesignUrl}{\repoGithub/blob/HEAD/Mininet_DSL_Design.md}
|
||||
|
||||
\begin{document}
|
||||
|
||||
\InsertTitle
|
||||
|
||||
%\tableofcontents
|
||||
|
||||
|
||||
\section{Εισαγωγή}
|
||||
|
||||
Η παρούσα εργασία έχει ως αντικείμενο την \textbf{αυτοματοποιημένη ανάπτυξη δικτυακών τοπολογιών στο περιβάλλον Mininet},
|
||||
με βάση μια δηλωτική περιγραφή σε αρχείο JSON.
|
||||
Στο πλαίσιο αυτό υλοποιείται εφαρμογή σε Python, η οποία διαβάζει περιγραφές της τοπολογίας σε μια πρότυπη \textbf{Domain-Specific
|
||||
Language -- DSL}, και δημιουργεί δυναμικά τους αντίστοιχους hosts, μεταγωγείς, συνδέσμους και δρομολογητές και εφαρμόζει
|
||||
τις απαιτούμενες ρυθμίσεις δικτύου.
|
||||
Το Mininet χρησιμοποιείται ως περιβάλλον εξομοίωσης, ώστε η τοπολογία να μπορεί να κατασκευάζεται και να εξετάζεται
|
||||
με χρήση των ίδιων εργαλείων και πρωτοκόλλων που χρησιμοποιούνται σε ένα πραγματικό σύστημα Linux.
|
||||
|
||||
Μετά την ανάπτυξη της τοπολογίας πραγματοποιούνται τρία πειράματα χαμηλού επιπέδου για τη μελέτη των πρωτοκόλλων
|
||||
\textbf{DHCP} και \textbf{ARP}, καθώς και της \textbf{δρομολόγησης μεταξύ διαφορετικών υποδικτύων}.
|
||||
Μέσω καταγραφών με το \texttt{tcpdump} εξετάζεται η διαδικασία D.O.R.A. του DHCP, η αντιστοίχιση διευθύνσεων IP σε
|
||||
διευθύνσεις MAC μέσω του ARP και η μεταβολή των Ethernet διευθύνσεων και του TTL κατά τη διέλευση ενός IP πακέτου
|
||||
από τον δρομολογητή.
|
||||
Στόχος των πειραμάτων είναι η σύνδεση της θεωρητικής λειτουργίας των πρωτοκόλλων με την πραγματική μορφή των
|
||||
πακέτων που ανταλλάσσονται στα διαφορετικά επίπεδα του δικτύου.
|
||||
|
||||
|
||||
\subsection{Παραδοτέα}
|
||||
|
||||
Τα παραδοτέα της εργασίας αποτελούνται από:
|
||||
\begin{itemize}
|
||||
\item Την παρούσα τεχνική αναφορά.
|
||||
\item Το αρχείο \href{\topologyJsonUrl}{\texttt{exercise/topology.json}}, το οποίο περιγράφει δηλωτικά την τοπολογία δικτύου που χρησιμοποιείται στην εργασία.
|
||||
\item Τον κατάλογο \texttt{source/}, ο οποίος περιέχει το αρχείο \href{\buildNetworkUrl}{\texttt{build\_network.py}}, καθώς και τα υπόλοιπα αρχεία
|
||||
Python που υλοποιούν την εφαρμογή.
|
||||
\item Τον κατάλογο \href{\resultsUrl}{\texttt{exercise/results/}}, ο οποίος περιέχει τις μετρήσεις και τα παραγόμενα αρχεία των πειραμάτων της εργασίας.
|
||||
\item Τους συνδέσμους προς τα αποθετήρια στο \href{\repoGithub}{GitHub} και στον \href{\repoGitea}{προσωπικό μου server}, τα οποία περιέχουν τον πηγαίο κώδικα,
|
||||
τον κώδικα παραγωγής της αναφοράς και τα αποτελέσματα των πειραμάτων.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Υλοποίηση του Builder}
|
||||
|
||||
\subsection{Δηλωτική γλώσσα περιγραφής τοπολογίας}
|
||||
|
||||
Για την περιγραφή των δικτυακών τοπολογιών σχεδιάστηκε μία μικρή \textbf{δηλωτική γλώσσα ειδικού σκοπού}
|
||||
(Domain-Specific Language -- DSL), η οποία χρησιμοποιεί το JSON ως μορφή αναπαράστασης.
|
||||
Στόχος της γλώσσας είναι να περιγράφει την \emph{επιθυμητή κατάσταση του δικτύου} και όχι τη σειρά των εντολών
|
||||
που απαιτούνται για την κατασκευή του στο Mininet.
|
||||
Με αυτόν τον τρόπο η περιγραφή της τοπολογίας παραμένει ανεξάρτητη από λεπτομέρειες της υλοποίησης, όπως τα
|
||||
ονόματα των εικονικών διεπαφών ή η ακριβής ακολουθία κλήσεων προς το Mininet API.
|
||||
Η αναλυτική σχεδίαση και η γραμματική της γλώσσας τεκμηριώνονται επίσης στο αρχείο
|
||||
\href{\dslDesignUrl}{\texttt{Mininet\_DSL\_Design.md}} του αποθετηρίου.
|
||||
|
||||
\subsubsection{Σχεδιαστική προσέγγιση}
|
||||
|
||||
Ο σχεδιασμός της γλώσσας πραγματοποιήθηκε \textbf{από πάνω προς τα κάτω}, ξεκινώντας από τις έννοιες που είναι
|
||||
φυσικό να χρησιμοποιούνται για την περιγραφή ενός δικτύου, όπως οι \emph{κόμβοι}, οι \emph{διεπαφές}, οι \emph{σύνδεσμοι} και οι
|
||||
\emph{υπηρεσίες}.
|
||||
Παράλληλα, κάθε αφηρημένη έννοια επιλέχθηκε έχοντας υπόψη τις διαθέσιμες πρωτογενείς λειτουργίες του Mininet και
|
||||
του δικτυακού υποσυστήματος του Linux.
|
||||
Η προσέγγιση αυτή επιτρέπει στη γλώσσα να παραμένει υψηλού επιπέδου, χωρίς να εισάγει κατασκευές που δεν μπορούν
|
||||
να μεταφραστούν με σαφή και συστηματικό τρόπο στο υποκείμενο περιβάλλον εκτέλεσης.
|
||||
|
||||
Οι βασικές λειτουργίες που απαιτούνται από την εργασία μπορούν να αναχθούν σε ένα σχετικά μικρό σύνολο
|
||||
\emph{πρωτογενών κατασκευών} του Mininet και του Linux.
|
||||
Η δημιουργία hosts και switches, η σύνδεσή τους μέσω links και η εκτέλεση εντολών μέσα στους αντίστοιχους
|
||||
network namespaces επαρκούν για την κατασκευή της απαιτούμενης τοπολογίας.
|
||||
Ένας δρομολογητής μπορεί αντίστοιχα να μοντελοποιηθεί ως host με περισσότερες από μία διεπαφές, κατάλληλη
|
||||
Layer-3 διευθυνσιοδότηση και ενεργοποιημένη προώθηση IP.
|
||||
Ο DHCP server μπορεί να θεωρηθεί ως υπηρεσία που εκτελείται σε έναν κόμβο και συνδέεται με συγκεκριμένη διεπαφή.
|
||||
|
||||
Πριν οριστικοποιηθούν οι οντότητες της DSL, εξετάστηκαν οι βασικές λειτουργίες που παρέχει το Mininet και το
|
||||
δικτυακό υποσύστημα του Linux για την κατασκευή και παραμετροποίηση μιας τοπολογίας.
|
||||
Οι κύριες λειτουργίες που χρησιμοποιήθηκαν ως βάση είναι οι \texttt{addHost()}, \texttt{addSwitch()} και
|
||||
\texttt{addLink()}, καθώς και η δυνατότητα εκτέλεσης εντολών μέσα σε κάθε network namespace μέσω του
|
||||
\texttt{node.cmd()}.
|
||||
Στις λειτουργίες αυτές προστίθενται η παραμετροποίηση διεπαφών και δρομολόγησης μέσω εργαλείων του Linux και η
|
||||
εκκίνηση διεργασιών, όπως ο \texttt{dnsmasq}, μέσα στον αντίστοιχο κόμβο.
|
||||
Η ανάλυση αυτή χρησιμοποιήθηκε για να \textbf{σταθεροποιηθεί το σύνολο των αφαιρέσεων της DSL}, έτσι ώστε κάθε
|
||||
υψηλού επιπέδου κατασκευή να έχει σαφή δρόμο μετάφρασης προς τις διαθέσιμες λειτουργίες του backend.
|
||||
|
||||
Με βάση τις παρατηρήσεις αυτές επιλέχθηκε ένα σύνολο οντοτήτων ώστε η DSL να \textbf{καλύπτει τον χώρο των
|
||||
κατασκευών που απαιτούνται από την εργασία}.
|
||||
Αντίστοιχα, το σύνολο των primitives του Mininet και του Linux που χρησιμοποιείται είναι επαρκές ώστε κάθε
|
||||
κατασκευή της DSL να μπορεί να μεταφραστεί σε συγκεκριμένες λειτουργίες του backend.
|
||||
Με αυτή την έννοια, τόσο η γλώσσα ως προς τον χώρο του προβλήματος όσο και τα χρησιμοποιούμενα primitives ως
|
||||
προς τον χώρο της υλοποίησης λειτουργούν \emph{«επί»}.
|
||||
Δηλαδή, δεν παραμένει απαίτηση της εργασίας χωρίς αναπαράσταση στη DSL ούτε κατασκευή της DSL χωρίς αντίστοιχη
|
||||
υλοποίηση στο Mininet και στο Linux.
|
||||
Οι βασικές οντότητες της γλώσσας είναι οι \emph{κόμβοι}, οι \emph{διεπαφές}, οι \emph{σύνδεσμοι}, οι
|
||||
\emph{ρυθμίσεις κόμβων} και οι \emph{υπηρεσίες}.
|
||||
|
||||
\subsubsection{Βασική γραμματική}
|
||||
|
||||
Η τοπολογία περιγράφεται από τρεις κύριες κατηγορίες αντικειμένων: \texttt{nodes}, \texttt{links} και
|
||||
\texttt{services}.
|
||||
Η βασική δομή της γλώσσας μπορεί να συνοψιστεί ως εξής:
|
||||
|
||||
\begin{verbatim}
|
||||
Network
|
||||
|-- Nodes
|
||||
| |-- name
|
||||
| |-- type
|
||||
| |-- interfaces
|
||||
| `-- settings
|
||||
|
|
||||
|-- Links
|
||||
| |-- name
|
||||
| |-- endpoints
|
||||
| | |-- node
|
||||
| | `-- interface
|
||||
| `-- settings
|
||||
|
|
||||
`-- Services
|
||||
|-- type
|
||||
|-- node
|
||||
|-- interface
|
||||
`-- settings
|
||||
\end{verbatim}
|
||||
|
||||
Κάθε κατηγορία έχει \textbf{διαφορετική σημασιολογική ευθύνη}.
|
||||
Ένας κόμβος(node) αναπαριστά έναν συμμετέχοντα του δικτύου, μία διεπαφή(interface) ένα σημείο σύνδεσης που ανήκει σε έναν κόμβο
|
||||
και ένας σύνδεσμος(link) συνδέει δύο τέτοια σημεία.
|
||||
Οι ρυθμίσεις(settings) κόμβου περιγράφουν ιδιότητες του ίδιου του δικτυακού namespace, ενώ οι υπηρεσίες(services) αναπαριστούν
|
||||
ανεξάρτητες διεργασίες που εκτελούνται μέσα σε αυτό.
|
||||
|
||||
\subsubsection{Κόμβοι και διεπαφές}
|
||||
|
||||
Οι κόμβοι δηλώνονται με ένα μοναδικό λογικό όνομα και έναν τύπο.
|
||||
Οι τύποι που υποστηρίζονται στην παρούσα υλοποίηση είναι \texttt{host}, \texttt{switch} και \texttt{router}.
|
||||
Ο τύπος εκφράζει τη \emph{σημασιολογία του κόμβου} και όχι απαραίτητα το συγκεκριμένο αντικείμενο του Mininet που
|
||||
θα χρησιμοποιηθεί για την υλοποίησή του.
|
||||
|
||||
Οι διεπαφές \textbf{ανήκουν στους κόμβους} και προσδιορίζονται από λογικά ονόματα, τα οποία δεν απαιτείται να
|
||||
ταυτίζονται με τα ονόματα που θα δημιουργηθούν τελικά στο Linux.
|
||||
Για παράδειγμα, μία διεπαφή με λογικό όνομα \texttt{lan} μπορεί κατά την υλοποίηση να αντιστοιχιστεί στη φυσική
|
||||
διεπαφή \texttt{r0-eth0}.
|
||||
Η επιλογή αυτή επιτρέπει στο αρχείο JSON να χρησιμοποιεί ονόματα που εκφράζουν τον ρόλο μιας διεπαφής και όχι
|
||||
λεπτομέρειες της διαδικασίας δημιουργίας της.
|
||||
|
||||
Μία διεπαφή μπορεί να χρησιμοποιεί στατική διευθυνσιοδότηση, DHCP ή να μην διαθέτει καθόλου Layer-3
|
||||
παραμετροποίηση.
|
||||
Στην περίπτωση στατικής διευθυνσιοδότησης δηλώνεται η διεύθυνση μαζί με το prefix και, προαιρετικά, μία
|
||||
προεπιλεγμένη πύλη.
|
||||
Επιπλέον μπορούν να δηλωθούν ιδιότητες όπως η διεύθυνση MAC και το MTU.
|
||||
|
||||
Ιδιαίτερη σημασία έχει η διάκριση μεταξύ της \textbf{απουσίας} του πεδίου \texttt{interfaces} και της δήλωσης
|
||||
ενός κενού αντικειμένου \texttt{interfaces}.
|
||||
Όταν το πεδίο παραλείπεται, ο κόμβος θεωρείται ότι διαθέτει \emph{δυναμικό σύνολο διεπαφών} και νέες διεπαφές
|
||||
μπορούν να δημιουργηθούν κατά την επίλυση των συνδέσμων.
|
||||
Αντίθετα, όταν το πεδίο υπάρχει, ακόμη και αν είναι κενό, το σύνολο των διαθέσιμων διεπαφών θεωρείται
|
||||
\emph{σταθερό}.
|
||||
|
||||
\subsubsection{Σύνδεσμοι και αυτόματη επιλογή διεπαφών}
|
||||
|
||||
Κάθε σύνδεσμος αποτελεί αυτοτελή οντότητα και συνδέει ακριβώς δύο endpoints.
|
||||
Κάθε endpoint προσδιορίζει τον κόμβο στον οποίο ανήκει και τη λογική διεπαφή μέσω της οποίας πραγματοποιείται η
|
||||
σύνδεση.
|
||||
Η διεπαφή μπορεί να δηλωθεί ρητά ή να χρησιμοποιηθεί ο ειδικός επιλογέας \texttt{auto}.
|
||||
|
||||
Όταν χρησιμοποιείται το \texttt{auto} σε κόμβο με σταθερό σύνολο διεπαφών, επιλέγεται μία από τις δηλωμένες
|
||||
διεπαφές που δεν έχει ήδη δεσμευτεί από άλλη σύνδεση.
|
||||
Αν δεν υπάρχει ελεύθερη διεπαφή, η τοπολογία θεωρείται μη έγκυρη και \textbf{δεν δημιουργείται επιπλέον θύρα
|
||||
σιωπηρά}.
|
||||
Όταν αντίθετα το σύνολο διεπαφών έχει παραλειφθεί, το \texttt{auto} επιτρέπει τη δυναμική δημιουργία νέας λογικής
|
||||
διεπαφής για τις ανάγκες του συνδέσμου.
|
||||
|
||||
Οι σύνδεσμοι μπορούν επίσης να περιλαμβάνουν παραμέτρους προσομοίωσης χαρακτηριστικών του φυσικού μέσου.
|
||||
Η τρέχουσα γλώσσα υποστηρίζει περιορισμό εύρους ζώνης, καθυστέρηση, απώλεια πακέτων και jitter μέσω των πεδίων
|
||||
\texttt{bandwidth\_mbps}, \texttt{delay\_ms}, \texttt{loss\_percent} και \texttt{jitter\_ms}.
|
||||
|
||||
\subsubsection{Ρυθμίσεις κόμβων και υπηρεσίες}
|
||||
|
||||
Οι ρυθμίσεις που αφορούν τη λειτουργία του ίδιου του κόμβου τοποθετούνται στο αντικείμενο \texttt{settings} του
|
||||
αντίστοιχου node.
|
||||
Για τον τύπο \texttt{router}, για παράδειγμα, υποστηρίζονται η ενεργοποίηση του IP forwarding και η
|
||||
απενεργοποίηση του reverse path filtering.
|
||||
Οι ιδιότητες αυτές αντιμετωπίζονται ως \emph{χαρακτηριστικά του network namespace} και όχι ως ανεξάρτητες
|
||||
υπηρεσίες.
|
||||
|
||||
Οι υπηρεσίες μοντελοποιούνται ξεχωριστά επειδή αντιστοιχούν σε \textbf{διεργασίες που εκτελούνται πάνω σε έναν
|
||||
κόμβο}.
|
||||
Στην παρούσα εργασία υποστηρίζεται η υπηρεσία \texttt{dhcp-server}, η οποία συνδέεται με έναν κόμβο και μία από
|
||||
τις διεπαφές του.
|
||||
Οι παράμετροι της υπηρεσίας περιλαμβάνουν το εύρος διευθύνσεων που μπορούν να εκχωρηθούν και την προεπιλεγμένη
|
||||
πύλη που διαφημίζεται στους DHCP clients.
|
||||
|
||||
Η θέση εκτέλεσης μιας υπηρεσίας και η διεπαφή στην οποία συνδέεται αποτελούν μέρος της ίδιας της ταυτότητάς της
|
||||
και για τον λόγο αυτό δηλώνονται έξω από το αντικείμενο \texttt{settings}.
|
||||
Με αυτόν τον διαχωρισμό, το \texttt{settings} περιγράφει αποκλειστικά τη συμπεριφορά της υπηρεσίας και όχι το
|
||||
σημείο στο οποίο αυτή τοποθετείται μέσα στην τοπολογία.
|
||||
|
||||
\subsubsection{Αυστηρότητα της γραμματικής}
|
||||
|
||||
Η γραμματική σχεδιάστηκε ώστε να είναι \textbf{αυστηρή} και να μην αγνοεί άγνωστα πεδία ή μη υποστηριζόμενες
|
||||
τιμές.
|
||||
Ένα τυπογραφικό λάθος σε ένα όνομα ιδιότητας δεν αντιμετωπίζεται επομένως ως απουσία της ιδιότητας, αλλά ως
|
||||
σφάλμα της περιγραφής.
|
||||
Η επιλογή αυτή περιορίζει την πιθανότητα μία συντακτικά αποδεκτή αλλά διαφορετική από την επιθυμητή τοπολογία
|
||||
να δημιουργηθεί χωρίς εμφανή προειδοποίηση.
|
||||
|
||||
Η γλώσσα διαχωρίζει επίσης τη \emph{δομική εγκυρότητα} μιας περιγραφής από τη \emph{σημασιολογική συνέπειά} της.
|
||||
Ένα αντικείμενο μπορεί να ακολουθεί σωστά τη γραμματική αλλά να περιγράφει, για παράδειγμα, έναν σύνδεσμο προς
|
||||
ανύπαρκτο κόμβο ή μία στατική πύλη εκτός του αντίστοιχου υποδικτύου.
|
||||
Η διάκριση αυτή αξιοποιείται στη συνέχεια από την αρχιτεκτονική του builder, όπου η ανάλυση της γραμματικής και
|
||||
ο σημασιολογικός έλεγχος πραγματοποιούνται σε \textbf{διαφορετικά στάδια}.
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Συμπεράσματα}
|
||||
...
|
||||
|
||||
\section{Σύνοψη}
|
||||
|
||||
Τέλος, ...
|
||||
|
||||
\end{document}
|
||||
Reference in New Issue
Block a user