4.1 Introduzione al protocollo RTSP

Dimensione: px
Iniziare la visualizzazioe della pagina:

Download "4.1 Introduzione al protocollo RTSP"

Transcript

1 4.1 Introduzione al protocollo RTSP Il Real Time Streaming Protocol (RTSP) [Schulzrinne e altri, 98] è un protocollo di livello applicazione, che fornisce un framework estensibile utile per implementare il controllo del trasporto di dati multimediali isocroni. Il protocollo RTSP inizializza e controlla flussi singoli o multipli di media continui sincronizzati nel tempo. Esso non trasporta i dati costituenti questi flussi, anche se è possibile realizzare una trasmissione interlacciata dei flussi di controllo con quelli dei dati. RTSP funziona come un controllo remoto su rete per server multimediali. L insieme dei flussi da controllare sono specificati tramite una descrizione della presentazione. La nozione di connessione RTSP non esiste: invece un server crea un identificatore univoco per ogni sessione. Una sessione RTSP non è legata in alcun modo ad una connessione di trasporto come una su TCP. Durante una sessione RTSP, un client RTSP, per trasmettere le sue richieste, può utilizzare una connessione diversa per ognuna di esse. In alternativa è possibile usare un protocollo di trasporto non orientato alla connessione come l UDP. I flussi controllati da RTSP possono usare il protocollo RTP, ma il funzionamento di RTSP non dipende dallo specifico meccanismo di trasporto utilizzato per i dati multimediali. RTSP è stato progettato in modo che fosse simile al protocollo HTTP/1.1 in sintassi ed operazioni, affinchè fosse possibile aggiungere i meccanismi di estensione dell HTTP anche all RTSP. Però RTSP differisce dall HTTP per molti aspetti importanti: RTSP introduce un certo numero di metodi nuovi e utilizza differenti identificatori di protocollo. Un sever RTSP ha la necessità di mantenere delle informazioni di stato, in contrapposizione al funzionamento di HTTP che è privo di un concetto di stato. Sia il client che il server RTSP possono inviare richieste. I dati sono trasportati fuori banda da un protocollo differente. RTSP usa per definizione lo standard ISO (UTF-8) invece che l ISO , in modo da essere consistente con le nuove caratteristiche di internazionalizzazione che si stanno introducendo nell HTTP. L URI (Universal Resource Identifier) delle richieste è sempre assoluto. Mentre l HTTP/1.1 pone nelle richieste solo un percorso assoluto, e inserisce il nome dell host in un campo intestazione separato. L URI assoluto permette di implementare in modo semplice il virtual hosting, con cui si possono mantenere su un singolo host con un unico indirizo IP diverse strutture di documenti. Il protocollo supporta le seguenti operazioni: Prelevamento di sessioni multimediali da un media-server. Il client può richiedere la descrizione di una presentazione multimediale tramite HTTP, SDP o altri metodi. Se la presentazione è trasmessa in multicast, la sua descrizione contiene l indirizzo e le porte usate per trasmettere i flussi real-time. Mentre se la trasmissione è unicast, deve essere il client a fornire al server l indirizzo e le porte a cui trasmettere i flussi real-time. Invito di un media-server in una conferenza. Un media-server può essere invitato ad unirsi in una conferenza esistente, o per effetuare il playback di qualche media all interno della conferenza, oppure per registrare tutti o un sottinsieme dei media esistenti nella conferenza. Le richieste RTSP possono essere gestite dai proxy, tunnel e cache come avviene per l HTTP/1.1 [Fielding e altri, 97].

2 4.1.1 Terminologia Di seguito è riportata la definizione della terminologia utilizzata nell ambito di questo lavoro, in tutto quello che si riferisce a RTSP. Controllo Aggregato: il controllo contemporaneo di flussi multipli. Ad esempio per un flusso audio ed uno video logicamente correlati, un client RTSP può inviare al server una singola richiesta di play o pause, che avrà effetto su entrambi. Conferenza: una presentazione multimediale con più partecipanti (>= 1). Client: l applicazione client che effettua le richieste ad uno o più server di sessioni multimediali. Connessione: un circuito virtuale, strato di trasporto, stabilito tra due applicazioni comunicanti. Media continui: dati caratterizzati da relazioni temporali (audio, video, ecc ). Entità: l informazione trasferita come payload in una richiesta o una risposta RTSP. Una entità è costituita da metainformazioni nella forma di intestazioni-entità, e contenuti nella forma di corpoentità. Media Server: l applicazione server che provvede alla riproduzione e alla registrazione di uno o più flussi multimediali. All interno di una presentazione, differenti flussi possono aver origine da diversi media server. (Media) stream: una singola istanza di media (audio, video, WB, ecc ). Quando si usa RTP, uno stream è costituito da tutti i pacchetti RTP ed RTCP creati da una sorgente in una sessione RTP. Questo è equivalente alla definizione di uno stream DSM-CC 1. Messaggio: l unità base di una comunicazione RTSP costituito da una sequenza strutturata di ottetti conforme alla sintassi RTSP, trasmessa tramite un protocollo orientato o non orientato alla connessione. Partecipanti: sono i membri di una conferenza. Un partcipante può essere anche una macchina (ad es. un media server di registrazione o riproduzione). Presentazione: un insieme di uno o più stream presentati al client come un tutt uno, usando una descrizione della presentazione. In molti casi, ma non sempre, questo implica il controllo aggregato degli stream. Descrizione della presentazione: contiene le informazioni riguardanti uno o più stream della presentazione, come l insieme delle codifiche, gli indirizzi di rete, i contenuti. Altri protocolli dell IETF, come l SDP, usano il termine sessione per indicare una presentazione live. Risposta: un messaggio risposta di RTSP. Richiesta: un messaggio richiesta di RTSP. Sessione RTSP: una transazione RTSP completa, per ottenere, ad esempio, la visione completa di un filmato. 1 Vedi Appendice A.

3 4.2 Implementazione di RTSP Il linguaggio utilizzato per implementare RTSP è Java. Trattandosi di un linguaggio ad oggetti, è stato naturale implementare le varie parti che costituiscono RTSP tramite un mappaggio uno ad uno su opportune classi di Java. Quindi sono state realizzate una classe RtspClient, che implementa un client RTSP e che fa parte del package rtsp.client, e una classe RtspServer, che implementa un server RTSP e che fa parte del package rtsp.server. Mentre il sottosistema di parsing dei messaggi RTSP è realizzato in maniera simile ad un riconoscitore di linguaggi LL1, utilizzando un approccio Top-Down. L insieme di classi che compongono il sottosistema di parsing, sono raggruppate in un package di Java chiamato rtsp.common. I servizi offerti da questo package sono utilizzati sia dal server che dal client Parametri del Protocollo. RTSP URL Per riferire le risorse di rete sono utilizzati gli schemi rtsp ed rtspu. La sintassi per gli URL è: Per ora i fragment ed i query identifiers dell abs_path non hanno per l RTSP un rtsp_url = ( "rtsp:" "rtspu:" ) "//" host [ ":" port ] [abs_path ] host = <A legal Internet host domain name of IP address (in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}> port = *DIGIT abs_path is defined in RFC 2068/Par significato definito (a differenza dell HTTP), quindi in questa implementazione non sono utilizzati. Lo schema rtsp richiede che i comandi vengano trasmessi su un protocollo affidabile (per Internet si usa il TCP), mentre lo schema rtspu identifica un protocollo non affidabile (per Internet si usa l UDP). Si è scelto di implementare il trasporto dei messaggi RTSP solo su TCP, in quanto si è ritenuto necessario utilizzare un protocollo di trasporto affidabile per il trasporto dei messaggi di un protocollo di controllo come RTSP. Se non viene specificata la porta, si assume che essa sia la 554. Una presentazione o uno stream è identificato tramite una stringa di testo, che ha il formato di un URL. Questi URL possono riferirsi ad un singolo stream, oppure ad un aggregato di stream. Un esempio di URL di RTSP è: rtsp://lis3.deis.unical.it:554/lecture1/video con cui si identifica lo stream audio all interno della presentazione Lecture1, che può essere controllata tramite richieste RTSP inviate su di una connessione TCP alla porta 554 dell host lis3.deis.unical.it. Le componenti di un percorso (path) sono opache per il client, e non implicano una struttura particolare del file system del server. La classe RtspURL si occupa di implementare il parsing degli URL utilizzati in RTSP. Timestamp relativi in SMPTE

4 smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ] smpte-type = "smpte" "smpte-30-drop" "smpte-25" ; other timecodes may be added smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ] [ "." 1*2DIGIT ] Esprimono il tempo relativo all inizio di un stream (videoclip). La sintassi è la seguente: L smpte-time ha il formato: ore:minuti:secondi:frame.subframe. Il formato smpte-30-drop ha un frame rate di frame/secondo. Anche se in questa implementazione non viene utilizzato, è stata realizzata la classe Smpte che si occupa del parsing di questo tipo di parametro. Normal Play Time (NPT) Indica la posizione assoluta nello stream relativamente all inizio della presentazione. Questo tipo di timestamp è costituito da una parte sinistra esprimibile o in secondi oppure in ore,minuti e secondi. La parte destra è misurata in frazioni di secondo. L inizio di una presentazione corrisponde ad un npt pari a 0.0; non sono definiti valori negativi. La costante speciale now è utilizzati solo per eventi live. NPT è definito come nel DSM-CC 2 : Intuitivamente l NPT è l orologio che l utente umano associa al programma. E visualizzato come su un VCR. L NPT avanza normalmente in modo play (scala=1), avanza velocemente nel modo fast forward, decrementa quando si effettua il play inverso, è fisso in modo pausa. npt-range = ( npt-time "-" [ npt-time ] ) ( "-" npt-time ) npt-time = "now" npt-sec npt-hhmmss npt-sec = 1*DIGIT [ "." *DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] npt-hh = 1*DIGIT ; any positive number npt-mm = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59 La sintassi è la seguente: Esempi: npt= npt=12:05:35.3- npt=now- Il Parsing degli NPT avviene nella classe omonima Npt. Tempo Assoluto Il tempo assoluto è espresso nel formato ISO 8601, usando UTC (GMT). Si possono indicare anche le frazioni di secondo. La sintassi è la seguente: utc-range = "clock" "=" utc-time "-" [ utc-time ] utc-time = utc-date "T" utc-time "Z" 2 utc-date = 8DIGIT ; < YYYYMMDD > vedi utc-time Appendice A. = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >

5 Esempio: la data 8 Novembre 1998 ore 14:37:20 ed un quarto di secondo in UTC si esprime: T Z Il parsing di questo tipo di parametro avviene nella classe Utc Il sottosistema di parsing dei messaggi. Il messaggio RTSP, nella sua forma più generica, rappresentato dalla classe RtspMessage, ha la forma seguente: INTESTAZIONE CORPO Esistono fondamentalmente due tipi di messaggi: richiesta RTSP ed risposta RTSP. Il protocollo RTSP è di tipo testuale: i messaggi sono delle stringhe di testo, di lunghezza variabile, organizzate per righe, separate dalla combinazione dei caratteri di terminazione CRLF (ASCII 13 e 10), anche se il parser RTSP deve essere capace di distinguere tra due righe separate dal solo carattere CR oppure LF. Ogni riga è divisa in due parti fondamentali: un intestazione (header) di riga, ed un corpo di riga. In alcuni header i corpi di riga sono a loro volta costituita da diversi sottocampi. Nel protocollo RTSP sono definiti vari header di riga, e la maggior parte sono raggruppati nelle seguenti categorie: - General Header; - Entity Header; - Request Header; - Response Header. Quindi nell implementazione sono state realizzate le classi GeneralHeader, EntityHeader, RequestHeader e ResponseHeader, ognuna delle quali si occupa di effettuare il parsing degli header relativi, rappresentati come variabili stringa, alle quali i parser assegnano come valore il relativo corpo di riga. Tutte le classi che implementano gli header, derivano dalla classe astratta Header, ed implementano l interfaccia Parser. Gli utilizzatori degli oggetti di tipo header, come ad esempio gli oggetti di tipo RtspClient ed RtspServer, si occupano di interpretare semanticamente i valori dei corpi di riga che ogni parser estrae da un messaggio. Esistono degli header di riga particolari, che non appartengono a nessuno dei precedenti gruppi, per cui sono state realizzate delle opportune classi che ne implementano il parsing. Tra questi sono stati implementati i seguenti: CseqHeader, TransportHeader, Range; tra l altro gli ultimi due sono caratterizzati da un corpo di riga particolarmente strutturato, per cui sono state realizzate delle opportune classi per poterne realizzare il parsing. I due tipi di messaggi RTSP hanno delle parti del corpo in comune, comprese nella classe RtspMessage, mentre differiscono nell intestazione, ed in altri campi del corpo. Dunque sono state implementate le due classi RtspRequest ed RtspReply, necessarie per tener conto di queste differenze. La strutture sintattiche di una richiesta e di una risposta sono: Request = Request-Line *( general-header request-header entity-header) CRLF [message-body] Response = Status-Line *( general-header response-header entity-header) CRLF [message-body]

6 Esistono quindi due tipi di intestazione di messaggio: la RequestLine, del tipo richiesta, e la StatusLine, del tipo risposta. Per entrambe sono state implementate le classi omonime Messaggio Richiesta. Request-Line = Method SP Request-URI SP RTSP-Version CRLF L intestazione di una richiesta ha la seguente struttura: Il campo Method rappresenta il comando che deve essere eseguito dal destinatario della richiesta (server RTSP o client RTSP). L interpretazione di questo campo avviene nelle rispettive classi RtspClient ed RtspServer, che implementano la semantica del protocollo RTSP. I metodi 3 attualmente definiti nel protocollo sono: "DESCRIBE", "ANNOUNCE", "GET_PARAMETER", "OPTIONS", "PAUSE", "PLAY", "RECORD", "REDIRECT", "SETUP", "SET_PARAMETER" e "TEARDOWN". Il campo Request-URI specifica la risorsa (il flusso dei dati multimediali, il file che li contiene) oggetto della richiesta. Per il parsing di questo campo è stata utilizzata una classe detta RtspURL. Il campo RTSP-Version indica la versione del protocollo RTSP utilizzata nel messaggio; la sua interpretazione avviene nella classe RequestLine stessa. Il suo formato è: RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT Messaggio Risposta. L intestazione di una risposta ha la seguente struttura: Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF Il campo RTSP-Version è identico a quello visto nella Request-Line. Il campo Status-Code è una stringa numerica rappresentante, sotto forma di codice di uscita, il risultato che ha avuto l esecuzione del comando inviato nel messaggio di richiesta di cui questo è il messaggio di risposta. La Reason-Phrase è il messaggio corrispondente allo Status-Code, in una forma intellegibile anche per l utente umano. Il parsing della Status-Line viene effettuato nella classe omonima StatusLine. 3 Del significato d'ogni metodo si parlerà nel paragrafo relativo al server RTSP.

7 La seguente è la lista dei codici attualmente definiti nel protocollo: Status-Code Reason-Phrase * "100" Continue * "200" OK "201" Created "250" Low on Storage Space * "300" Multiple Choices * "301" Moved Permanently * "302" Moved Temporarily "303" See Other "304" Not Modified "305" Use Proxy * "400" Bad Request "401" Unauthorized "402" Payment Required "403" Forbidden * "404" Not Found * "405" Method Not Allowed * "406" Not Acceptable "407" Proxy Authentication Required "408" Request Time-out "410" Gone "411" Length Required "412" Precondition Failed "413" Request Entity Too Large "414" Request-URI Too Large "415" Unsupported Media Type * "451" Parameter Not Understood "452" Conference Not Found "453" Not Enough Bandwidth * "454" Session Not Found * "455" Method Not Valid in This State "456" Header Field Not Valid for Resource "457" Invalid Range "458" Parameter Is Read-Only * "459" Aggregate operation not allowed * "460" Only aggregate operation allowed "461" Unsupported transport "462" Destination unreachable * "500" Internal Server Error * "501" Not Implemented "502" Bad Gateway "503" Service Unavailable "504" Gateway Time-out * "505" RTSP Version not supported "551" Option not supported Il primo numero di uno Status-Code ne definisce la classe: - 1xx: Informativo - Richiesta ricevuta, il processo continua. - 2xx: Successo - L ultima azione è stata ricevuta, compresa e accettata con successo. - 3xx: Redirezione - Bisogna intraprendere ulteriori azioni per completare la richiesta. - 4xx: Errore del client - La richiesta contiene errori sintattici e non può essere soddisfatta. - 5xx: Errore del server - Il server non è riuscito a soddisfare una richiesta apparentemente valida.

8 Gli Status-Code sono estensibili. In generale un implementazione di RTSP deve usare e riconoscere almeno i codici del tipo x00: questa implementazione del protocollo riconosce ed usa i codici marcati con *. Le Reason-Phrase sono solo indicative, e possono essere modificate o estese in maniera coerente, e questo è stato fatto in vari casi, per rendere maggiormente comprensibili i messaggi che il client mostra all utente General Header. Questo tipo di header comprende i seguenti: - Cache-Control; - Connection; - Date; - Via. Il parser della classe GeneralHeader riesce a riconoscerli tutti, però in questa implementazione viene utilizzato solo l header Date, implementato nella classe omonima. "Date" ":" HTTP-date L header Date ha la seguente sintassi: Questa implementazione utilizza il formato HTTP-date più recente, definito nell RFC 1123; un esempio è : Date:30 Oct :59:03 GMT Il valore di questo header si riferisce all istante in cui il messaggio, che lo contiene, è stato inviato Entity Header. Questo tipo di header definisce metainformazioni opzionali riguardanti il corpo-entità, oppure, se questo non è presente, la risorsa identificata dalla richiesta. Gli header compresi in questo gruppo sono : - Allow; - Content-Base; - Content-Encoding; - Content-Language; - Content-Length; - Content-Location; - Content-Type; - Expires; - Last-Modified. Come per gli General Header, il parser della classe EntityHeader li riconosce tutti, ma questa implementazione usa solo quelli descritti di seguito. L header Content-Base può essere usato per specificare l URI di base per la risoluzione di un URL relativo. La sintassi è: "Content-Base" ":" absoluteuri

9 Se questo header non compare nel messaggio, l URI di base viene definito o tramite l header Content-Location (se questo è un URI assoluto), oppure tramite il primo URI utilizzato nella sessione RTSP. L header Content-Length indica la dimensione dell entità del messaggio, il numero (in formato decimale) degli ottetti che lo compongono. Deve essere sempre presente in tutti i messaggi il cui corpo non è vuoto. Se viene omesso si assume che la lunghezza del corpo del messaggio è zero. La sintassi è: "Content-Length" ":" 1*DIGIT L header Content-Location può essere usato per ricostruire l URI completo per individuare una risorsa referenziata in un messaggio. La sintassi è: "Content-Location" ":"( absoluteuri relativeuri ) Se l URI è relativo, viene interpretato in relazione all URI del Content-Base, se invece non è presente un header Content-Base, l URI viene interpretato relativamente al Request-URI. L header Content-Type indica il tipo di dati inviati nell entità del messaggio (in genere una risposta). Il tipo di dati inviato in un messaggio deve essere tra quelli comprensibili per il "Content-Type" ":" media-type destinatario, il quale li specifica tramite l header Accept inviato con la richiesta. La sintassi e: Un esempio di media-type e application/sdp, con cui si indica che il corpo-entità del messaggio trasporta una descrizione di sessione secondo il protocollo SDP Request Header. In questo gruppo sono compresi: - Accept; - Accept-Encoding; - Accept-Language; - Authorization; - From; - If-Modified-Since; - Range; - Referer; - User-Agent. Questi header sono utilizzati esclusivamente nelle richieste, eccetto l header Range che può essere usato anche nelle risposte. Come nei casi precedenti il parser della classe RequestHeader li riconosce tutti, questa implementazione utilizza quelli descritti di seguito. L header Accept può essere utilizzato per specificare quale tipologie di descrizioni di sessione sono accettabili nella risposta ad una richiesta contenente questo header. Un esempio è: Accept: application/rtsl, application/sdp

10 L header Range specifica un intervallo di tempo. Questo intervallo può essere specificato in tre diversi formati : smpte, npt e clock. L RtspServer e l RtspClient utilizzano il formato npt. Quando Range viene utilizzato in una risposta, indica quale intervallo di tempo è correntemente in fase di riproduzione o di registrazione. Inoltre possono essere usati intervalli aperti a destra. Il corpo del header può contenere un campo nel formato UTC, con cui si specifica l istante di tempo dal quale l operazione relativa dovrà essere effettivamente eseguita. La sintassi è: Dove i ranges-specifier sono descritti nel paragrafo "Range" ":" 1\#ranges-specifier[ ";" "time" "=" utc-time ] ranges-specifier = npt-range utc-range smpte-range Per la complessità dell operazione di parsing, questo header è stato implementato nella classe apposita Range Response Header. In questo gruppo sono compresi: - Location; - Proxy-Authenticate; - Public; - Retry-After; - Server; - Vary; - WWW-Authenticate. Sono utilizzati per consentire al destinatario di una richiesta di fornire nella risposta informazioni addizionali, che non potrebbero essere inserite nella Status-Line. Queste informazioni riguardano il server e ulteriori accessi alla risorsa identificata dal Request-URI. In questa implementazione si utilizza solo l header Location, utilizzato per redirigere il ricevente ad un indirizzo diverso dal Request-URI, per poter completare la richiesta o l identificazione di una risorsa. La classe ResponseHeader si occupa del parsing di questo gruppo di header Header di richiesta e risposta. Il parsing di questi header viene effettuato in entrambe le classi RtspRequest ed RtspResponse. Transport Header Questo header, utizzato sia nelle richieste che nelle risposte, è fondamentale per il client ed il server nel realizzare la contrattazione ed il setup dei parametri di una sessione RTSP.

11 Siccome è caratterizatto da una sintassi complessa per il suo parsing è stata realizzata una classe apposita detta appunto TransportHeader. La sintassi di questo header è: Transport = "Transport" ":" 1\#transport-spec transport-spec = transport-protocol/profile[/lower-transport] *parameter transport-protocol = "RTP" profile = "AVP" lower-transport = "TCP" "UDP" parameter = ( "unicast" "multicast" ) ";" "destination" [ "=" address ] ";" "interleaved" "=" channel [ "-" channel ] ";" "append" ";" "ttl" "=" ttl ";" "layers" "=" 1*DIGIT ";" "port" "=" port [ "-" port ] ";" "client_port" "=" port [ "-" port ] ";" "server_port" "=" port [ "-" port ] ";" "ssrc" "=" ssrc ";" "mode" = <"> 1\#mode <"> ttl = 1*3(DIGIT) port = 1*5(DIGIT) ssrc = 8*8(HEX) channel = 1*3(DIGIT) address = host mode = <"> *Method <"> Method Parametri generali: - unicast multicast: indica in maniera mutuamente esclusiva se il trasporto dei dati deve essere unicast o multicast. Il valore predefinito è multicast. - destination: indica l ndirizzo a cui devono essere spediti gli stream. - source: è utilizzato per specificare l indirizzo da cui gli stream provengono, se differisce da quello dei pacchetti RTSP (il server in caso di playback, il client in caso di recording). - layers: indica il numero di strati multicast usati per gli stream. - mode: indica i metodi supportati per la sessione. I valori possibili sono PLAY e RECORD ; se non specificato si assume il valore PLAY. - append: se il parametro mode include il valore RECORD, questo parametro indica che i dati dei media devono essere accodati a quelli della risorsa esistente sul server anziché sovrascriverli. - interleaved: indica che i dati dei media devono essere interlacciati con quelli del flusso di controllo. Parametri specifici per il multicast: - ttl: multicast time-to-live Parametri specifici per l RTP: - port: questo parametro fornisce la coppia di porte per l RTP/RTCP, nel caso di una sessione multicast. Viene specificato come un intervallo. - client_port: questo parametro fornisce la coppia di porte RTP/RTCP, nel caso di trasmissione unicast, su cui il client ha scelto di ricevere i dati del media e le relative informazioni di controllo. Viene specificato come un intervallo.

12 - server_port: questo parametro è il complementare del precedente per il server. - ssrc: indica l SSRC dei pacchetti RTP che il server userà (risposta) oppure quello che il client vorrebbe (richiesta). Un Transport Header descrive un singolo stream RTP (RTSP può controllare stream multipli come una singola entità). Session Header Identifica una sessione RTSP dal momento in cui viene inizializzata dal server in risposta ad una richiesta di SETUP, fino a quando viene chiusa da una TEARDOWN. L identificatore di sessione viene scelto dal server; quando il client lo riceve, dovrà utilizzarlo sempre in tutte le richieste "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ] relative a quella sessione. La sintassi è: Il parametro timeout è utilizzabile dal server solo nelle risposte, per indicare per quanto tempo attenderà tra un comando RTSP e il successivo prima di chiudere automaticamente la sessione, per mancanza di attività del client. Qesto parametro è misurato in secondi, e il valore predefinito è pari a 60 secondi. Un singolo session-id può essere utilizzato per controllare stream multipli appartenenti alla stessa sessione. Se un client apre più sessioni per uno stesso URL, dovrà usare un session-id diverso per ogni sessione. CSeq Header Specifica il numero di sequenza per una coppia richiesta-risposta RTSP. E presente in tutte le richieste e risposte: per ogni richiesta con un certo numero di sequenza deve esistere una risposta "CSeq" ":" 1# ( DIGIT ) con lo stesso numero. La sintassi è:

13 Riassunto degli Header. La tabella seguente riassume gli header usati dal RTSP. Il tipo g indica un general header utilizzabile sia nelle richieste che nelle risposte; il tipo R indica i request header; il tipo r indica i response header; il tipo e gli entity header. Gli header contrassegnati con req. nella colonna etichettata support devono essere implementati necessariamente, mentre quelli marcati con opt. sono opzionali. Gli header contrassegnati con u sono quelli effettivamente usati in questa implementazione, mentre è stato comunque implementato il parsing di tutti. Inoltre sono indicati i metodi per i quali ogni header è significativo. 4.3 Dettagli implementativi. Header type support methods Accept R opt. u entity Accept-Encoding R opt. entity Accept-Language R opt. all Allow r opt. all Authorization R opt. all Bandwidth R opt. all Blocksize R opt. all but OPTIONS, TEARDOWN Cache-Control g opt. SETUP Conference R opt. SETUP Connection g req. all Content-Base e opt. u entity Content-Encoding e req. SET_PARAMETER Content-Encoding e req. DESCRIBE, ANNOUNCE Content-Language e req. DESCRIBE, ANNOUNCE Content-Length e req. u SET_PARAMETER, ANNOUNCE Content-Length e req. u entity Content-Location e opt. u entity Content-Type e req. u SET_PARAMETER, ANNOUNCE Content-Type r req. u entity CSeq g req. u all Date g opt. u all Expires e opt. DESCRIBE, ANNOUNCE From R opt. all If-Modified-Since R opt. DESCRIBE, SETUP Last-Modified e opt. entity Proxy-Authenticate Proxy-Require R req. all Public r opt. all Range R opt. u PLAY, PAUSE, RECORD Range r opt. u PLAY, PAUSE, RECORD Referer R opt. all Require R req. all Retry-After r opt. all RTP-Info r req. PLAY Scale Rr opt. PLAY, RECORD Session Rr req. u all but SETUP, OPTIONS Server r opt. all Speed Rr opt. PLAY Transport Rr req. u SETUP Unsupported r req. all User-Agent R opt. all Via g opt. all WWW-Authenticate r opt. all

14 4.3.1 Il server RTSP. Il server RTSP, realizzato con la classe RtspServer, implementa la semantica del protocollo dal lato server. Si tratta di un server a stati, a differenza di un server HTTP, meccanismo necessario per implementare una memoria temporale degli eventi che scandiscono il suo funzionamento. Gli eventi che provocano le transizioni di stato, con la relativa esecuzione di azioni opportune, sono generati dai messaggi di richiesta provenienti da un client. I metodi(par 4.2.3) di questi messaggi ne costituiscono la tipizzazione, e impongono le transizioni di stato al server. La figura rappresenta l automa a stati del server. Recording TEARDOWN PLAY RECORD PAUSE Init SETUP Ready TEARDOWN Terminated PLAY PAUSE RECORD Playing TEARDOWN RECORD e PLAY avvengono solo durante un tunnelling Figura 4.1: Automa del server e del client RTSP A seguito di un messaggio di richiesta, il server esegue una serie di controlli, necessari per verificare la consistenza e la soddisfacibilità della richiesta, quindi cerca di soddisfarla. Se tutto va a buon fine, risponde al client con un messaggio di risposta positivo (status code 200), altrimenti la risposta contiene il codice di errore opportuno, indicante al client la causa dell insoddisfacibilità della sua richiesta. Alcuni errori sono gestiti automaticamente dal client, mentre altri sono notificati all utente umano, che può quindi decidere le azioni da intraprendere per risolvere l errore, se è possibile. Il funzionamento del server è organizzato e gestito basondolo sul concetto di sessione. Una sessione, in quanto tale, esiste sotto forma di istanza della classe ServerSession. Su un host su cui viene eseguito un server RTSP, possono esistere contemporaneamente più sessioni attive. Ogni sessione può gestire contemporaneamente vari flussi di dati multimediali. Le sessioni si distinguono in: aggregate, quando i vari media sono semanticamente correlati, quindi ogni richiesta proveniente da un client, deve riferlirli come un tutt uno (tranne nei SETUP), e quindi la loro gestione è demandata ad un unico porcesso RtspServer; non aggregate, quando i vari media non sono necessariamente correlati, quindi un client deve effettuare richieste separate per ogni media, e la gestione di ognuno di loro è affidata ad un processo RtspServer diverso. La necessità di usare un processo server per ogni media deriva dal funzionamento a stati dei server RTSP: quindi un media potrebbe essere in fase di riproduzione, mentre un altro potrebbe ancora essere nella fase di inizializzazione.

15 La classe SessionManager si occupa della gestione delle sessioni, mettendo a disposizione del processo server i seguenti servizi: crea una nuova sessione, quando un client la richiede; verifica se un client può essere inserito in una sessione esistente; risponde negativamente ad un client che cerca di inserirsi in una sessione gestita da un altro client, che non l abbia abbandonata disconnetendosi, oppure passandone espicitamente il controllo; gestisce l assegnazione delle porte per la creazione dei vari socket unicast e multicast, evitando conflitti tra i vari processi server; gestisce il database dei file contenenti i dati multimediali, mantenendo un indice nel file streamindex.dat dei vari media stream disponibili; genera automaticamente i file in formato SDP, per mantenere la descrizione delle nuove sessioni registrate; gestisce la chiusura delle sessioni, causate da problemi di connessione su rete, oppure per errori interni; utilizza un file (server.prop) personalizzabile, utile per inizializzare le proprietà dei server RTSP, (path, timeout, maxsessionnumber, ecc.). gestisce gli accessi concorrenti dei vari processi server al file streamindex.dat, tramite un monitor basato sull algotitmo lettori-scrittori implementato nella classe IndexFileManager, in cui si dà maggiore priorità ai processi scrittori, per rendere disponibili le modifiche dell elenco delle sessioni il più presto possibile. Quando sull host server non esiste nessun oggetto RtspServer attivo, resta in esecuzione un thread demon (processo demone), istanza della classe RtspDemon, il quale attende su un ServerSocket, alla porta 554, le connessioni provenienti dai client. Nel momento in cui un client apre una connessione TCP con questo demon, esso crea una istanza della classe RtspServer, anch essa un thread, passandogli il socket TCP con cui comunicare col client, e ne fa partire l esecuzione. Quindi il demon ritorna in attesa di altri client sul suo socket. Il server inizialmente è nello stato di Init, in cui può accettare solo tre tipi di richieste: DESCRIBE, ANNOUNCE e SETUP. DESCRIBE Il client usa questo metodo per ottenere una descrizione completa della risorsa, identificata tramite l URL nella richiesta. In genere il client richiede un DESCRIBE per poter inizializzare il playback di una sessione. Nella decrizione il server include tutte le informazioni necessarie per permettere al client di ricevere i flussi dei media componenti la presentazione o sessione multimediale. Il client indica nella richiesta, tramite l header Accept, il tipo di descrizione che riesce ad interpretare. Questa implementazione utilizza il protocollo SDP per descrivere le sessioni. Se l header Accept non contiene un formato di cui il server dispone, esso risponde con un messaggio contenente il codice d errore 451 (Parameter Not Understood). Il server ricerca nel suo file system il file contente la descrizione nel formato SDP. Questi file hanno il nome formato dal prefisso SDP-, a cui segue il nome della sessione. Se la sessione è disponibile, il server individua il file contenente la descrizione in formato SDP, quindi con il contenuto costruisce il corpo della risposta al DESCRIBE. Se il sever non trova il file SDP-<nome sessione>, risponde con un messaggio contenente il codice di errore 404 (Not Found).

16 Un esempio di DESCRIBE e relativa risposta è: C->S: DESCRIBE rtsp://lis3.deis.unical.it/lecture4/part1 RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg S->C: RTSP/ OK CSeq: 312 Date: 7 Nov :35:06 GMT Content-Type: application/sdp Content-Length: 376 v=0 o=vincenzo.c IN IP s=sdp Seminar i=lecture on Java Concurrency u=http://www.telsa.it/~v.ciminelli (Vincenzo Ciminelli) c=in IP /127 t= m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 Se nell URL del DESCRIBE il nome di sessione è costituito da un *, [es.: DESCRIBE rtsp://lis3.deis.unical.it/* RTSP/1.0] il server risponderà inviando nel corpo della risposta l elenco di tutte le sessioni di cui dispone. Questo elenco è ricavato dal file streamindex.dat contenente la lista di tutti i media stream disponibili sul server, oltre ad ulteriori informazioni su ogni stream. Questo è implementato tramite il metodo DescribeAll invocato dal metodo Describe stesso. Da questo elenco il client sceglie la sessione che desidera, di cui può quindi richiedere il DESCRIBE specifico. ANNOUNCE Il client usa questo metodo quando vuole registrare sul server una nuova sessione, per informarlo di tutti i dettagli riguardanti la sessione, necessari per eseguirne con successo la registrazione. Il corpo dell ANNOUNCE contiene la descrizione in formato SDP, come nel caso del DESCRIBE. Se il client invia un formato di descrizione diverso, il server risponderà con un messaggio contenente il codice di errore 406 (Not Acceptable). Se tutto va a buon fine, il server conserverà la descrizione della sessione in una variabile opportuna, che userà per le operazioni successive.

17 C->S: ANNOUNCE rtsp://lis3.deis.unical.it/lecture4/part2 RTSP/1.0 CSeq: 312 Date: 8 Jan :35:06 GMT Session: Content-Type: application/sdp Content-Length: 376 v=0 o=vincenzo.c IN IP s=sdp Seminar i=lecture on Java Threads u=http://www.telsa.it/~v.ciminelli (Vincenzo Ciminelli) c=in IP /127 t= m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 S->C: RTSP/ OK CSeq: 312 Un esempio di ANNOUNCE è: SETUP Il client, dopo aver ottenuto la descrizione di una sessione con un DESCRIBE, oppure averla fornita al server con un ANNOUNCE, deve inviare una richiesta di SETUP per ogni media stream compreso nella sessione di cui vuole fare il playback o il recording. Il server può funzionare nei seguenti modi: 1. riproduzione di una sessione in unicast verso il client; 2. riproduzione di una sessione verso un gruppo multicast; 3. registrazione di una sessione inviata dal client in unicast; 4. registrazione di una sessione da un gruppo multicast; 5. tunnelling di una sessione da un gruppo multicast verso un client capace di comunicare solo in unicast. Tramite un SETUP il client comunica al server le informazioni necessarie per inizializzare le connessioni su cui verranno inviati i pacchetti contenenti i dati, ed il tipo di funzionamento desiderato tra quelli appena elencati. L header principale utilizzato nel SETUP è il Transport- Header, tramite il quale il client comunica al server le seguenti informazioni: tipo di protocollo di trasporto dati multimediali (es. RTP); tipo di trasporto (TCP, UDP, ecc.); tipo di sessione: unicast, multicast; indirizzo del gruppo multicast a cui il server deve trasmettere o da cui deve ricevere i dati; le porte su cui il client attende i dati (unicast), oppure le porte del gruppo multicast su cui il server deve trasmettere o da cui deve ricevere i dati; il tipo di sessione (PLAY o RECORD). Ricevuto un SETUP, il server comincerà col verificare la presenza di un Transport-Header: se manca risponde con un codice di errore 400 ( Bad Request ). Quindi stabilisce il tipo di sessione richiesta: PLAY o RECORD. Se il client richiede il RECORD di uno stream esistente nel file system del server, questo accetta se il RECORD deve essere fatto appendendo in coda al file i nuovi

18 dati, rifiuta con un codice di errore 406 ( Not Acceptable ) se il client richiede la sovrascrittura del file. Se la richiesta è un PLAY, il server verifica se dispone del file contenente il media stream richiesto. Se così non è, risponde con un codice di errore 404 ( File Not Found ). Dopo queste verifiche, il server controlla la presenza di un header Session, con cui il client può indicare una sessione già attiva sull host del server. Se il SETUP contiene questo header, il server cerca di inserire la gestione di questo stream nella sessione richiesta dal client, se ciò non è possibile risponde con un codice di errore 454 ( Session Not Found ). Se il SETUP non contiene un header Session il client vuole inizializzare una nuova sessione, quindi il server la crea, generando un session ID, che inserisce in un header Session nella risposta : da questo momento il client deve usare sempre un header Session con questo session ID in tutte le richieste successive rivolte a questa sessione, altrimenti il server, non riconoscendo la sessione, risponderà con un codice di errore 454. Dopo queste verifiche preliminari, il server interpreta il contenuto del Transport Header, nel metodo gettransportheader, in cui il server riconosce il tipo di funzionamento richiesto dal client, e quindi prepara le informazioni necessarie da passare al sottosistema che si occupa del trattamento dei dati multimediali 4. Nella tabella è riassunta la semantica adottata per questa operazione: O. U. D. U. O. M. D. M. O. U. D. M. O. M. D. U. Sessione di PLAY Sessione di RECORD Playback dal server al client Recording dal client al server Non definito (errore 406) Non definito (errore 406) Playback dal server al gruppo Multicast. Non definito (errore 406) Tunnelling dal gruppo Multicast al Client. Tunnelling(1) con Recording dal gruppo Multicast sul server O.=Origine; D.=Destinazione; U.=Unicast; M.=Multicast (1) Il tunnelling viene attivato se la destinazione corrisponde all indirizzo del client. L origine e la destinazione sono i due parametri Source e Destination del Transport Header, contenenti gli indirizzi multicast del gruppo da cui provengono o a cui devono essere trasmessi i dati dei media stream. La presenza contemporanea di questi due parametri non è supportata, e provoca una risposta del server contenente il codice di errore 406 ( Not Acceptable; Incoherent Transport Header ). Quando l origine o la destinazione non sono indicati, il server assume i valori predefiniti: 4 Questo sottosistema è descritto nel capitolo 5.

19 Sessione di PLAY Sessione di RECORD Origine predefinita Indirizzo del Server Indirizzo del Client Destinazione Predefinita Indirizzo del Client Indirizzo del Server Ovviamente il client deve indicare le porte relative all indirizzo su cui egli deve trasmettere i media stream, o da cui li deve ricevere. Le informazioni sulle porte possono essere ricavate dall SDP se si tratta di una sessione multicast, ma il client, se vuole, le può modificare e comunicarle al server proprio nel Transport Header. La tabella seguente riporta, per i vari modi di funzionamento, i parametri di porta scambiati tra client e server: O.U. D.U. O.M. D.M. O.U. D.M. O.M. D.U. Sessione di PLAY Client-port Server-port Non definito (errore 406) Multicast Port Client-port Server-port Multicast port Sessione di RECORD Client-port Server-port Non definito (errore 406) Non definito (errore 406) Multicast port Client Port(1) O.=Origine; D.=Destinazione; U.=Unicast; M.=Multicast (1) Specificata in caso di tunnelling La Multicast port corrisponde al parametro port del Transport Header. In una sessione unicast, se il server rileva che sul suo host le porte specificate dal client generano conflitti, inizia con questo una contrattazione, proponendo nella risposta al client un nuovo set di porte che non generano conflitti: se il client le accetta, le operazioni proseguono, altrimenti quest ultimo può proporne delle altre in un nuovo SETUP. La contrattazione prosegue fino a quando i due non raggiungono un accordo. Tutta la contrattazione è trasparente all utente. Quando il server ed il client dispongono di tutti i parametri, il primo crea il processo che si occupa della trasmissione o della registrazione dei flussi multimediali, il secondo crea i processi che si occuperanno del rendering dei flussi multimediali (VIC per il video e VAT per l audio), per l utente.

20 Un esempio di SETUP è: C->S: SETUP rtsp://lis3.deis.unical.it/lecture1/video RTSP/1.0 CSeq: 302 Transport: RTP/AVP;unicast;client_port= S->C: RTSP/ OK CSeq: 302 Date: 23 Jan :35:06 GMT Session: Transport: RTP/AVP;unicast;client_port= Alla fine di un SETUP che ha avuto successo, il server ed il client cambieranno il loro stato, da Init a Ready. In questo stato il server attende le richieste del client che possono essere: PLAY (per una sessione di playing), RECORD (per una sessione di recording), TEARDOWN. PLAY Il client invia una richiesta di questo tipo quando vuole che il server cominci ad inviare i flussi multimediali, secondo le specifiche di inizializzazione impostate nel SETUP. Se la sessione è di tipo aggregato, il client deve inviare un solo PLAY per richiedere la trasmissione di tutti i media stream che la compongono. Quindi l URL della richiesta di PLAY deve contenere nel path solo il riferimento al nome della sessione, altrimenti il server risponde con un codice di errore 460 ("Only Aggregate Operation Allowed"). Se la sessione è di tipo non aggregato, il client deve invece inviare un messaggio di PLAY per ogni media stream che la compone. In tal caso l URL di ogni PLAY deve contenere nel path il riferimento ad uno specifico media stream, altrimenti il server risponde con un codice di errore 459 ("Aggregate Operation Not Allowed"). Il server effettua questi controlli anche per tutti i metodi successivi. Se si tratta del primo PLAY di una sessione, il server inizia la riproduzione dei media dall inizio; se invece si tratta di un PLAY seguente un messaggio di PAUSE, il server riprende la riproduzione dal punto in cui era stata sospesa. Se la sessione è di tipo aggregato, è disponibile la funzione di accesso casuale (seeking) all interno dei media stream: il client può richiedere di far ripartire la riproduzione da un istante qualsiasi, indicandolo con un header Range nel messaggio di PLAY. Siccome i dati multimediali digitalizzati sono discreti per la loro stessa natura, il server eseguirà il riposizionamento della riproduzione all istante di tempo all interno degli stream, che più approssima quello richiesto. Informa il client dell esatto istante da cui ripartirà la riproduzione, indicandolo in un header Range inserito nella risposta al PLAY. Un esempio di questo tipo di richiesta è: C->S: PLAY rtsp://lis3.deis.unical.it/lecture1/video RTSP/1.0 CSeq: 835 Session: Range: npt=9.6- S->C: RTSP/ OK CSeq: 835 Date: 7 Nov :35:06 GMT Range: npt=10-

Protocollo HTTP. Alessandro Sorato

Protocollo HTTP. Alessandro Sorato Un protocollo è un insieme di regole che permettono di trovare uno standard di comunicazione tra diversi computer attraverso la rete. Quando due o più computer comunicano tra di loro si scambiano una serie

Dettagli

Interfaccia Web per customizzare l interfaccia dei terminali e

Interfaccia Web per customizzare l interfaccia dei terminali e SIP - Session Initiation Protocol Il protocollo SIP (RFC 2543) è un protocollo di segnalazione e controllo in architettura peer-to-peer che opera al livello delle applicazioni e quindi sviluppato per stabilire

Dettagli

12.5 UDP (User Datagram Protocol)

12.5 UDP (User Datagram Protocol) CAPITOLO 12. SUITE DI PROTOCOLLI TCP/IP 88 12.5 UDP (User Datagram Protocol) L UDP (User Datagram Protocol) é uno dei due protocolli del livello di trasporto. Come l IP, é un protocollo inaffidabile, che

Dettagli

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone

Mod. 4: L architettura TCP/ IP Classe 5 I ITIS G. Ferraris a.s. 2011 / 2012 Marcianise (CE) Prof. M. Simone Paragrafo 1 Prerequisiti Definizione di applicazione server Essa è un servizio che è in esecuzione su un server 1 al fine di essere disponibile per tutti gli host che lo richiedono. Esempi sono: il servizio

Dettagli

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client

Luca Mari, Sistemi informativi applicati (reti di calcolatori) appunti delle lezioni. Architetture client/server: applicazioni client Versione 25.4.05 Sistemi informativi applicati (reti di calcolatori): appunti delle lezioni Architetture client/server: applicazioni client 1 Architetture client/server: un esempio World wide web è un

Dettagli

Routing (instradamento) in Internet. Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi:

Routing (instradamento) in Internet. Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi: Routing (instradamento) in Internet Internet globalmente consiste di Sistemi Autonomi (AS) interconnessi: Stub AS: istituzione piccola Multihomed AS: grande istituzione (nessun ( transito Transit AS: provider

Dettagli

Introduzione alle applicazioni di rete

Introduzione alle applicazioni di rete Introduzione alle applicazioni di rete Definizioni base Modelli client-server e peer-to-peer Socket API Scelta del tipo di servizio Indirizzamento dei processi Identificazione di un servizio Concorrenza

Dettagli

CARATTERISTICHE DELLE CRYPTO BOX

CARATTERISTICHE DELLE CRYPTO BOX Secure Stream PANORAMICA Il sistema Secure Stream è costituito da due appliance (Crypto BOX) in grado di stabilire tra loro un collegamento sicuro. Le Crypto BOX sono dei veri e propri router in grado

Dettagli

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN)

Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) Estensione di un servizo di messaggistica per telefonia mobile (per una società di agenti TuCSoN) System Overview di Mattia Bargellini 1 CAPITOLO 1 1.1 Introduzione Il seguente progetto intende estendere

Dettagli

PRESENTAZIONE DI UN SMS AL GATEWAY

PRESENTAZIONE DI UN SMS AL GATEWAY Interfaccia Full Ascii Con questa interfaccia è possibile inviare i dati al Server utilizzando solo caratteri Ascii rappresentabili e solo i valori che cambiano tra un sms e l altro, mantenendo la connessione

Dettagli

Le Reti Informatiche

Le Reti Informatiche Le Reti Informatiche modulo 10 Prof. Salvatore Rosta www.byteman.it s.rosta@byteman.it 1 Nomenclatura: 1 La rappresentazione di uno schema richiede una serie di abbreviazioni per i vari componenti. Seguiremo

Dettagli

Modulo 11. Il livello trasporto ed il protocollo TCP Indice

Modulo 11. Il livello trasporto ed il protocollo TCP Indice Pagina 1 di 14 Il livello trasporto ed il protocollo TCP Indice servizi del livello trasporto multiplexing/demultiplexing trasporto senza connesione: UDP principi del trasferimento dati affidabile trasporto

Dettagli

ARP (Address Resolution Protocol)

ARP (Address Resolution Protocol) ARP (Address Resolution Protocol) Il routing Indirizzo IP della stazione mittente conosce: - il proprio indirizzo (IP e MAC) - la netmask (cioè la subnet) - l indirizzo IP del default gateway, il router

Dettagli

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless

La configurazione degli indirizzi IP. Configurazione statica, con DHCP, e stateless La configurazione degli indirizzi IP Configurazione statica, con DHCP, e stateless 1 Parametri essenziali per una stazione IP Parametri obbligatori Indirizzo IP Netmask Parametri formalmente non obbligatori,

Dettagli

Cos è un protocollo? Ciao. Ciao 2:00. tempo. Un protocollo umano e un protocollo di reti di computer:

Cos è un protocollo? Ciao. Ciao 2:00. <file> tempo. Un protocollo umano e un protocollo di reti di computer: Cos è un protocollo? Un protocollo umano e un protocollo di reti di computer: Ciao Ciao Hai l ora? 2:00 tempo TCP connection request TCP connection reply. Get http://www.di.unito.it/index.htm Domanda:

Dettagli

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30

Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 Prova di Esame - Rete Internet (ing. Giovanni Neglia) Prova completa Mercoledì 2 Marzo 2005, ore 14.30 NB: alcune domande hanno risposta multipla: si richiede di identificare TUTTE le risposte corrette.

Dettagli

Inizializzazione degli Host. BOOTP e DHCP

Inizializzazione degli Host. BOOTP e DHCP BOOTP e DHCP a.a. 2002/03 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/~auletta/ Università degli studi di Salerno Laurea e Diploma in Informatica 1 Inizializzazione degli Host Un

Dettagli

GLI ERRORI DI OUTLOOK EXPRESS

GLI ERRORI DI OUTLOOK EXPRESS Page 1 of 6 GLI ERRORI DI OUTLOOK EXPRESS 1) Impossibile inviare il messaggio. Uno dei destinatari non è stato accettato dal server. L'indirizzo di posta elettronica non accettato è "user@dominio altro

Dettagli

IL LIVELLO APPLICAZIONI DNS, SNMP e SMTP

IL LIVELLO APPLICAZIONI DNS, SNMP e SMTP Reti di Calcolatori IL LIVELLO APPLICAZIONI DNS, SNMP e SMTP D. Talia RETI DI CALCOLATORI - UNICAL 6-1 Applicazioni di Rete Domain Name System (DNS) Simple Network Manag. Protocol (SNMP) Posta elettronica

Dettagli

Analisi dei requisiti e casi d uso

Analisi dei requisiti e casi d uso Analisi dei requisiti e casi d uso Indice 1 Introduzione 2 1.1 Terminologia........................... 2 2 Modello della Web Application 5 3 Struttura della web Application 6 4 Casi di utilizzo della Web

Dettagli

Inidirizzi IP e Nomi di Dominio. Domain Name System. Spazio dei Nomi Piatto. Gestione dello Spazio dei Nomi

Inidirizzi IP e Nomi di Dominio. Domain Name System. Spazio dei Nomi Piatto. Gestione dello Spazio dei Nomi I semestre 03/04 Inidirizzi IP e Nomi di Dominio Domain Name System Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ Università degli studi di Salerno Laurea in Informatica

Dettagli

Ultimo aggiornamento sett13

Ultimo aggiornamento sett13 Ultimo aggiornamento sett13 INDICE 1. Invio singolo SMS tramite richiesta POST/GET HTTP...3 1.1 - Messaggi singoli concatenati...4 2. Invio multiplo SMS tramite richiesta POST/GET HTTP...4 2.1 - Messaggi

Dettagli

Elementi di Informatica e Programmazione

Elementi di Informatica e Programmazione Elementi di Informatica e Programmazione Le Reti di Calcolatori (parte 2) Corsi di Laurea in: Ingegneria Civile Ingegneria per l Ambiente e il Territorio Università degli Studi di Brescia Docente: Daniela

Dettagli

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+...

J+... J+3 J+2 J+1 K+1 K+2 K+3 K+... Setup delle ConnessioniTCP Una connessione TCP viene instaurata con le seguenti fasi, che formano il Three-Way Handshake (perchè formato da almeno 3 pacchetti trasmessi): 1) il server si predispone ad

Dettagli

Reti di Telecomunicazione Lezione 7

Reti di Telecomunicazione Lezione 7 Reti di Telecomunicazione Lezione 7 Marco Benini Corso di Laurea in Informatica marco.benini@uninsubria.it Il protocollo Programma della lezione file transfer protocol descrizione architetturale descrizione

Dettagli

Modello OSI e architettura TCP/IP

Modello OSI e architettura TCP/IP Modello OSI e architettura TCP/IP Differenza tra modello e architettura - Modello: è puramente teorico, definisce relazioni e caratteristiche dei livelli ma non i protocolli effettivi - Architettura: è

Dettagli

Guida all'installazione ed uso dell'app RXCamLink

Guida all'installazione ed uso dell'app RXCamLink Guida all'installazione ed uso dell'app RXCamLink Questa guida riporta i passi relativi all'installazione ed all'utilizzo dell'app "RxCamLink" per il collegamento remoto in mobilità a sistemi TVCC basati

Dettagli

Guida. Vista Live. Controllo. Riproduzione su 24 ore. Ricerca avanz. Le icone includono: Mod. uscita. Icona. Un sensore di allarme.

Guida. Vista Live. Controllo. Riproduzione su 24 ore. Ricerca avanz. Le icone includono: Mod. uscita. Icona. Un sensore di allarme. Guida operatore del registratore TruVision Vista Live Sull immagine live dello schermo vengono visualizzati laa data e l ora corrente, il nome della telecamera e viene indicato se è in corso la registrazione.

Dettagli

Outlook Express 6 Microsoft Internet Explorer, Avvio del programma Creare un nuovo account

Outlook Express 6 Microsoft Internet Explorer, Avvio del programma Creare un nuovo account Outlook Express 6 è un programma, incluso nel browser di Microsoft Internet Explorer, che ci permette di inviare e ricevere messaggi di posta elettronica. È gratuito, semplice da utilizzare e fornisce

Dettagli

ATA MEDIATRIX 2102 GUIDA ALL INSTALLAZIONE

ATA MEDIATRIX 2102 GUIDA ALL INSTALLAZIONE ATA MEDIATRIX 2102 GUIDA ALL INSTALLAZIONE Mediatrix 2102 ATA Guida all installazione EUTELIAVOIP Rev1-0 pag.2 INDICE SERVIZIO EUTELIAVOIP...3 COMPONENTI PRESENTI NELLA SCATOLA DEL MEDIATRIX 2102...3 COLLEGAMENTO

Dettagli

Funzioni nuove e modificate

Funzioni nuove e modificate Gigaset S675 IP, S685 IP, C470 IP, C475 IP: Funzioni nuove e modificate Questo documento integra il manuale di istruzioni dei telefoni VoIP Gigaset: Gigaset C470 IP, Gigaset C475 IP, Gigaset S675 IP e

Dettagli

GUIDA RAPIDA emagister-agora Edizione BASIC

GUIDA RAPIDA emagister-agora Edizione BASIC GUIDA RAPIDA emagister-agora Edizione BASIC Introduzione a emagister-agora Interfaccia di emagister-agora Configurazione dell offerta didattica Richieste d informazioni Gestione delle richieste d informazioni

Dettagli

Lezione n 1! Introduzione"

Lezione n 1! Introduzione Lezione n 1! Introduzione" Corso sui linguaggi del web" Fondamentali del web" Fondamentali di una gestione FTP" Nomenclatura di base del linguaggio del web" Come funziona la rete internet?" Connessione"

Dettagli

Manuale di Remote Desktop Connection. Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci

Manuale di Remote Desktop Connection. Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci Manuale di Remote Desktop Connection Brad Hards Urs Wolfer Traduzione: Luciano Montanaro Traduzione: Daniele Micci 2 Indice 1 Introduzione 5 2 Il protocollo Remote Frame Buffer 6 3 Uso di Remote Desktop

Dettagli

I name server DNS. DNS: Domain Name System. Esempio di DNS. DNS: Root name server. DNS: queries ripetute

I name server DNS. DNS: Domain Name System. Esempio di DNS. DNS: Root name server. DNS: queries ripetute DNS: Domain Name System I name DNS Persone: identificatori: CF, nome, Numero di Passaporto Host e router Internet: Indirizzo IP ( bit) - usato per instradare i pacchetti nome, per es., massimotto.diiie.unisa.it

Dettagli

Informatica per la comunicazione" - lezione 9 -

Informatica per la comunicazione - lezione 9 - Informatica per la comunicazione" - lezione 9 - Protocolli di livello intermedio:" TCP/IP" IP: Internet Protocol" E il protocollo che viene seguito per trasmettere un pacchetto da un host a un altro, in

Dettagli

Voice Over IP NAT Traversal

Voice Over IP NAT Traversal Voice Over IP Traversal Giorgio Zoppi zoppi@cli.di.unipi.it Tecnologie di Convergenza su IP a.a.2005/2006 VoIP Traversal 1 57 Tecnologie di Convergenza su IP Che cosa è il (Network Address Translation?

Dettagli

DNS (Domain Name System) Gruppo Linux

DNS (Domain Name System) Gruppo Linux DNS (Domain Name System) Gruppo Linux Luca Sozio Matteo Giordano Vincenzo Sgaramella Enrico Palmerini DNS (Domain Name System) Ci sono due modi per identificare un host nella rete: - Attraverso un hostname

Dettagli

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO

SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO CLSMS SOFTWARE GESTIONE SMS DA INTERFACCE CL MANUALE D INSTALLAZIONE ED USO Sommario e introduzione CLSMS SOMMARIO INSTALLAZIONE E CONFIGURAZIONE... 3 Parametri di configurazione... 4 Attivazione Software...

Dettagli

Trasmissione Seriale e Parallela. Interfacce di Comunicazione. Esempio di Decodifica del Segnale. Ricezione e Decodifica. Prof.

Trasmissione Seriale e Parallela. Interfacce di Comunicazione. Esempio di Decodifica del Segnale. Ricezione e Decodifica. Prof. Interfacce di Comunicazione Università degli studi di Salerno Laurea in Informatica I semestre 03/04 Prof. Vincenzo Auletta auletta@dia.unisa.it http://www.dia.unisa.it/professori/auletta/ 2 Trasmissione

Dettagli

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese

Inter Process Communication. Laboratorio Software 2008-2009 C. Brandolese Inter Process Communication Laboratorio Software 2008-2009 C. Brandolese Introduzione Più processi o thread Concorrono alla relaizzazione di una funzione applicativa Devono poter realizzare Sincronizzazione

Dettagli

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE

RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE RETI DI CALCOLATORI E APPLICAZIONI TELEMATICHE Prof. PIER LUCA MONTESSORO Facoltà di Ingegneria Università degli Studi di Udine 1999 Pier Luca Montessoro (si veda la nota a pagina 2) 1 Nota di Copyright

Dettagli

WAN 80.80.80.80 / 24. L obiettivo è quello di mappare due server web interni (porta 80) associandoli agli indirizzi IP Pubblici forniti dall ISP.

WAN 80.80.80.80 / 24. L obiettivo è quello di mappare due server web interni (porta 80) associandoli agli indirizzi IP Pubblici forniti dall ISP. Configurazione di indirizzi IP statici multipli Per mappare gli indirizzi IP pubblici, associandoli a Server interni, è possibile sfruttare due differenti metodi: 1. uso della funzione di Address Translation

Dettagli

MANUALE UTENTE DEL SOFTWARE DI GESTIONE DEGLI ART. SDVR040A/SDVR080A/SDVR160A

MANUALE UTENTE DEL SOFTWARE DI GESTIONE DEGLI ART. SDVR040A/SDVR080A/SDVR160A MANUALE UTENTE DEL SOFTWARE DI GESTIONE DEGLI ART. SDVR040A/SDVR080A/SDVR160A Leggere attentamente questo manuale prima dell utilizzo e conservarlo per consultazioni future Via Don Arrigoni, 5 24020 Rovetta

Dettagli

Gestione Email Gruppo RAS Carrozzerie Convenzionate

Gestione Email Gruppo RAS Carrozzerie Convenzionate Email Ras - CARROZZIERI Pag. 1 di 17 Gestione Email Gruppo RAS Carrozzerie Convenzionate Notizie Generali Email Ras - CARROZZIERI Pag. 2 di 17 1.1 Protocollo Gruppo RAS Questo opuscolo e riferito al Protocollo

Dettagli

Introduzione ai protocolli di rete Il protocollo NetBEUI Il protocollo AppleTalk Il protocollo DLC Il protocollo NWLink Il protocollo TCP/IP

Introduzione ai protocolli di rete Il protocollo NetBEUI Il protocollo AppleTalk Il protocollo DLC Il protocollo NWLink Il protocollo TCP/IP Protocolli di rete Sommario Introduzione ai protocolli di rete Il protocollo NetBEUI Il protocollo AppleTalk Il protocollo DLC Il protocollo NWLink Il protocollo TCP/IP Configurazione statica e dinamica

Dettagli

Web Conferencing and Collaboration tool

Web Conferencing and Collaboration tool Web Conferencing and Collaboration tool La piattaforma Meetecho Piattaforma di Web Conferencing e Collaborazione on line in tempo reale Caratteristiche generali Soluzione client-server progettata per essere

Dettagli

Livello applicazione: Protocollo DNS

Livello applicazione: Protocollo DNS Livello applicazione: Protocollo DNS Gaia Maselli Queste slide sono un adattamento delle slide fornite dal libro di testo e pertanto protette da copyright. All material copyright 1996-2007 J.F Kurose and

Dettagli

FileMaker Server 12. Guida introduttiva

FileMaker Server 12. Guida introduttiva FileMaker Server 12 Guida introduttiva 2007 2012 FileMaker, Inc. Tutti i diritti riservati. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054 FileMaker e Bento sono marchi di FileMaker,

Dettagli

Sistemi avanzati di gestione dei Sistemi Informativi

Sistemi avanzati di gestione dei Sistemi Informativi Esperti nella gestione dei sistemi informativi e tecnologie informatiche Sistemi avanzati di gestione dei Sistemi Informativi Docente: Email: Sito: Eduard Roccatello eduard@roccatello.it http://www.roccatello.it/teaching/gsi/

Dettagli

Livello di applicazione. Reti di Calcolatori. Corso di Laurea in Ingegneria Informatica. Livello di applicazione DNS A.A.

Livello di applicazione. Reti di Calcolatori. Corso di Laurea in Ingegneria Informatica. Livello di applicazione DNS A.A. Corso di Laurea in Ingegneria Informatica Reti di Calcolatori Livello di applicazione DNS A.A. 2013/2014 1 Livello di applicazione Web e HTTP FTP Posta elettronica SMTP, POP3, IMAP DNS Applicazioni P2P

Dettagli

Energy Studio Manager Manuale Utente USO DEL SOFTWARE

Energy Studio Manager Manuale Utente USO DEL SOFTWARE Energy Studio Manager Manuale Utente USO DEL SOFTWARE 1 ANALYSIS.EXE IL PROGRAMMA: Una volta aperto il programma e visualizzato uno strumento il programma apparirà come nell esempio seguente: Il programma

Dettagli

Zeroshell come client OpenVPN

Zeroshell come client OpenVPN Zeroshell come client OpenVPN (di un server OpenVpn Linux) Le funzionalità di stabilire connessioni VPN di Zeroshell vede come scenario solito Zeroshell sia come client sia come server e per scelta architetturale,

Dettagli

Manuale Software. www.smsend.it

Manuale Software. www.smsend.it Manuale Software www.smsend.it 1 INTRODUZIONE 3 Multilanguage 4 PANNELLO DI CONTROLLO 5 Start page 6 Profilo 7 Ordini 8 Acquista Ricarica 9 Coupon AdWords 10 Pec e Domini 11 MESSAGGI 12 Invio singolo sms

Dettagli

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP

MIB PER IL CONTROLLO DELLO STATO DI UN SERVER FTP Università degli Studi di Pisa Facoltà di Scienze Matematiche,Fisiche e Naturali Corso di Laurea in Informatica Michela Chiucini MIB PER IL CONTROLLO DELLO STATO DI UN SERVER

Dettagli

Import Dati Release 4.0

Import Dati Release 4.0 Piattaforma Applicativa Gestionale Import Dati Release 4.0 COPYRIGHT 2000-2005 by ZUCCHETTI S.p.A. Tutti i diritti sono riservati.questa pubblicazione contiene informazioni protette da copyright. Nessuna

Dettagli

Introduzione a MySQL

Introduzione a MySQL Introduzione a MySQL Cinzia Cappiello Alessandro Raffio Politecnico di Milano Prima di iniziare qualche dettaglio su MySQL MySQL è un sistema di gestione di basi di dati relazionali (RDBMS) composto da

Dettagli

CONFIGURAZIONE DEI SERVIZI (seconda parte)

CONFIGURAZIONE DEI SERVIZI (seconda parte) Corso ForTIC C2 LEZIONE n. 10 CONFIGURAZIONE DEI SERVIZI (seconda parte) WEB SERVER PROXY FIREWALL Strumenti di controllo della rete I contenuti di questo documento, salvo diversa indicazione, sono rilasciati

Dettagli

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it

UML: Class Diagram. Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it UML: Class Diagram Ing. Orazio Tomarchio Orazio.Tomarchio@diit.unict.it Dipartimento di Ingegneria Informatica e delle Telecomunicazioni Università di Catania Class Diagram Forniscono una vista strutturale

Dettagli

DNS cache poisoning e Bind

DNS cache poisoning e Bind ICT Security n. 19, Gennaio 2004 p. 1 di 5 DNS cache poisoning e Bind Il Domain Name System è fondamentale per l'accesso a internet in quanto risolve i nomi degli host nei corrispondenti numeri IP. Se

Dettagli

Documentazione Servizio SMS WEB. Versione 1.0

Documentazione Servizio SMS WEB. Versione 1.0 Documentazione Servizio SMS WEB Versione 1.0 1 Contenuti 1 INTRODUZIONE...5 1.1 MULTILANGUAGE...5 2 MESSAGGI...7 2.1 MESSAGGI...7 2.1.1 INVIO SINGOLO SMS...7 2.1.2 INVIO MULTIPLO SMS...9 2.1.3 INVIO MMS

Dettagli

NetMonitor. Micro guida all uso per la versione 1.2.0 di NetMonitor

NetMonitor. Micro guida all uso per la versione 1.2.0 di NetMonitor NetMonitor Micro guida all uso per la versione 1.2.0 di NetMonitor Cos è NetMonitor? NetMonitor è un piccolo software per il monitoraggio dei dispositivi in rete. Permette di avere una panoramica sui dispositivi

Dettagli

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho

Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Web conferencing e collaborazione in tempo reale su Internet: la piattaforma Meetecho Tobia Castaldi Alessandro Amirante Lorenzo Miniero Simon Pietro Romano Giorgio Ventre 02/10/2009 GARR 2009 "Network

Dettagli

Descrizioni VHDL Behavioral

Descrizioni VHDL Behavioral 1 Descrizioni VHDL Behavioral In questo capitolo vedremo come la struttura di un sistema digitale è descritto in VHDL utilizzando descrizioni di tipo comportamentale. Outline: process wait statements,

Dettagli

Programmazione di rete in Java

Programmazione di rete in Java Programmazione di rete in Java Reti di calcolatori Una rete di calcolatori è un sistema che permette la condivisione di dati informativi e risorse (sia hardware sia software) tra diversi calcolatori. Lo

Dettagli

I file di dati. Unità didattica D1 1

I file di dati. Unità didattica D1 1 I file di dati Unità didattica D1 1 1) I file sequenziali Utili per la memorizzazione di informazioni testuali Si tratta di strutture organizzate per righe e non per record Non sono adatte per grandi quantità

Dettagli

CHIAVETTA INTERNET ONDA MT503HSA

CHIAVETTA INTERNET ONDA MT503HSA CHIAVETTA INTERNET ONDA MT503HSA Manuale Utente Linux Debian, Fedora, Ubuntu www.ondacommunication.com Chiavet ta Internet MT503HSA Guida rapida sistema operativo LINUX V 1.1 33080, Roveredo in Piano (PN)

Dettagli

Introduzione ad Access

Introduzione ad Access Introduzione ad Access Luca Bortolussi Dipartimento di Matematica e Informatica Università degli studi di Trieste Access E un programma di gestione di database (DBMS) Access offre: un supporto transazionale

Dettagli

Manuale d uso Apache OpenMeetings (Manuale Utente + Manuale Amministratore)

Manuale d uso Apache OpenMeetings (Manuale Utente + Manuale Amministratore) Manuale d uso Apache OpenMeetings (Manuale Utente + Manuale Amministratore) Autore: Matteo Veroni Email: matver87@gmail.com Sito web: matteoveroni@altervista.org Fonti consultate: http://openmeetings.apache.org/

Dettagli

Guida alla scansione su FTP

Guida alla scansione su FTP Guida alla scansione su FTP Per ottenere informazioni di base sulla rete e sulle funzionalità di rete avanzate della macchina Brother, consultare la uu Guida dell'utente in rete. Per ottenere informazioni

Dettagli

Il Concetto di Processo

Il Concetto di Processo Processi e Thread Il Concetto di Processo Il processo è un programma in esecuzione. È l unità di esecuzione all interno del S.O. Solitamente, l esecuzione di un processo è sequenziale (le istruzioni vengono

Dettagli

Il World Wide Web: nozioni introduttive

Il World Wide Web: nozioni introduttive Il World Wide Web: nozioni introduttive Dott. Nicole NOVIELLI novielli@di.uniba.it http://www.di.uniba.it/intint/people/nicole.html Cos è Internet! Acronimo di "interconnected networks" ("reti interconnesse")!

Dettagli

Alb@conference GO e Web Tools

Alb@conference GO e Web Tools Alb@conference GO e Web Tools Crea riunioni virtuali sempre più efficaci Strumenti Web di Alb@conference GO Guida Utente Avanzata Alb@conference GO Per partecipare ad un audioconferenza online con Alb@conference

Dettagli

Guida ai Servizi Voce per il Referente. Guida ai Servizi Voce per il Referente

Guida ai Servizi Voce per il Referente. Guida ai Servizi Voce per il Referente Guida ai Servizi Voce per il Referente Guida ai Servizi Voce per il Referente 1 Sommario 1 Introduzione... 3 1.1 Accesso al Self Care Web di Rete Unica... 4 2 Servizi Aziendali... 6 2.1 Centralino - Numero

Dettagli

Comandi filtro: sed. Se non si specificano azioni, sed stampa sullo standard output le linee in input, lasciandole inalterate.

Comandi filtro: sed. Se non si specificano azioni, sed stampa sullo standard output le linee in input, lasciandole inalterate. Comandi filtro: sed Il nome del comando sed sta per Stream EDitor e la sua funzione è quella di permettere di editare il testo passato da un comando ad un altro in una pipeline. Ciò è molto utile perché

Dettagli

Il modello client/server consente a due processi di condividere risorse e di cooperare per il raggiungimento di un obiettivo.

Il modello client/server consente a due processi di condividere risorse e di cooperare per il raggiungimento di un obiettivo. In una rete di ampie dimensioni, ciascuna sottorete (es. LAN, WAN) è connessa ad altre sottoreti tramite router. Internet è un insieme di reti connesse tra loro. Essenzialmente, in una rete alcune macchine

Dettagli

SPOSTAMENTO SITEMANAGER DA SERVER DIREL A SERVER PROPRIETARIO

SPOSTAMENTO SITEMANAGER DA SERVER DIREL A SERVER PROPRIETARIO SPOSTAMENTO SITEMANAGER DA SERVER DIREL A SERVER PROPRIETARIO La seguente guida mostra come trasferire un SiteManager presente nel Server Gateanager al Server Proprietario; assumiamo a titolo di esempio,

Dettagli

Web Conferencing Open Source

Web Conferencing Open Source Web Conferencing Open Source A cura di Giuseppe Maugeri g.maugeri@bembughi.org 1 Cos è BigBlueButton? Sistema di Web Conferencing Open Source Basato su più di quattordici componenti Open-Source. Fornisce

Dettagli

INTERNET e RETI di CALCOLATORI A.A. 2014/2015 Capitolo 4 DHCP Dynamic Host Configuration Protocol Fausto Marcantoni fausto.marcantoni@unicam.

INTERNET e RETI di CALCOLATORI A.A. 2014/2015 Capitolo 4 DHCP Dynamic Host Configuration Protocol Fausto Marcantoni fausto.marcantoni@unicam. Laurea in INFORMATICA INTERNET e RETI di CALCOLATORI A.A. 2014/2015 Capitolo 4 Dynamic Host Configuration Protocol fausto.marcantoni@unicam.it Prima di iniziare... Gli indirizzi IP privati possono essere

Dettagli

explorer 2 Manuale dell Installatore e Technical Reference Ver. 2.2.6 del 14 Dicembre 2012

explorer 2 Manuale dell Installatore e Technical Reference Ver. 2.2.6 del 14 Dicembre 2012 explorer 2 Manuale dell Installatore e Technical Reference Ver. 2.2.6 del 14 Dicembre 2012 1 Indice 1. Descrizione del sistema e Requisiti hardware e software per l installazione... 4 1.1 Descrizione del

Dettagli

Dati importati/esportati

Dati importati/esportati Dati importati/esportati Dati importati Al workspace MATLAB script Dati esportati file 1 File di testo (.txt) Spreadsheet Database Altro Elaborazione dati Grafici File di testo Relazioni Codice Database

Dettagli

Principali caratteristiche piattaforma web smsmobile.it

Principali caratteristiche piattaforma web smsmobile.it SmsMobile.it Principali caratteristiche piattaforma web smsmobile.it Istruzioni Backoffice Post get http VERSION 2.1 Smsmobile by Cinevision srl Via Paisiello 15/ a 70015 Noci ( Bari ) tel.080 497 30 66

Dettagli

Editor vi. Editor vi

Editor vi. Editor vi Editor vi vi 1 Editor vi Il vi è l editor di testo standard per UNIX, è presente in tutte le versioni base e funziona con qualsiasi terminale a caratteri Permette di visualizzare una schermata alla volta

Dettagli

Manipolazione di testi: espressioni regolari

Manipolazione di testi: espressioni regolari Manipolazione di testi: espressioni regolari Un meccanismo per specificare un pattern, che, di fatto, è la rappresentazione sintetica di un insieme (eventualmente infinito) di stringhe: il pattern viene

Dettagli

Test di comunicazione tra due LOGO! 0BA7: Master - Master

Test di comunicazione tra due LOGO! 0BA7: Master - Master Industry Test di comunicazione tra due LOGO! 0BA7: Master - Master Dispositivi utilizzati: - 2 LOGO! 0BA7 (6ED1 052-1MD00-0AB7) - Scalance X-208 LOGO! 0BA7 Client IP: 192.168.0.1 LOGO! 0BA7 Server IP:

Dettagli

MODBUS-RTU per. Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie. Expert NANO 2ZN

MODBUS-RTU per. Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie. Expert NANO 2ZN per Expert NANO 2ZN Specifiche protocollo di comunicazione MODBUS-RTU per controllo in rete dispositivi serie Expert NANO 2ZN Nome documento: MODBUS-RTU_NANO_2ZN_01-12_ITA Software installato: NANO_2ZN.hex

Dettagli

Architettura dei Calcolatori

Architettura dei Calcolatori Architettura dei Calcolatori Sistema di memoria parte prima Ing. dell Automazione A.A. 2011/12 Gabriele Cecchetti Sistema di memoria parte prima Sommario: Banco di registri Generalità sulla memoria Tecnologie

Dettagli

BPEL: Business Process Execution Language

BPEL: Business Process Execution Language Ingegneria dei processi aziendali BPEL: Business Process Execution Language Ghilardi Dario 753708 Manenti Andrea 755454 Docente: Prof. Ernesto Damiani BPEL - definizione Business Process Execution Language

Dettagli

Interfaccia HTTP enduser Specifiche tecniche 03.10.2013

Interfaccia HTTP enduser Specifiche tecniche 03.10.2013 i-contact srl via Simonetti 48 32100 Belluno info@i-contact.it tel. 0437 30419 fax 0437 1900 125 p.i./c.f. 0101939025 Interfaccia HTTP enduser Specifiche tecniche 03.10.2013 1. Introduzione Il seguente

Dettagli

Specifiche tecnico-funzionali per comunicazione e conservazione dati da parte dei Sistemi Controllo Accessi. INDICE

Specifiche tecnico-funzionali per comunicazione e conservazione dati da parte dei Sistemi Controllo Accessi. INDICE Specifiche tecnico-funzionali per comunicazione e conservazione dati da parte dei Sistemi Controllo Accessi. INDICE 1.1 CARATTERISTICHE DEL SUPPORTO IMMODIFICABILE E SUO FILE-SYSTEM... 2 1.2 SICUREZZA

Dettagli

Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata

Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica certificata Decreto 2 novembre 2005 Regole tecniche per la formazione, la trasmissione e la validazione, anche temporale, della posta elettronica IL MINISTRO PER L'INNOVAZIONE E LE TECNOLOGIE - Visto l articolo 17

Dettagli

SubnetMask: come funzionano e come si calcolano le sottoreti (SpySystem.it)

SubnetMask: come funzionano e come si calcolano le sottoreti (SpySystem.it) SubnetMask: come funzionano e come si calcolano le sottoreti (SpySystem.it) In una rete TCP/IP, se un computer (A) deve inoltrare una richiesta ad un altro computer (B) attraverso la rete locale, lo dovrà

Dettagli

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1

Configuration Managment Configurare EC2 su AWS. Tutorial. Configuration Managment. Configurare il servizio EC2 su AWS. Pagina 1 Tutorial Configuration Managment Configurare il servizio EC2 su AWS Pagina 1 Sommario 1. INTRODUZIONE... 3 2. PROGRAMMI NECESSARI... 4 3. PANNELLO DI CONTROLLO... 5 4. CONFIGURARE E LANCIARE UN ISTANZA...

Dettagli

Servizi DNS - SMTP FTP - TELNET. Programmi. Outlook Express Internet Explorer

Servizi DNS - SMTP FTP - TELNET. Programmi. Outlook Express Internet Explorer Servizi DNS - SMTP FTP - TELNET Programmi Outlook Express Internet Explorer 72 DNS Poiché riferirsi a una risorsa (sia essa un host oppure l'indirizzo di posta elettronica di un utente) utilizzando un

Dettagli

Approvazione delle modifiche al modello di versamento F24 enti pubblici ed alle relative specifiche tecniche Introduzione del secondo codice fiscale

Approvazione delle modifiche al modello di versamento F24 enti pubblici ed alle relative specifiche tecniche Introduzione del secondo codice fiscale Prot. n. 2012/140335 Approvazione delle modifiche al modello di versamento F24 enti pubblici ed alle relative specifiche tecniche Introduzione del secondo codice fiscale IL DIRETTORE DELL AGENZIA In base

Dettagli

Altre opzioni Optralmage

Altre opzioni Optralmage di Personalizzazione delle impostazioni............ 2 Impostazione manuale delle informazioni sul fax......... 5 Creazione di destinazioni fax permanenti................ 7 Modifica delle impostazioni di

Dettagli

Web conferencing software. Massimiliano Greco - Ivan Cerato - Mario Salvetti

Web conferencing software. Massimiliano Greco - Ivan Cerato - Mario Salvetti 1 Web conferencing software Massimiliano Greco - Ivan Cerato - Mario Salvetti Arpa Piemonte 2 Che cosa è Big Blue Button? Free, open source, web conferencing software Semplice ed immediato ( Just push

Dettagli

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software.

Firewall. Generalità. Un firewall può essere sia un apparato hardware sia un programma software. Generalità Definizione Un firewall è un sistema che protegge i computer connessi in rete da attacchi intenzionali mirati a compromettere il funzionamento del sistema, alterare i dati ivi memorizzati, accedere

Dettagli

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity

CORSO DI ALGORITMI E PROGRAMMAZIONE. JDBC Java DataBase Connectivity CORSO DI ALGORITMI E PROGRAMMAZIONE JDBC Java DataBase Connectivity Anno Accademico 2002-2003 Accesso remoto al DB Istruzioni SQL Rete DataBase Utente Host client Server di DataBase Host server Accesso

Dettagli

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it

SMS API. Documentazione Tecnica YouSMS SOAP API. YouSMS Evet Limited 2015 http://www.yousms.it SMS API Documentazione Tecnica YouSMS SOAP API YouSMS Evet Limited 2015 http://www.yousms.it INDICE DEI CONTENUTI Introduzione... 2 Autenticazione & Sicurezza... 2 Username e Password... 2 Connessione

Dettagli