Comportamento di un nodo fornitore di servizi

Il modello presentato fino ad ora, si basa su elementi che fanno parte della conoscenza locale del richiedente, infatti la semantica di un servizio fornito da un dispositivo, se `e stato rilevato, non varia nel tempo, inoltre la mobilit`a relativa tra due nodi pu`o essere rilevata in modo simmetrico (eventi di con- nessione e disconnessione coincideranno per i due capi della comunicazione) e lo stesso vale per le velocit`a di trasmissione.

L’uso esclusivo di conoscenza locale sempre aggiornata non `e per`o possi- bile una volta che si consideri il tempo necessario a chi fornisce il servizio per effettuare l’esecuzione del servizio stesso. Infatti, mentre le caratteristiche hardware e software del dispositivo e del servizio offerto sono costanti, non lo sono il tempo di esecuzione in locale del servizio, che pu`o essere influenzato da altre attivit`a in corso sul device, e l’eventuale periodo di attesa che pre- cede l’esecuzione dovuto dalla presenza di altre richieste di servizio in arrivo allo stesso fornitore.

Il modello per l’esecuzione di servizi per un nodo della rete pu`o essere defini- to una volta descritto il comportamento generale del device al momento della ricezione di una richiesta. Un qualsiasi nodo della rete che offra un insieme

S1 S2 S1 N2 S3 N1 N3 N5 Rate di servizio Flusso Richieste

Coda richieste Nodo Provider

Figura 3.7: Gli elementi che compongono un sistema a coda

di servizi S1, ..., Sm (provider ) potrebbe ricevere richieste da altri utenti con

cui entra in contatto (seekers) per ognuno dei servizi esposti.

Il flusso delle richieste in arrivo deve essere gestito tramite una coda FIFO di attesa (si assume non ci siano differenze di priorit`a tra le richieste) da cui il provider estrae le richieste da eseguire ogni volta che termina l’esecuzione di un servizio. Ogni richiesta in arrivo su un provider deve quindi attende- re un periodo di tempo all’interno della coda, fino al momento in cui viene selezionata per l’esecuzione, che `e a sua volta caratterizzata da un ritardo dipendente dal servizio richiesto e dall’hardware del dispositivo. Al termine dell’esecuzione del servizio, l’output viene trasferito al richiedente o ad un altro nodo della rete, nel caso il servizio faccia parte di un servizio composto. Il tempo di attesa in coda `e determinabile per il provider come il tempo necessario per eseguire i servizi che precedono la richiesta, ma per il seeker non `e possibile ottenere questa informazione senza avere conoscenza sempre aggiornata dello stato del provider.

Le connessioni tra nodi della rete permettono di distribuire la conoscenza e di raccogliere dati per effettuare delle stime, ma i dati non possono essere continuamente aggiornati a costo di saturare la rete con il traffico e i pe- riodi di disconnessione portano ad un’inevitabile perdita di attualit`a della conoscenza a disposizione. C’`e quindi bisogno di sfruttare un modello che permetta di costruire delle stime meno indicative dello stato istantaneo del provider e che forniscano una migliore approssimazione dello stato medio del sistema.

Il calcolo del tempo di attesa `e un problema classico dei sistemi client- server ed `e stato analizzato nell’area di ricerca di teoria delle code [43], in cui

in base ai processi stocastici che approssimano la frequenza di arrivo delle richieste e di esecuzione dei servizi, `e possibile definire un modello stocastico dello stato della coda.

Le richieste in arrivo al provider sono influenzate dai periodi di discon- nessione con gli altri nodi. Un seeker nA che genera richieste per un provider

nB con un proprio rate, pu`o generare tali richieste durante un periodo di

disconnessione. Al momento in cui la connessione viene ristabilita, `e quindi possibile che esistano pi`u richieste da parte dello stesso seeker verso lo stesso provider e che il seeker cerchi quindi di trasferirle durante il tempo di con- tatto raccolte in un batch.

Il processo stocastico che approssima uno scenario simile a quello descrit- to `e il processo di Poisson in cui batch di richieste vengono inviati al provider ad intervalli distribuiti esponenzialmente e le quantit`a di messaggi nei batch sono identicamente e indipendentemente distribuiti. Questa ipotesi ci per- mette di approssimare il modello del sistema a coda ad un modello standard esistente in letteratura (M[X]_{/G/1) [44], per il quale un singolo nodo di ela-}

borazione si occupa di risolvere le richieste ricevute secondo la distribuzione descritta in precedenza, dopo averle inserite in una coda infinita secondo una politica FIFO.

Per il modello M[X]/G/1 le richieste arrivano al provider sotto forma di batch separati da intervalli di tempo distribuiti esponenzialmente. Il modello che vogliamo definire intende modellare proprio questo comportamento, dato che il provider stabilisce un nuovo contatto con i nodi della rete secondo una distribuzione esponenziale e quindi il provider ricever`a un batch da un seeker ad intervalli distribuiti esponenzialmente. La dimensione dei batch `e rego- lata dalla distribuzione di Poisson con cui possiamo assumere che i seeker generino le richieste, che `e una distribuzione senza memoria e quindi i batch risultano indipendenti l’uno dall’altro e identicamente distribuiti.

Il rate medio di risoluzione delle richieste in coda dipende dai diversi ser- vizi esposti dal provider e da quali servizi sono richiesti dai seeker. Dato che caratterizzare a livello di modello le distribuzioni dei tempi di esecuzione dei servizi pu`o portare a porre assunzioni molto forti, la descrizione tramite una distribuzione generale ci permette di rendere il modello di esecuzione dei

servizi molto elastico.

Grazie al lavoro contenuto in [44], vedremo nel capitolo 4, come possia- mo sfruttare il modello M[X]_{/G/1 per ricavare la definizione di una variabile}

aleatoria per esprime il tempo di attesa in coda per una qualsiasi richiesta inviata al provider tramite il suo valore atteso e varianza, con, unici dati da ricavare, i primi tre momenti del tempo di interarrivo delle richieste, del loro tempo di esecuzione e del numero di richieste contenute in batch.

I valori necessari sono calcolabili tramite le rilevazioni effettuate dal pro- vider. Mentre tale conoscenza `e aggiornata costantemente dal provider, non `

e possibile per il seeker dare una stima del tempo di attesa in coda e del tempo di esecuzione del servizio.

Ogni seeker dovr`a quindi affidarsi alla conoscenza trasmessa dai fornitori di servizi che non pu`o essere aggiornata durante i periodi di intercontatto.

Il tempo totale di esecuzione di una richiesta su di un singolo provider `e composta dalle fasi finora descritte: tempo di attesa per il contatto, tempo di upload dei parametri di input, tempo di attesa in coda sul provider, tem- po di esecuzione del servizio richiesto sul provider e tempo di trasferimento dell’output.