Changeset 6 for doc/AssociazioneMultipla.tex

Timestamp:

May 10, 2007, 3:31:03 PM (18 years ago)

Author:

soujak

Message:

Terminata Soluzioni.SopraIlFirmware.(Descrizione|Vantaggi)

File:

• doc/AssociazioneMultipla.tex (modified) (4 diffs)

doc/AssociazioneMultipla.tex

@@ -389 +389 @@
 
 \paragraph{Gabola}
+\label{gabola}
 Uno degli aspetti più convincenti di questa soluzione è la possibilità di
 utilizzare la modalità di risparmio energetica (introdotta nella
@@ -398 +399 @@
 risveglio per ricevere l'intera mole di informazioni in attesa di consegna.
 
-% :   * il driver sara' in grado di gestire in un unico punto d'entrata le
-% :     interfacce multiple offerte dal SO
+\paragraph{Architettura}
+Il \textit{design} della soluzione intende rispondere alle esigenze di
+trasparenza per il sistema operativo e, di conseguenza, per l'utente.
+Le interfacce virtuali, della cui presenza il \textit{driver} è tenuto a
+notificare il SO, aderiscono alle \textit{Wireless Extensions} e si
+differenziano attraverso diversi indirizzi MAC (verosimilmente fittizi).
+Questa forma di \textit{spoofing} è necessaria sia per lo smistamento dei flussi
+in entrata alla stazione e provenienti dai BSS, sia per il convogliamento di
+quelli in uscita dalla stazione e diretti ai vari BSS.
 %       TODO
 %       Grafico della faccenda
@@ -406 +414 @@
 %       DRI     \|/
 %       FW      [ ]
-Si consiglia inoltre che il \textit{client} si presenti ai differenti BSS con
-indirizzi MAC diversi fra loro, in modo tale da evitare partecipazione
-ridondante al medesimo ESS.
-
-% .   * componente scheduler (-> interfacce virtuali wext compliant) che
-% .     pianifica le trasmissioni
-
-
+%     ANTENNA    Y
+%              .'  `.
+% BSS1       .'      B1
+% BSS2     B2
+Così facendo si renderà peraltro possibile l'utilizzo di associazioni multiple
+all'interno del medesimo ESS per ridondare la partecipazione.
+La residenza del componente di gestione dei flussi multipli di comunicazione
+all'interno del \textit{driver} lascia chiaramente spazio all'aggiunta di
+politiche per pianificazioni ottimali delle trasmissioni (se ne parlerà più
+approfonditamente in \ref{sec:ottimizzazioni}.
 
 \subsubsection{Vantaggi}
-% :   * nessuna perdita di dati
-% .     * power-saving e bufferizzazione dei dati da parte degli AP
-%     * buone prestazioni
-% .     * reale associazione multipla -> nessun overhead per 
-% .       riautenticazione/riassociazione
-% .   * totale trasparenza grazie alle interfacce wext compliant
-% .   * si puo' non partire da zero (-> madwifi)
+\begin{description}
+ \item [Perdita di dati nulla]
+ \begin{math} \Leftarrow \end{math}
+ i dati in arrivo vengono conservati dai BSS grazie allo sfruttamento della
+ modalità di risparmio energetico (cfr. \ref{gabola}).
+ \item [Prestazioni massime] \begin{math} \Leftarrow \end{math}
+ l'effettiva associazione multipla minimizza il costo dei salti evitando
+ riautenticazioni e riassociazioni.
+ \item [Trasparenza totale] \begin{math} \Leftarrow \end{math}
+ le interfacce aderenti alle \texttt{wext} nascondono completamente la realtà
+ dei fatti (cfr. \ref{sec:wext}).
+ \item [Punto di partenza già disponibile] \begin{math} \Leftarrow \end{math}
+ \texttt{MADWiFi} implementa un sottoinsieme delle funzionalità in oggetto
+ (cfr. \ref{sec:madwifi}).
+\end{description}
 
 \subsubsection{Svantaggi}
-%     * grosso sforzo per l'implementazione
-% .     * parziale reimplementazione di MAC per occuparsi di beghe causate
-%         dalla molteplicita' dei BSS:
-% .       * tempistiche: sincronizzazione, rilevamento beacon persi ed eventuale
-% .         sfruttamento dei CFP. (beacon interval noti e mantenimento di
-% .         informazioni necessarie per ogni BSS)
-% .       * sottotipi di autenticazione/crittografia: mantenimento chiavi
-% .         (|di sessione), stato della crittografia e dell'autenticazione.
-% .         (getter e setter sugli attributi MIB relativi)
-% .     * complessita' intrinseca dovuta al livello implementativo
-% .     * firmware spesso solo binari, quindi probabile reverse engineering
-% .   * prestazioni non eccellenti, perche` limitate da power-saving e relativi
-% .     obblighi temporali (TIM...) {non posso proprio fare i miei comodi al
-% .     100% }
+\begin{description}
+ \item [Sforzo implementativo considerevole] : \\
+  \begin{math} \Leftarrow \end{math}
+  aggiunta delle nuove funzionalità, mantentendo le informazioni relative agli
+  stati di autenticazione associazione ed eventualmente sincronizzando la
+  presenza su un BSS ad infrastruttura con i periodi liberi da contesa; \\
+  \begin{math} \Leftarrow \end{math}
+  parziale reimplementazione di MAC, evitando la perdita dei \texttt{beacon},
+  indispensabili per il rispetto dei vincoli temporali
+  (\ref{sec:vincolitemporali}); \\
+  \begin{math} \Leftarrow \end{math}
+  complessità intrinseca dovuta al basso livello a cui si è costretti ad agire;
+  \\
+  \begin{math} \Leftarrow \end{math}
+  forma binaria nella quale i \textit{firmware} sono sovente distribuiti che
+  può costringere a noiose operazioni di ingegneria inversa.
+\item [Limitazioni prestazionali] \begin{math} \Leftarrow \end{math}
+  i vincoli temporali dovuti ad esigenze ordinarie (mantenimento
+  dell'associazione) e aggiuntive (ritiro dei dati conservati dai BSS)
+  costringono a salti indesiderati;
+ \item [] \begin{math} \Leftarrow \end{math}
 %     * troppo specifico
 %       * dipendenza dalla piattaforma fw -> portabilita' minima
@@ -444 +469 @@
 % .     * la soluzione dipende fortemente dal firmware di riferimento, scarsa
 % .       programmabilita' di parecchie implementazioni
+ \item [] \begin{math} \Leftarrow \end{math}
+ 
+\end{description}
 
 \subsection{Sopra il \textit{driver}}