| CATEGORII DOCUMENTE |
APLICATII - RETELE
1. Aplicatii traditionale
- Accesarea terminalelor TELNET
- Transferul fisierelor FTP
- Posta electronica SMPT si MIME
2. Aplicatii moderne
- Accesarea Web HTTP
- Serviciul de ghidare prin internet DNS
- Transmiterea vocii prin internet si suport multimedia SIP
- Socket-uri
TELNET - Accesarea terminalelor
Este cea mai veche aplicatie Internet, folosita de ARPANET/1969
-Telnet e o facilitate de conectare la distanta (remote logon)
bazata pe un protocol de terminal virtual si un terminal virtual de retea. In esenta, pentru transferul datelor sunt translatate caracteristicile terminalului real intr-un terminal virtual de retea.
-Telnet defineste o procedura de negociere care permite utilizatorului si serverului sa stabileasca optiunile terminalului de rertea.
1971 -RCF, 1983 - RFC 854 si RFC 855
-Accesul la distanta a fost prima cauza a creerii retelelor de date ca ARPANET. Telnet a fost proiectat intr-o epoca in care utilizatorii interactionau cu calculatorul prin intermediul unor terminale simple (dumb teminals) formate dintr-o tastatura si un afisaj, plus un hardware de comunicatie primitiv care permitea transmiterea fluxului de caractere in ambele sensuri. Mai multe astfel de terminale erau conectate la un calculator de comunicatii, conectat direct la retea sau la un host. Hostul sau controlerul erau capabile sa stabileasca o conexiune cu hostul indepartat, astfel incat utilizatorul local sa se conecteze distant si sa-l foloseasca. Problema hosturilor era cum sa asocieze anumite taste (specifice terminalului) cu anumite functii (Break sau Transmit). Fizic, terminalele difereau prin tastatura, set de caractere, dimensiunea afisajului, lungimea liniei si viteza. Logic, interactiunea terminal-host era guvernata de software-ul hostului, fiecare cu propria solutie pentru pornirea si oprirea proceselor, controlul fkuxului, etc.
Solutia adoptata de Telnet a fost sa dezvolte un protocol de terminal virtual VTP (Virtual Terminal Protocol), care transforma caracteristicile terminalului real intr-o forma standard, numita terminal virtual de retea NTV ( Network Virtual Terminal). Acesta este un dispozitiv imaginar, cu caracteristici prestabilite, si care, folosind VTP, permite stabilirea unei conexiuni intre terminalul utilizatorului si hostul indepartat. Ambele parti genereaza semnale de control si date in limbajul lor nativ. Acestea sunt apoi translatate in cele specifice NTV si respectiv, traficului de intrare e retranslatat in limbajul terminalului.
Orice VTP are patru faze de operare:
-Managementul conexiunii, care include cerea de stabilire a conexiunii si de terminare.
-Negocierea parametrilor conexiunii, functie de setul limitata de posibilitati ale terminalului real si de anumite constangeri ale NVT (ca de exemplu, lungimea linie).
-Controlul, adica schimbul de informatie de control si de comenzi ( de ex, sfarsit de linie, procesul de intrerupei).
-Datele: transferul datelor intre cei doi corespondenti. La Tenet, datele si semnalele de control sunt transportate de acelasi flux.
Obs: Din cauza naturii secventiale, orientata pe caracter, telnet nu poate accept o interfata grafica sau optiuni bidimensionale.
Telnet NVT
NVT implicit cuprinde doar optiunile cele mai simple, care pot fi implementate pe cele mai simple terminale. Pentru facilitati mai sofisticate exista faza de negociere a optiunilor. Tenet poate fi folosit de:
-doua terminale
-doua procese
-un terminal si un proces.
Daca entitatea de comunicatie e un proces e necesar un modul server de proces pentru a converti reprezentare NVT si reprezentarea procesului. Daca entitatea de comunicatii e un terminal e necesar un modul Telnet utilizator pentru asocierea caracteristicilor terminalului la cele ale NVT.
NVT Telnet este un dispozitiv orientat pe caracter, bidirectional, cu afisaj si tastatura: afisajul raspunde la datele care intra iar tastatura genereaza datele care ies, ce sunt transmise pe conexiunea Telnet si, daca se doreste ecou, si pe afisajul NVT:
Protocolul de transfer Telnet
Desi TCP e capabil de o transmisie duplex (transmisie simultana in ambele directii), datele Telnet sunt transmise semiduplex (cate o singura directie la un moment dat). De la terminal spre proces, caracterul de linie noua (prompter) semnifica sfarsitul intrarii utilizatorului, si la fel este Tenet Go Ahead dinspre proces spre terminal. Cand apar aceste semnale in fluxul de date , receptorul poate incepe sa transmita date. Datorita caracterului duplex al TCP, semnalele de control pot fi transmise la orice moment, indiferent d sensul de transmitere a datelor. Acest lucru permite utilizatorului terminalului, de exemplu, sa trimita un Abort Output, cand procesul transmite date imprimantei.
Datele sunt transmise ca un flux de octeti, fara alte formatari. Semnalele de control si informatiile non-data sunt transmise ca si comenzi Tenet, reprezentate prin siruri de octeti printre date. Comenzile pot fi semnale de control ale utilizatorului, comenzi intre procesele Telnet ca parte a protocolului de transfer si pentru negocierea optiunilor.
Fiecare comanda Telnet e precedata de caracterul IAC (Interet As Command)) (255) pentru a-l diferentia de datele utilizatorului sau procesului . ( Daca in fluxul datelor apare octetul 255 el va fi dublat). Astfel o comanda Telnet simpla are 2 octeti, al treilea octet fiind identificatorul optiunii. Comanda de subnegociere a optiunilor are lungimea variabila, dar incepe intotdeauna cu o secventa de 3 octeti (IAC SB option-id) si se termina cu o secventa de 2 octeti (IAC SE).
Protocolul Telnet de transfer al datelor minimizeaza incarcarea pentru transmisie deoarece nu pretinde octeti suplimentari pentru antetele mesajelor. Oricum incarcarea e mare la procesare deoarece atat User Telnet cat si Server Telnet trebuie sa proceseze fluxul transmis caracter cu caracter, pentru translatia datelor (NVT/nativ) si cautarea comenzilor.
Comenzile Telnet
IAC - Interpret as Command (255) - interpreteaza octetul de
comanda;
Semnale de control ale utilizatorului
AYT - Are You There (246) - cere un semnal audio-vizual ca
partea distanta e inca activa;
IP - Intrerrupt Process (244) - intrerupe procesul distant (daca
utilizatorul presupune ca procesul a intrat intr-o bucla infinita sau s-a activat un proces nedorit;
AO - Abort Output (245) - cere terminarea rularii procesului, dar
fara sa mai emita ceva terminalului utilizatorului. Se sterg si orice date deja produse dar inca neimprimate;
EC - Erase Caracter (247) - cere stergerea caracterului precedent
din fluxul de date;
EL - Erase Line (2489 - cere stergerea liniei precedente (dintre
ultimul caracter si inapoi pana la inceputul dem linie;
BRK - Break (243) - intrerupere sau atentie - codul ofera un
semnal in afara setului de caractere ASCII, pentru a indica Break sau Attention disponibile pe multe sisteme.
Comenzi proces - la - proces
GA - Go Ahead (249) - semnal de retur a liniei pentru transferul
semiduplex a datelor;
DM - Data Mark (242) - caracter de sincronizare a sirului,
impreuna cu Sync;
SB - Subnegotiation Begin (250) - incepe comanda de
subnegociere;
SE - Subnegotiation End (240) - sfarsitul parametrilor
subnegocierii;
WILL;WONT;DO; DON'T (251-254) - mesaje de negociere.
Mecanismul de sincronizare Telnet Synch
La inceput , trebuie amintit ca TCP-ul are facilitatea de urgentare a datelor (pointerul URGENT DATA), prin care receptorul datelor e informat ca dintr-un punct anume incepand sunt date urgente. TCP-ul nu incearca sa stabileasca ce anume doreste receptorul prin acele date, ci ia masuri ca acele date sa fie procesate urgent. Acest mecanism de urgentare exploateaza proprietatea de memorare (buffering) a TCP-ului. In esenta, TCP transmite datele sub forma de segmente prin conexiune, iar receptorul elimina antetele si le memoreaza. In final datele sunt pasate aplicatiei, dar nu imediat intotdeauna sau atat de repede pe cat sosesc. Astfel ca in orice moment, in buffer pot fi date vechi asteptand sa fie livrate aplicatiei. Daca segmentul care soseste inchide indicatia urgent, atunci TCP va alerta imediat aplicatia ca sunt date urgente in asteptare. Alarma de urgentare trece aplicatia in modul "urgent" de operare pentru stergerea bufferului cat mai repede posibil.
Semnalul Tenet Synch permite utilizatorului sa comunice procesului server anumite comenzi urgente (IP - interrupt process sau AO - abort output). Normal, cand un terminal e conectat direct la un sistem cu divizarea timpului, utilizatorul terminalului poate apasa tasta abort sau intrerupere determinand procesul local sa raspunda. Dar cand un terminal e conectat la un calculator printr-o retea, apare o intarziere, importanta uneori, pana cand semnalele de abort sau intrerupere ajung la proces. Problema e partial rezolvata cu semnalul Telnet Syhch.
Semnalul Telnet Synch consta dintr-o comanda DM ( Data Mark) transmisa intr-un segment TCP avand notificarea urgent. Pentru a transmite o comanda urgenta (ca AO sau IP) Telnet transmite comanda urgenta urmata de (IAC DM ) ca date urgente. Cand Telnet destinatie primeste o notificare TCP urgenta, trebuie sa verifice fluxul de date cautand comenzile normal, dar descarca toate datele. Comenzile Telnet sunt manevrate normal. Se continua pana la gasirea lui DM cand procesare revine la normal.
Optiunile Telnet
Optiunile Telnet permit celor doua parti de la capetele conexiunii sa ofere facilitati mai multe decat cele ale NVT- ului implicit. La negociere una din parti solicita o optiune, iar cealalta parte o accepta sau nu. Daca o accepta ea devine imediat activa. Negocierea poate avea loc oricand si dupa stabilirea conexiunii. In practica optiunile se negociaza imediat cand se deschide conexiunea, pentru a oferi imediat cel mai bun serviciu posibil.
Optiunile Telnet sunt impartite in 3 categorii:
Prima categorie se refera la schimbarea , imbunatatirea sau
rafineaza caracteristicile NVT. De ex: optiunile 8-16 permit definiri suplimentare ale caracteristicilor imprimantei NUT, altele permit definirea uinui nou terminal virtual in locul NUT (optiunea 20)
A doua categorie schimba protocolul de transfer. De ex. : optiunea
3 Suppres 60 Ahead cere ca sa nu fie folosita comanda GA, ceea ce transforma protocolul semiduplex in duplex. Mai sunt si optiunile care definesc comenzi noi sau caracteristici ale protocolului de transfer: optiunea 25, End of Record defineste o comanda Telnet pentru a indica sfarsitul intrarii utilizator procesului.
A treia categorie permite ca alte informatii, care nu fac parte din
datele utilizator sau protocolul de transfer, sa fie definite si transmise prin conexiune: optiunea 5, Status option, cere ca partea distanta sa raporteze starea tuturor optiunilor negociate pentru conexiune.
0-Binary transmission 17- Entended ASCII
1-Echo 18-LOgout
3-Reconnection 19-Byte macro
4-Approx Message Size Negotiation 20-data entry terminal
5-Status 21-SUPDUP
6-Timing Mark 22-SUPDUP output
7-Remote controlled trans.and echo 23-Send location
8-Output Line width 24-Terminal type
9-Output 25- End of record
10-Output Carriage-return disposition 26-TACACS user id
11-Output horizontal tab stops 27-Output marking
12-Output horizontal 28-terminal location number
13-Output formfeed disposition 29-3270 regime
14-Output vertical tabstops 30-X,3 PAD
15-Output vertical tab disposition 31Negotiate about window size
16-Output linefeed disposition 32-Send terminal speed inform.
33-Remote flow control
Majoritatea
optiunilor Telnet sunt valabile la un capat al conexiunii sau pentru un sens de
transmitere a informatiei, fara sa afecteze operarea de la celalalt capat.
Astfel ca sunt necesare doua negocieri separate , daca o optiune se
doreste pentru ambele sensuri. Astfel, pentru un sens poate fi negociata
optiunea EOR, End of Record, (terminal 
proces) care
ar permite comanda Telnet EOR , care indica sfarsitul datelor utilizatorului.
Pentru sensul ( proces terminal) trebuie negociata separat optiunea
pentru a defini un caracter similar, care sa semnaleze sfarsitul datelor
procesului trimise imprimantei.
Negocierea optiunilor
Fiecare parte poate initia negocierea unei optiuni care sa devina valida pe parte cealalta. De exemplu, partea User Telnet poate initia negocierea , cu preferintele sale pentru ecou, sau cererea poate fi facuta de ServerTelnet. Negocierea poate cere validarea unei noi optiuni pentru conexiune sau invalidarea optiunii curente.
O negociere corecta trebuie sa respecte regulile:
1. Cererea de validare a unei optiuni poate fi respinsa
2. Cererea de invalidare a unei optiuni trebuie acceptata
3. Optiunile sunt valabile doar la sfarsitul negocierii
4. nu se negociaza ( cerere sau raspuns) ceva care e deja adevarat. Deci nu se initiaza /raspunde la o cerere de initiere a unei optiuni existente.
Exista 4 comenzi de negociere a optiunilor: WILL,WONT,Do,DONT, a caror interpretare depinde de context.
WILL
WILL DO
Initiatorul
doreste initiatorul
doreste
o
optiune, cel ce ca
cel ce raspunde
DO
raspunde
e de acord sa
valideze o opti-
une
si acesta e de
initiatorul
doreste o acord
DONT WONT
o
optiune, cel ce
raspunde nu e de acord intiatorul doreste
ca cel ce raspunde
sa
valideze o opti-
une si acesta nu e
DONT WONT DONT
de
acord
initiatorul
doreste sa
invalideze o optiune
cel ce raspunde trebuie
WONT
sa
fie de acord initiatorul
doreste
sa
invalideze
o
optiune
la cel ce raspunde
si acesta trebuie sa
fie de acord
Protocolul nu e ambiguu daca ambele parsi fac aceeasi cerere si ambele mesaje trec prin retea. De exemplu, daca A vrea ca B sa implementeze o comanda, A genereaza comanda DO, si daca B e de acord raspunde cu comanda WILL. Daca b vrea ca el b , sa implementeze o optiune genereaza o comanda WILL si daca A e de acord raspunde cu comanda DO.
Daca A si B fac o cerere lui B sa implementeze o optiune , in acelasi timp, atunci A genereaza o comanda DO si B o comanda WILL; aceste comenzi traverseaza reteaua si ambele parti primesc un raspuns la comenzile lor.
Actiunile de validare/invalidare a unei operatiuni depind de respectiva optiune. Unele optiuni prevad ca la negociere sa se verifice daca ambele parti pot suporta optiunea, si daca da urmeaza subnegocierea. Protocolul de subnegociere (format, secventiere, interpretarea mesajelor de subnegociere ) e parte a specificatiilor optiunii ( ex: optiunea Terminal Type).
Transferul de fisiere FTP File Transfer Protocol
Ca si Telnet, FTP a aparut intr-o epoca cu sisteme foarte diferite, deci lucreaza cu o mare varietate de comenzi, moduri de transfer si reprezentari de date, multe dintre ele invechite. Obiectivele FTP (RFC 959) declarate sunt:
promovarea partajarii fisierelor (programe si/sau date);
incurajarea indirecta sau implicita (prin programe) a folosirii calculatoarelor la distanta;
protejarea utilizatorului de variatiile sistemelor de memorare a fisierelor de pe hosturi diferite;
transferul sigur si eficient al datelor.
Implicit e faptul ca se lucreaza mai degraba cu sisteme de fisiere decat cu fisiere simple. Un fisier simplu poate fi privit ca un simplu set de biti cu un nume, viziune ce apartine TFTP (Trivial File Transfer Protocol). La acest protocol transferul fisierului e o sarcina simpla: trimite antetul cerut pentru scrierea sau citirea unui fisier cu un nume oarecare, dupa care insira bitii in retea. FTP considera. Pe de alta parte, sisteme de fisiere si astfel lucreaza cu metadate ca: nume de cale a fisierelor, controlul accesului si reprezentarea datelor (RFC 959).
Modelul FTP
Ca si Telnetul, FTP implica entitatea User FTP si entitate Server FTP. Utilizatorul este hostul care initiaza transferul. El alege numele fisierului si optiunile pentru transfer. Serverul accepta sau respinge cererea de transfer conform cu criteriul propriu de protectie a sistemului sau de fisiere si optiunile solicitate. Daca cererea de transfer e acceptata, serverul e responsabil cu stabilirea si manevrarea transferului.
FTP opereaza pe doua niveluri (vezi figura urmatoare). Pentru a incepe, modul de protocol de utilizator FTP stabileste o conexiune TCP cu un modul de protocol de server FTP. Aceasta conexiune e folosita pentru a schimba informatii de control sub forma de comenzi FTP si raspunsuri . Cand e acceptat transferul de fisiere, se stabileste a doua conexiune FTP si datele fisierelor sunt transferate prin aceasta conexiune; acesta poate fi considerat nivelul de protocol de transfer a datelor. Ambele niveluri ale FTP interactioneaza cu software-ul TCP/IP din sistemul local pentru activarea conexiunilor TCP.
Modelul FTP
Ambele niveluri FTP interactioneaza si cu software-ul sistemului local de
management a fisierelor, pentru a accesa sistemul de fisiere local si fisierele sale. In final, exista si o interfata a utilizatorului FTP , care permite unui utilizator uman sau unui program sa acceseze utilizatorul FTP.
Comenzile FTP specifica parametrii conexiunii de date (portul de date modul de transfer, tipul reprezentarii si structura) si natura operarii sistemului de fisiere (memorare/store, recuperare/retriviere, comasare/append, stergere/delete, etc).
Comenzi (parametri) de control a accesului
USER username - identifica utilizatorul pentru hostul indepartat;
PASS password - autentificarea utilizatorului;
ACCT account information - idntifica contul utilizatorului;
REIN - un utilizator termina si sterge toate bufferele;
Pregatit pentru o noua comanda USER,
Sesiune
REST maker - Restart. Treci (skips) peste fisierul specificat de
markerul datelor;
SITE string - Trimite informatia hostului strain, care e folosi-
ta pentru a furniza servicii specifice acelui host
SYST - Gasirea tipului de sistem de operare la server;
STAT (pathname) - Genereaza raspuns despre stare, de trimis pe
conexiunea de control;
QUIT - Utilizatorul termina si inchide conexiunea de
control.
Parametri de transfer
PORT host-port - Specifica portul de date de folosit in conexiu-
nile de date;
PASV - Cere serverului sa asculte portul de date si sa
astepte o conexiune, mai degraba decat sa
intieze o conexiune;
TYPE type-code - Specifica tipul reprezentarii;
STRU structure- code - Specifica structura fisierului;
MODE mode-code - Specifica modul de transfer a datelor.
Servicii FTP
RETR pathname - (Retrieve) recuperare, accesare, copiere.
Transfera fisierul de pe server la utilizator.
* retrieve- functie care permite utilizatorului sa copieze un fisier arhivat din memorie pe serverul de fisiere sau workstation. Copia din memoria arhivata (storage pool) nu e afectata. E in opozitie cu arhivarea (IT Vocabulary - IBM).
STOR pathname - (Store) memoreaza. Transfera fisierul de la
utilizator pe server. Daca numele de fisier
specificat in numele caii exista deja, e in-
locuit.
STOU - (store unique). Transfera fisierul de la utiliza-
tor pe server. Serverul creeaza nume de
fisiere unice si le returneaza utilizatorului
APPE pathname - (append) ataseaza/comaseaza. Tranfera datele
de la utilizator pe server. Daca numele de
fisier specificat de numele caii exista deja, se
ataseaza datele fisierului existent si daca nu,
se creeaza un fisier nou.
DELE pathname - (delete file) stregerea fisierului.
ALLO integer (R integer) - (allocate) alocare. Poate fi ceruta de unele
servere pentru a rezerva spatiul de memorie
suficient.Primul argument, e numarul de
octeti. Al doilea argument, optional, e
dimensiunea paginii sau a inregistrarii.
LIST pathname - daca numele caii specifica un director,
serverul transfera lista de fisiere in director, iar
daca e un fisier serverul transfera informatia
curenta in fisier.
NLST pathname - (name list) numirea listei, face ca serverul
transfere o lista de fisiere.
RNFR pathname - (rename from) redenumeste, din: specifica
numele de cale vechi a fisierului ce trebuie
redenumit. Trebuie urmata de o comanda RNTO.
HELP (string) - determina serverul sa trimita informatii despre
starea implementarii. Argumentul optional e
un nume de comanda pentru care serverul
returneaza mai multe informatii specifice.
NOOP - (no-operation) serverul returneaza raspusul OK.
Protocolul de transfer a datelor utilizatorului trebuie "sa asculte" la un port de date specificat si serverul initiaza conexiuni de date si transferul datelor , conform cu parametrii specificati.
Interesant este faptul ca FTP foloseste protocolul Tenet pe conexiunea de control. Acest lucru se face in doua moduri:
protocolul FTP utilizator sau protocolul FTP server poate
implementa direct regulile protocolului Telnet in propriile proceduri;
protocolul FTP utilizator sau protocolul FTP server poate utiliza
modulul Telnet existent in sistem.
Transferul
In exemplul urmator e prezentat un transfer simplu, farar erori. Nu sunt analizate detaliile specificatiilor optiunilor.
Se presupune ca programul utilizatorului apeleaza FTP-ul utilizatorului - User FTP. Utilizatorul da adresa sistemului indepartat la care doreste accesul. Ca raspuns, protocolul FTP User deschide o conexiune TCP, numita conexiune de control, spre hostul indepartat. Toate comenzile si raspunsurile vor trece prin acesta conexiune (vezi fig. a).
In fig. b si c e prezentat procesul de control a accesului . Utilizatorul (sau programul utilizatorului) furnizeaza numele de cont si parola sistemului local, care formeaza comenzile FTP si la va trimite serverului. In cazul acesta, numele de cont si parola sunt valide si sunt acceptate. FTP nu ia parte la procesul actual de autorizare a utilizatorului. El ofera doar un mod prin care informatia e pasta unui mecanism oarecare din sistemul de management a fisierelor de pe server, pentru a controla accesul.
h)
Fig.d. Apoi User FTP furnizeaza detaliile specifice transferului: numele fisierului, directia transferului (get or put) ( ia sau trimite) si detalii despre tipul fisierului si modul de transfer, care sunt facute printr-o secventa de comenzi (nereprezentate in fig.d). Ca si la controlul accesului, s-ar putea ca utilizatorul sa nu vada toate detaliile acestui pas. Programul User FTP interpreteaza intentiile utilizatorului si trimite o serie de comenzi FTP prin conexiunea de control. Cand toate comenzile au fost receptionate si confirmate, poate incepe transferul. Ambele parti sunt de acord ca fisierul poate fi transferat in directia specificata, folosind tipul datelor, tipul fisierului si modul de transfer dat de User FTP.
Fig.f arata modul de transfer al datelor. Fisierul e transferat ca o secventa de segmente TCP (aici de la server la user). Serverul si userul lucreaza impreuna, folosind mecanismul TCP de control a fluxului si erorilor,al conexiunilor de date, pentru a citi datele din fisierul sursa, a le incapsula printr-un numar de octeti in fiecare segment TCP, si a scrie datele din segmentele receptionate in fisierul destinatiei la hostul utilizatorului. TCP e responsabil cu retransmisia segmentului daca se detecteaza erori si pentru controlul fluxului de la sursa si de pe conexiunea TCP.
Fig.g,h. Cand serverul a extras ultimul octet din fisierul sursa, transmite ultimul segment TCP si initiaza inchiderea conexiunii. Procesul FTP user interpreteaza aceasta inchidere normala ca un semnal ca transferul e complet si ambele parti /user si server) termina conexiunea de date. Conexiunea de control ramane deschisa si poate fi folosita pentru controlul de date sau se poate inchide in acest punct.
Optiuni
Proiectarea FTP considera ca fisierele sunt obiecte aflate in memoria de masa a calculatorului, care partajeaza anumite proprietati, indiferent de tipul masinii. Fisierele au nume simbolice care permit identificarea lor in mod unic, de catre un anume sistem de fisiere sau directoare. Un fisier are un proprietar si e protejat fata de accesul neautorizat sau modificarile facute de altii.
Un fisier poate fi:
-citit de pe ( copiat de pe)
- scris pe
- sters
- creat
Cu acest cadru de lucru simplu FTP reuseste sa transfere fisiere intre diverse calculatoare prin retele diferite. Pentru a se adapta necesitatilor unui calculator anumit si cu un anume sistem de operare, FTP furnizeaza un mecanism de negociere a optiunilor de transfer cu 3 dimensiuni:
tipul datelor
tipul fisierelor
modul de transfer.
Programatorul fiecarui sistem trebuie sa determine modul de asociere a unui fisier oarecare cu unul din fisierele standard.
Tipuri de date
Sunt 4 tipuri de date: ASCII, EBCDIC, imagini si secventa logica de octeti. Primele doua se folosesc pentru reprezentarea fisierelor text, care se memoreaza ca un sir de caractere pe majoritatea masinilor /se folosesc caractere ASCII pe 8 biti). Astfel, daca e folosita optiunea ASCII nu mai e necesara vreo conversie de cod la sfarsit, in majoritatea cazurilor. Optiunea EBCDIC e potrivita daca ambele hosturi sunt IBM, folosind codul EBDIC.
Fisierele de tip ASCII sau EBCDIC mai pot avea specificatii suplimentare referitoare la reprezentarea lor pe imprimanta. Deoarece unele sisteme includ in textul tiparit caracterele de control pentru imprimanta, se ofera trei variante:
nonprint, pentru fisiere care nu vor fi tiparite:
telnet formatting , caractere de control vor fi extrase din text si folosite pentru formatarea paginii (ex: carriage return, line feed, new line, vertical tab, form feed)
character control formatting, optiune de formatare folosita pentru limbajul FORTRAN.
Tipul image e folosit pentru transferul unor fisiere arbitrare intre doua masini de acelasi tip cu acelasi sistem de operare. Un transfer de tip imagine e o replica bi-cu-bit a fisierului de pe masina sursa pe masina destinatie. Tipul logical byte size se foloseste cand sunt unitati de date la care trebuie conservata dimensiunea. Se specifica dimensiunea in octeti (care nu trebuie sa aiba neaparat 8 biti). E cel mai des folosit cand vrem sa ne asiguram ca imaginea programului executabil , compilata pe o masina si transmisa si memorata pe o alta masina , poate fi corect interpretata si manevrata pe a doua masina.
Tipuri de fisiere
FTP defineste trei tipuri de fisiere:
structuri de fisiere (file structure)
structuri de inregistrare (record structure=
structuri de pagini (page structure)
pentru a oferi o interfata convenabila si eficienta sistemului de fisiere de la sursa si destinatie. Se asigura astfel compatibilitatea cu orice sistem de operare.
a) Tipul "file structure" presupune ca fisierul e doar un sir de octeti (definit prin optiunea datelor) cu sfarsitul semnalat de un marker (EOF-End of File);
b) Tipul "record structure" se foloseste cand e ,ai convenabil ca fisierul sa fie tratat ca o secventa de inregistrari (record). O inregistrare poate fi de dimensiunea agreata de hrdware-ul controlerului din interfata discului sistemului. Se transmit inregistrarile separate, fiecare avand un marker de sfarsit (EOR - End of Record);
c)Tipul "page structure" e folosit pentru fisiere care sunt memorate continuu pe disc si la care trebuie pastrata structura de pagini la transfer.
a)
Numarul
paginii
Pointer
c)
|
|
Tabela cu pagini
Moduri de transmisie
In timp ce tipurile de date si de fisiere se refera la problemele sistemelor de operare de pe hosturile sursa si destinatie, modul de transmisie ofera optiuni pentru optimizarea lucrului cu reteaua. Sunt definite trei moduri de transmisie:
modul flux;
modul bloc;
modul comprimat.
Modul flux e cel mai simplu , fiind implicit (default mode). Datele sunt transmise nemodificate pe conexiunea de date. Deoarece exista procesari specializate la capetele conexiunii, acest mod cere un efort minim serverului si utilizatorului. Nu exista restrictii de tipuri de fisiere. Pentru fisierele cu structura "record" se folosesc 2 octeti marcand sfarsitul inregistrarii si sfarsitul fisierului.
Modul bloc permite repornirea unui transfer esuat/intrerupt. La aparitia unei defectiuni sau intreruperi, transferul se reia doar din acel loc si nu se retransmite intregul fisier. Daca acest mod e acceptat, sursa inacpsuleaza datele in blocuri; fiecare bloc incepe cu un antet din 2 campuri.
|
Descriptor 1B |
Contor de octeti 2B |
Date >oB |
Descriptor Modulul bloc
0000.0000 nu exista descriptor
1000.0000 EOR
0100.0000 EOF
0010.0000 Suspiciune de erori in date
0001.xxxx blocul de date e un marker de restart, format din xxxx octeti
1 bit 7 biti n octeti Modulul comprimat
|
N |
Date necomprimate |
2 6 8 biti 2 6 biti
|
n |
Octeti replica |
n |
Cod descriptor |
- Descriptorul EOR: structura "record" e permisa dar nu necesara
la modul de transmitere bloc. Poate fi folosit orice tip de date. Daca se foloseste structura "record", atunci fiecare inregistrare poate avea unul sau mai multe blocuri.
EOF - indica sfarsitul fisierului;
- Date suspecte, arata ca datele ce se transfera nu sunt de incredere. Dar codul nu presupune un control al erorilor de catre FTP. Intentia a fost ca sa se foloseasca pentru surse care pot prezenta pe alocuri erori (date seismice sau meteorologice( ca de ex: (erori de citire a benzii magnetice).
- Markerul de restart: blocul contine caractere, ce pot fi tiparite si marcheaza un punct de control in fluxul de date , de catre sursa. Receptorul marcheaza pozitia la randul sau in fluxul de date si returneaza aceasta informatie transmitatorului. In caz de intrerupere, sursa si transmitatorul pot reporni transferul da la ultimul marker de restart receptionat corect. Nu sunt specificate modurile de plasare a punctelor de control si repornire.
- Contorul din antet indica lungimea blocului de date (in bytes), fiind astfel marcat inceputul urmatorului bloc de date (nu exista biti de completare).
Modul comprimat ofera o cale de eficientizare a transferului permitand sursei sa comprime intr-un cod mai scurt secventele de caractere de acelasi tip. Sunt permise 4 formate diferite. Dar fiecare format incepe cu un antet de 8 biti:
date necomprimate: antetul indica numarul de octeti necomprimati care urmeaza (max 127 octeti, dupa care e necesar un nou antet);
octeti replicati (copiati): cand fisierul sursa contine o secventa de octeti cu aceeasi valoare, ei sunt extrasi si inlocuiti cu formatul replicat de octeti. Secventa de 2 octeti permite definirea unei repetitii de pana la 63 octeti specificati. FTP destinatie trebuie sa substituie formatul octetilor replicati cu numarul indicat de octeti specificat;
siruri de umplere (filler string( : permit o compresie suplimentara pentru caractere speciale (de obicei caracterul spatiu) care apar frecvent in fisierele text. Acest format permit ca la receptie sa fie inserate pana la 63 asemenea caracter,
secventa "escape" consta din octeti formati doar din zerouri urmati de octetul descriptor al codului, asa cum e definit in modul bloc
POSTA ELECTRONICA - ELECTRONIC MAIL
Este cea mai utilizata aplicatie dinretelel de comunicatii. Pentru inceput, cand se transmiteau mesaje simple, a fost suficient protocolul SMTP (Simple Mail Transfer Protocol), dar mai recent a fost dezvoltat protocolul MIME (Multi-Purpose Internet Mail Extension) pentru a permite transmiterea unor tipuri de date variate: voce, imagine, videoclipuri.
SMTP
Este protocolul standard de transfer a postei electronice intre hosturile avand implementate stiva de protocoale TCP/IP (RFC 821). Desi formatul mesajelor transferate de SMTP pastreza de obicei formatul specificat de RFC 822, nu exista reguli cu privire la continutul mesajului. SMTP foloseste informatia din antetul mesajului, anvelopa. Singurele reguli sunt ca.
SMTP foloseste codarea ASCII, pe 7 biti a caracterlor;
SMPT adauga informatie (log information) mesajului livrat , care indica ce cale a urmat acesta.
Operatiile de baza pentru e-mail
In figura e prezentat fluxul de e-mail intr-un sistem tipic , desi o mare parte nu face parte din SMTP
|
De la transmi- Tatorul SMPT Indepartat, la portul 25 local |
Recetpor
SMPT
e-mailuri utilizator
Ca raspuns la intrarea utilizator e creat mail-ul de program agent utilizator. Fiecare mesaj creat dintr-un antet ce contine adrese si alte informatii si corpul mesajului cu informatiile de trimis. Aceste mesaje sunt memorate intr-un mod oarecare, intr-o coada de asteptare (queue) si sunt oferite ca intrare programului de transmisie SMTP care e un program server prezent permanent pe host.
Orice mesaj di coada are 2 parti (indiferent de sistemul de operare al hostului):
1. -textul mesajului format din : - antetul RFC 822, care constituie anvelopa si include indicatii despre destinatar/destinatari; - continutul /corpul mesajului, compus deutilizator.
2. o lista a destinatiilor mail-ului, dedusa de agentul utilizator di antetul 822 al mesajului. Uneori destinatia/destinatiile sunt specificate literal in antet, alteori agentul utilizator trebuie sa extinda numele din lista de e-mailuri, sa indeparteze duplicatele, sa inlocuiasca numele mnemonice cu nume din lista de e-mailuri. Daca se cere o copie "oarba" BCC (blind carbon copy) agentul utilizator trebuie sa pregateasca mesajul in acest sens. Idea de baza e ca diferite stiluri si formate preferate de utilizatorul uman in interfata utilizator sunt inlocuite cu forma standard adecvata pentru transmiterea SMTP.
Transmitatorul SMTP ia mesajul din coada de mail de iesire si-l transmite hostului destinatie printr-o tranzactie SMTP, pe una sau mai multe conexiuni, la portul 25 a hostului destinatie. Un host poate avea transmitatoare SMTP multiple active simultan, daca are un volum mare de mailuri de transmis si de asemenea poate crea la comanda receptoare SMTP multiple, astfel incat mailul de la un host sa nu fie intarziat de mailuri de la alte hosturi.
La livrarea unui mesaj, transmitatorul SMTP sterge respectiva destinatie din lista destinatiilor , iar cand l-a livrat tuturor destinatarilor, sterge mesajul coada. Transmitatorul SMTP poate optimiza lucrul cu coada. Astfel daca un mesaj e trimis la mai multi utilizatori de pe acelasi host, textul mesajului e transmis o singura data. Daca mai multe mesaje sunt gata de transmis aceluiasi host, transmitatorul SMTP deschide o singura conexiune TCP, transfera toate mesajele si inchide conexiunea, in loc sa deschida cate o conexiune pentru fiecare mesaj.
Transmitatorul SMTP trebuie sa rezolve o serie de erori: hostul destinatie nu poate fi gasit, poate fi inactivg sau conexiunea TCP poate sa defecteze in timpul transferarii mailului. Transmitatorul poate reincarca mailul in coada pentru livrarea ulterioara, dar dupa un timp abandoneaza, nu-l tine la infinit acolo. Alta situatie frecventa este adresa destinatiei gresita, fie scrisa gresit de utilizator fie din cauza unei adrese noi a destinatarului pe un host diferit. Daca poate, transmitatorul SMTP redirecteaza mesajul si daca nu returneza sursei un mesaj de eroare.
(RCF 821) Protocolul SMTP e folosit pentru a transfera mesajul de la transmitatorul SMTP la receptorul SMTP printr-o conexiune TCP. SMTP incearca sa opereze singur, dar nu garanteaza recuperarea mesajelor pierdute. SMTP nu returneaza o confirmare cap-la-cap sursei mesajului, de livrare cu succes. Nu se garanteaza nici returnarea mesajelor de eroare. Cu toate acestea sistemele de mail folosind SMTP sunt considerate sigure in general.
Receptorul SMTP accepta fiecare mesaj care soseste si il plaseaza in cutia postala a utilizatorului, potrivz, fie il copiaza intr-o coada locala de iesire daca se cere redirectionarea ( forwarding). Receptorul SMTP trebuie sa fie capabil sa verifice destinatiile locale ale mailului si sa trateze erorile , inclusiv erorile de transmisie si memoria insuficienta.
Transmitatorul STMP e responsabil cu extragerea mesajului cand receptorul SMTP indica sfarsitul transferului, desi acest lucri inseamna doar ca mesajul a ajuns la receptorul SMTP si nu ca mesajul a fost livrat destinatarului final. Referitor la erori, receptorul SMTP se limiteaza sa renunte la conexiunile TCP care esueaza sau sunt inactive prea mult timp, astfel ca transmitatorul are majoritatea responsabilitatii. Erorile care apar in timpul incheierii indicatiei de eroare pot duce la duplicare a mesajelor, dar nu la pierderea lor.
De obicei, mesajele circula pe o singura conexiune TCP de la sursa la, destinatie. Uneori, mailul poate trece prin mai multe masini intermediare, folosind posibilitatea de "forwarding SMTP" (expediere ),caz in care mesajul traverseaza mai multe conexiuni TCP. O posibilitate de a face acest lucru este ca transmitatorul sa specifice ruta spre destinatie ca o secventa de servere. Mai des e cazul cand forwarding-ul e necesar din cauza mutarii utilizatorului.
Operare SMTP consta dintr-o serie de comenzi si raspunsuri schimbate intre transmitator si receptorl SMTP. Initiativa apartine transmitatorului SMTP care stabileste conexiunea TCP. Odata ce conexiunea a ost stabilita, transmitatorul SMTP transmite comenzi, prin conexiune, receptorului SMTP. Fiecare comanda genereaza o replica de la receptorul MTP.
Fiecare comanda consta dintr-o linie de text, incepand cu codul comenzii din 4 litere si urmat eventual de argumente . Replicile sunt de obicei dintr-o singura linie, dar exista si replici multilinii.
De la pag.87 (sfarsit) si pana la mijlocul pag 89 nu am scris fiindca nu stiu tipul caracterelor!
REPLICI SMTP
Confirmarea pozitiva a terminarii operatiei: actiunea ceruta s-a incheiat si poate fi initiata o noua cerere.
- Starea sistemului sau serviresa sistemului (sistem help)/ ajutor;
- Mesaj de ajutor (help): informatie despre modul de folosire a recptorului sau sensul unor anumite comenzi nestandard. Replica foloseste doar utilizator uman;
<domain> serviciu pregatit;
<domain> serviciu inchizind canalul de transmisie,
actiune ceruta de mail s-a incheiat cu succes;
utilizatorul nu e local; se va expedia mai departe pe <forward-path>;
Replica pozitiva intermediara: comanda a fost acceptata, dar actiunea e suspendata temporar, in asteptarea unor informatii suplimentare, pe care transmitatorul mai trebuie sa le furnizeze. Se foloseste pentru grupuri de secvente de comenzi.
incepe mail-ul; se termina cu <CRLF>.<CRLF>.
Confirmare negativa tranzitorie a incheierii actiunii: comanda a fost acceptata si actiunea ceruta nu apare;
<domain> serviciu nedisponibil, canal cu pierderi de date, )poate fi raspunsul la orice comanda, cand serviciul stie ca trebuie sa se dezactiveze;
-actiunea ceruta de mail nuva fi indeplinita; mailbox nedisponibil/ocupat;
-actiunea ceruta e respinsa; exista erori in procesarea locala;
-actiunea ceruta nu e preluata; spatiu de memorie insuficient.
Confirmare negativa permanenta a incheierii actiunii: comanda nu a fost acceptata si actiunea ceruta nu va avea loc.
-eroare de sintaxa, comanda nerecunoscuta (sunt incluse si erori cum ar fi linie de comanda prea lunga);
- eroare de sintaxa in parametri sau argument ;
- comanda neimplementata;
- secventa gresita de comenzi;
- parametri de comanda neimplementati;
- actiunea solicitata nu e preluata; mailbox nondisponibil
(ex: mailbox negasit, nu e acces, etc);
- utilizatorul nu e local, incercati <forward - path>;
- respingerea actiunii ceruta de mail ; e depasita memoria
- acsiunea solicitata nu e preluata, nume nepermis de mailbox (sintaxa incorecta);
- tranzactie esuata.
Miranda 7
Operatiunile de baza SMTP se desfasoara in 3 faze: stabilirea conexiunii, schimbul unei sau mai multor perechi comanda-raspuns si terminarea conexiunii.
Stabilirea conexiunii: transmitatorul SMTP va incerca sa stabileasca o conexiune TCP cu hostul indepartat, cand exista unul sau mai multe mailuri destinate acestuia. Secventa este:
transmitatorul deschide o conexiune TCP cu receptorul;
dupa ce conexiunea a fost stabilita, receptorul se identifica cu "220 Service Ready";
transmitatorul se identifica cu o comanda HELO;
receptorul accepta cu "2500K" identificarea transmitatorului.
Daca la destinatie serviciul de mail nu e disponibil. Hostul destinatie returneaza "421 Service Not Available" in pasul 2 si procesul se termina.
Transferul mail-ului: dupa stabilirea conexiunii, transmitatorul poate transmite una sau mai multe mesaje receptorului SMTP. Exista 3 faze logice la transferul mesajului:
comanda MAIL identifica sursa/initiatorul mesajului;
una sau mai multe comenzi RCPT identifica recipientul mesajului;
comanda DATA transfera textul mesajului.
Obs. Comanda MAIL arata calea de retur, ce poate fi folosita pentru raportarea erorilor. Daca receptorul e pregatit sa accepte mesajele de la sursa, returneaza replica "250 OK". In caz contrar, raspunsul indica esecul in executia comenzii (codurile 451,452,453) sau o eroare in comanda (codurile 421,500,501).
Comanda RCPT indica recipientul datelor din mail. Pentru fiecare comanda RCPT se returneaza separat :
1-raspunsul 250: receptorul accepta destinatia, adica mailbox-u-rile vizate se afla la receptor;
2- raspunsul 251- destinatia va transfera (forwarding) mai departe mailul (redirectare);
3-raspunsul 551- destinatia ar trebui transferata, dar receptorul nu redirectioneaza mailul; expeditorul trebuie sa trimita din nou adresa de forwarding;
4-raspunsul 550: nu exista mailbox ( cutie postala) pentru recipient pe host;
5-raspusurile 450,451,452,552,553 - destinatia e respinsa din alte motive decat cele precedente sau 421,500,501,503 sunt erori in comanda.
Faza RCPT separata are avantajul ca transmitatorul nu va trimite mesajul pana nu e sigur ca receptorul e pregatit pentru receptia mesajului, pentru cel putin un recipient, evitandu-se astfel supraincarcarea de a transmite intregul mesaj doar ca sa se afle ca destinatia e cunoscuta. Odata ce receptorul SMTP a fost de acord sa primeasca mesaje pentru cel putin un recipient, transmitatorul SMTP foloseste comanda DATA pentru a initia transferul mesajului. Daca receptorul SMTP se mai pregateste inca de receptie, returneaza 354, altfel returneaza o replica ce indica esecul executarii comenzii (451,554) sau eroare in comanda (421,500,501,503). Daca primeste 354, transmitatorul SMTP incepe transmisia mesajului pe conexiunea TCP, ca o secventa de linii ASCII. SMTP raspunde cu 250 OK daca mesajul e acceptata sau cu un cod de eroare adecvat (451,452,552,554).
Un exempu (din RFC 821) ilustreaza procesul:
S: MAIL FROM : <Smith @Alpha.ARPA>
R: 250 OK
S: RCPT TO : <Jones @Beta. ARPA>
R: 250 OK
S: RCPT TO : <Green @Beta.ARPA>
R: 550 No such user here
S: RCPT TO : < Brown @Beta. ARPA>
R: 250 OK
S: DATA
R: 354 Start mail input; end with < CRLF>.<CRLF>
S: Blach, blah, blah,
S: .etc, etc, etc
S: <CRLF>.<CRLF>
R: 250 OK
Transmitatorul SMTP transmite de la utilizatorul : <Smith @Alpha.ARPA> un mail spre 3 destinatari de pe masina Beta. ARPA, Jones, Green, si Brown. Receptorul anunta ca are cutii postale doar pentru Jones si Brown, dar ca nu stie nimic despre Green. Deoarece cel putin un recipient e confirmat, transmitatorul expediaza mesajul text.
Inchiderea conexiunii se face in doi pasi de transmitatorul SMTP:
S transmite o comanda QUIT si asteapta raspunsul;
Inchiderea conexiunii TCP: R initiaza propria inchidere de
conexiune TCP dupa transmiterea lui QUIT.
RFC 822 defineste formatul mesajelor text trimise prin e-mail. Mesajele contin:
o anvelopa, cu informatiile necesare transmiterii si livrarii;
continut. Doar la acesta se refera RFC 822.
Liniile de antet contin : cuvant cheie, coloana, argumentul cuvantului cheie. Liniilelungi sunt transferate in mai multe linii. Cuvintele cheie uzuale sunt: From, To, Subject, Date (iar Message ID contine un identificator unic al mesajului)
Date : Tue, 16 Jan 2006 10:37
From : "William Stallings" < ws @host.com>
Subject :The Syntax in RFC 822
To : Smith @ other-host.com
CC : Jones @ Yet-Another Host.com
BCC : Green @ Thirt-Host.com
Hello. This section begins the actual message body, which is delimited from the message heading by a blank line.
Obs : Chiar daca protocolul SMTP este bine definit de RFC 821 pot aparea probleme:
- lungimea mesajelor: la implementarile vechi e de 64KB;
- exprimarea timpului (time-out): daca difera la client si server , s-ar
putea ca unul sa renunte, intrerupand neasteptat conexiunea, in timp ce celalalt e inca ocupat;
- schimburile infinite de mesaje: daca:
- daca masina 1 pastreaza lista de posta A;
- masina 2 pastreaza lista de posta B;
- fiecare lista contine o intrare pentru cealalta, atunci orice mesaj
trimis oricareia dintre liste genereaza un trafic de email nesfarsit.
Unele din aceste probleme au fost rezulvate de protocolul SMTP extins ESMTP. Clientii care doresc sa-l utilizeze trimit initial mesajul EHLO ( in loc de HELO):
daca e rejectat serverul e standard, cu SMTP, si clientul procedeaza
normal;
daca e acceptat, sunt permise comenzi si parametri noi.
Portile de e-mail
Posta electronica functioneaza cel mai bine (folosind SMtp) daca ambele parti sunt in Internet si pot stabili conexiuni TCP. Exista insa cazuri cand:
Masinile nu sunt conectate la Internet ( in companii, pentru
securitate);
Cand transmitatorul intelege doar RFC 822 (SMTP) si recptorul alte
protocoale de e-mail (X.40 sau standard de proprietar).
Aceste probleme se rezolva prin porti de e-mail la nivelul aplicatiei.
OSI TPA
X,400
Poarta trebuie sa extraga mesajele sosite dintr-o coada si sa le transfere in cealalta coada. Dar problema nu este simpla, deoarece:
- adresele Internet si cele X.400 difera complet, trebuie puse in corespondenta. Anvelopa/antetul au campuri diferite.
- daca un sistem, are clase de prioritate si celalalt nu , se vor pierde informatii valoroase intr-un sens si in sensul celalalt trebui generate din nimic;
- rezolvarea altor probleme ca :
- un mesaj se refera la un fisier audio ce trebuie obtinut prin FTP, si celalalt sistem nu accepta acest concept;
- Un sistem X.400 care in caz de esec mesajul sa fie trimis prin
fax, dar folosirea faxului nu face parte din RFC822.
Solutiile sunt mai simple doar pentru mesaje simple (text ASCII), dar
in rest sunt foarte complicate ( 
convertoare
de protocol).
Livrarea finala
1) POP3 (Post Office Protocol) RFC1225
Multi utilizartori lucreaza pe PC-uri neconectate la Internet, dar
compania unde se afla serverele de email, cu care acesti utilizatori comunica
pentru a trimite / primi emailuri, folosind un protocol simplu POP #3: are
comenzi de conectare / deconectarea utilizatorilor, aducerea / stergerea
mesajelor.
2) IMAP (Interactive Mail System Protocol) RFC 1064
A fost proiectat pentru utilizatorii care folosesc mai multe calculatoare ( la serviciu, acasa, portabil). Serverele trebuie sa pastreze un depozit central de mesaje si accesul la el sa fie posibil de pe orice masina. Spre deosebire de POP # , IMAP nu copiaza emailul pe masina utilizatorului, fiindca acesta poate avea mai multe . IMAP are multe facilitati, ex.: nu adreseaza un mesaj prin numarul de sosire ci prin atribute (da-mi primul mesaj de la Sam). Cutia postala e un sistem de baze de date relationale si nu o secventa liniara de mesaje.
3) DMSP ( Distributed Mail System Protocol) RFC 1056
E o parte a sistemului PCMAIL. Nu se presupune ca tot emailul se afla la nivelul unui singur server (ca la POP si IMAP). Permite utilizatorilor sa descarce emailul pe calculatorul propriu si sa se deconecteze apoi. Utilizatorul poate cit / scrie mesajele cat e deconectat si cand se reconecteaza transmite emailurile si sistemul e resincronizat.
Facilitatile pentru procesarea suplimentara a mesajelor permite:
construirea filtrelor = set de reguli ce specifica o conditie si o
actiune, ce se verifica la pornirea utilizatorului sau la primirea mesajelor.
redirectionarea ( temporara ) emailurilor : un alt calculator sau un
serviciu de comunicatii ( care va contacta utilizatorul prin radio / satelit afisand un mesaj);
demonul de vacanta, care trimite un mesaj automat, in absenta
utilizatorului;
robotul de email: verifica fiecare mesaj sosit sa vada daca e de la
un corespondent nou si daca da returneaza un raspuns standard: mu mai pot citi personal toate emailurile, dar am produs un document care raspunde la majoritatea intrebarilor frecvente (FAQ - frequently asked question). De obicei grupurile de stiri au documente FAQ, nu personale.
MIME - Multiple Internet Mail Extensios RFC 1341,1521.
La inceput ARPANET, posta electronica era formata din mesaje text, in engleza, in cod ASCII. RFC 822 specifica antetele dar continutul era lasat in seama utilizatorului. Astazi, abordarea nu mai e actuala. E necesara transmisia si receptia de mesaje: in limbi cu accent (franceza, germana), cu alfabete nelatine ( slav, ebraic), fara alfabet ( chineza, japoneza), mesaje fara text (audio, video).
MIME continua sa foloseasca formatul RFC 822, dar adauga structura corpului mesajului si defineste reguli de codare pentru mesaje non-ASCII.
Mesajele MIME pot fi trimise cu programele de transmitere si receptie:
Antet RFC 822, legat de transport de mesaje.
|
To: |
Adresa/ele de e-mail a/le destinatarului/ilor primari |
|
Cc: |
Adresa/ele de e-mail a/le destinatarului/ilor secundar/i |
|
Bcc: |
Adresa/ele de e-mail pentru "blind carbon copy" |
|
From: |
Persoana/ele care au creat mesajul |
|
Sender: |
Adresa/ele de e-mail a transmitatorului curent |
|
Received: |
Linie adaugata de fiecare agent de transfer de pe traseu |
|
Return-Path: |
Pentru identificarea caii de retur la transmitator |
Campuri suplimentare de antet RFC 822 folosite de utilizatorii sau receptorii umani.
|
Date: |
Data,ora,minut,secunda la care a fost trimis mesajul |
|
Reply-To: |
Adresa de e-mail la care ar trebui trimise raspunsurile |
|
Mesage-Id: |
Numarul unic/identificator folosit ca referinta pentru acest mesaj |
|
In-Reply-To: |
Identificator mesajului al carui raspuns este mesajul curent |
|
References: |
Alti identificatori de mesaje relevanti |
|
Keywords: |
Cuvinte cheie alese de utilizator |
|
Subject: |
Rezumatul mesajului,pe o singura linie |
Antete RFC 822 adaugate de MIME
|
MIME-Version: |
Identifica versiunea |
|
Content-Description: |
Rezumatul mesajului |
|
Content-ID: |
Identificator unic |
|
Content-Transfer-Encoding: |
Cum e impachetat corpul mesajului pt.transmisie |
|
Content-Type: |
Natura mesajului |
Mime - Version precizeaza ca e un mesaj MIME si versiunea ( 1.0 deocamdata). Mesajele care nu contin acest camp se presupun in limba engleza ti sunt procesate ca atare.
Control - description caractere ASCII ce specifica ce este in mesaj. E necesar receptorului sa stie daca merita sa decodifice / citeasca mesajul. ( Ex.: daca acele caractere spun ca "mesajul contine fotografia hamsterului Barbarei" si receptorul nu e pasionat de hamsteri, probabil ca va arunca mesajul, decat sa-l decodifice intr-o fotografie color de inalta rezolutie).
Content -Id identifica continutul, are acelasi format cu Message - Id
Content - Transfer - Encoding arata cum este impachetat pentru transmisie corpul mesajului, intr-o retea care poate ridica obiectii la alte caractere decat literele: cifre / semne de punctuatie. Sunt furnizate 5 scheme si o evadare spre noi scheme:
Codarea ASCII pe 7 biti: caracterele pot fi transferate direct de protocolul de email, daca linia nu depaseste 1000 caractere;
Codarea pe 8 biti, incalca protocoluloriginal de email; trebuie respectata lungimea maxima a liniei. Se foloseste in locurile din Internet care au implementate extensii ale protocolului original;
Codarea binara; nu e respectata nici lungimea liniei (ex.: programele executabile); nu sunt garantii de livrare corecta;
Codarea in baza 64 (ramura ASCII) : 24 de biti sunt impartiti in grupe de 6 biti, iar celor 6 biti li se asociaza cate un caracter ASCII. Astfel texte binare arbitrare pot fi transmise sigur.
Codare afisabila marcata (Quoted - printable - encoding=: pentru texte in majoritate ASCII, unde caracterele cu cod mai mare ca 127 apar ca egal plus caracterul codat prin 2 cifre hexazecimale.
Obs.: Datele binare ar trebui codate in forma 4 sau 5, dar exista si varianta codarii definite de utilizator.
Content - Type cel mai interesant, specifica natura corpului mesajului (7 tipuri).
Tip Subtip
|
Text |
Plain |
Text neformatat |
|
Richtext |
Text cu comenzi simple de formatare |
|
|
Image |
Gif |
Imagini fixe in format GIF |
|
J peg |
Imagini fixe in format J PEG |
|
|
Audio |
Basic |
Sunet |
|
Video |
M peg |
Film in format M PEG |
|
Application |
Octet-stream |
Secventa neinterpretata de octeti |
|
Post-script |
Un document afisabil in Post Script |
|
|
Message |
Rfc 822 |
Un mesaj MIME RFC 822 |
|
Partial |
Mesajul a fost fragmentat pentru transmisie |
|
|
External- bady |
Mesajul in sine trebuie adus din retea |
|
|
Multipart |
Mixed |
Parti independente in ordine specificata |
|
Alternative |
Acelasi mesaj in formate diferite |
|
|
Parallel |
Partile trebuie vizualizate simultan |
|
|
Digest |
Fiecare parte e un mesaj RFC 822 complet |
APLICATII MODERNE
- Cresterea rapida a folosirii Web-ului e datorata standardizarii tuturor elementelor ce suporta aplicatii Web. Elementul cheie este HTTP ( Hypertext Transfer Protocol), pentru schimbul de informatii intre broswer-ele Web ( programe d navigare) si serverle Web.
- In retele HTTP ppot fi folosite trei tipuri de dispozitive intermediare:
- proxy
- gateway
- tunel
- DNS (Domain Name System ) e un serviciu de cautare ierarhizat ce asociaza numele host- uluide pe Internet cu adresa sa numerica. DNS foloseste o baza de date distribuita, ierarhizata, pentru asocierea nume-adresa si pentru a oferi informatii despre hosturi.
- SIP ( Session Initiaton Protocol) e un protocol de control de nivel aplicatie, pentru stabilirea , modificarea si terminarea sesiunilor de timp - real intre participanti , printr-o retea de date IP.
- SDP ( Session Description Protocol ) e folosit de SIP pentru a descrie continutul media ce e folosit pa durata sesiunii.
- API ( Application Programming Interface) pentru Socket-uri ofera o cale standardizata, convenabila pentru scrierea programelor de aplicatii, care folosesc comunicatii TCP sau IP.
Accesul la Web - protocolul HTTP
HTTP etste protocolul care sta la baza WWW (World Wide Web) si poate fi folosit in orice aplicatie client/serser ce presupune hypertext/hipertext. De fapt, transmiterea informatiei se face cu eficienta necesara pentru relizarea salturilor de hipertext.
Obs.: pentru utilizatorul Web-ului, documentele raspandite in toata lumea constituie niste pagini, care pot contine legaturi spre alte pagini. Selectand legatura (clic) se ajunge la noua pagina, etc. Despre paginile care indica alte pagini se spune ca utilizeaza hipertext.
Datele transferate de HTTp pot fi texte, hipertexte, audio, imagini sau alte informatii accesibile pe internet.
Cativa termeni cheie referitori la HTTP.
Cache - memorie intermediara rapida, de program, in care se memoreaza mesajele de raspuns si subsistemul care controleaza memorarea, regasire si stergerea mesajelor sale. Memorarea in cache se face pentru reducerea timpului de raspuns si a consumului de banda a retelei, pentru viitoarele cereri. Orice client sau server poate include cache-ul , desi la tunelare serverul nu o poate folosi.
Client - un program aplicatie care stabileste o conexiune cu scopul de a trimite cereri.
Conexiune - un circuit virtual de nivel transport stabilit intre doua programe aplicatie in vederea comunicarii.
Entitate - o reprezentare particulara sau redare a unei resurse de date sau raspunsul de la o resursa de serviciu, care poate fi inclusa intr-un mesaj de cerere sau de raspuns. O eantitate consta din antet si corp.
Gateway - un server care lucreaza ca intermediar pentru un alt server. Spre deosebire de proxy, poarta ( gateway) primeste cererile ca si cum era severul original pentru resursa solicitata; clientul care emite cererea poate sa nu fie constient ca comunica cu un gateway. Gateway- ul e deseori folosit ca un portal pe partea serverului prin firewall-urile retelei si ca un translator de protocol pentru accesarea resurselor de pe sisteme non-HTTP.
Mesaj - unitatea de baza a comunicatiei HTTP, constand dintr-o secventa de octeti transmisa prin conexiune.
Serverul origine - serverul pe care resursa exista sau va fi creata.
Proxy - program intermedia care actioneaza atat ca server cat si ca client, cu scopul de a face cereri din partea altor servere, eventual translatate. Proxy-ul trebuie sa interpreteze , si daca e necesar sa rescrie, mesajele de cerere inante de expedierea lor inainte. Deseori, proxy- rile sunt folosite ca portaluri pe partea utilizatorului prin firewall-urile retelei si ca aplicatii "helper" pentru manevrarea cererilor prin protocoale neimplementate de agentul utilizator.
Resursa - obiect de date retea sau serviciu, care poate fi identificat prin URI (Uniform Resource Identifier).
Server - program care accepta conexiuni de cereri de serviciu, trimitand inapoi raspunsuri.
Tunel - program intermediar , care actioneaza ca un releu "orb" intre doua conexiuni, Odata activat, tunelul nu e considerat ca parte a comunicatiei HTTP , desi tunelul poate fi initiat de o cerere HTTP. Tunelul inceteaza sa existe cand inchid ambele parti carora le-a facilitat comunicarea. Tunelurile se folosesc cand e necesar un portal si sistemele intermediare nu pot sau nu vor sa interpreteze comunicatia facilitata (relayed).
Agent utilizator - client care initiaza o conexiune si deseori sunt browser- e, editoare, spider-e sau alte programe din sistemele finale . (Spider: cautator prin Internet de informatii, care indexeaza bazele de date si faciliteaza astfel lucrul motoarelor de cautare).
HTTP e un protocol client-server orientata pe tranzactii. Tipic e folosit intre un browser Web si un server Web. Foloseste TCP pentru siguranta. Astfel, va fi creata la fiecare tranzactie, o noua conexiune TCP intre client si server, care se inchide la sfarsitul tranzactiei. Aplicatia tipica presupune utiliztor-browser Web, de gasire a unor secvente de pagini si documente, distribuite pe servere foarte dispersate, actiune care se desfasoara foarte rapid (ideal).
HTTP este flexibil in ceea ce priveste formatele. Cererea unui client la server poate include o lista cu prioritati de formate iar serverul raspunde cu formatul potrivit. Ex: browser-ul lynx nu poate manevra imagini, deci serverul Web nu trebuie sa transmita nicio imagine de pe paginile Web. Se evita astfel transmiterea informatiilor inutile si se permite extinderea setului de formate cu specificatii standard, brevetate
In figura urmatoare sunt date trei exemple de operatii HTTP.
a) cazul in care agentul utilizator stabileste o conexiune directa cu serverul origine ( un browser Web si un server ce contine paginile dorite). Clientul deschide o conexiune TCP end-to-end cu serverul, dupa care genereaza o cerere HTTP, ce consta dintr-o comanda ( metoda), o adresa (URL Uniform Rsource Locator), si un mesaj de tip MIME ce contine parametrii solicitati, informatii despre client si eventual alte informatii. Cand serverul primeste cererea, incearca sa execute operatia de stare, codul de succes/eroare si un mesaj de tip MIME cu informatii despre server, despre raspunsul propriuzis si eventual in corp . Apoi conexiunea se inchide.
b) Nu exista o conexiune TCP end-to-end intre agentul utilizator si serverul origine. Exista cateva sisteme intermediare.
Serverul origine
Conexiuni TCP exista
intre sistemele adiacente. Fiecare sistem intermedia actioneaza ca un releu
transferand cererile/raspunsurile.
Exista specificate , de catre HTTP, 3 tipuri de sisteme intermediare: proxy, gateway si tunel.
Proxy-ul prezinta serverului cererile clientilor si raspunsurilor din partea serverului la clienti. Exista 2 scenarii de apel a proxy-ului:
Daca exista un intermediar de securizare, ce separa clientul si serverul, proxy-ul e plasat intre client si firewall. Clientul face parte din reteaua securizata de firewall, dar serverul nu, deci serverul trebuie sa se autentifice la firewall pentru a stabili conexiunea cu proxy. Proxy-ul accepta raspunsurile de la server, dupa ce au trecut prin firewall.
2.Daca clientul si serverul au versiuni HTTP diferie, proxy-ul trebuie sa faca adaptarea.
Proxy-ul este deci un agent de inaintare, primind cereri de obiect URL, modificand cererile si inaintand cererile spre serverul identificat de URL
Gateway folosit de serverele ce nu pot comunica cu clientul direct si le apare acestuia ca un server origine. Exista si aici 2 scenarii de utilizare.
1. Daca exista un intermediar de securizare (firewall), cu gat-wayul inspre serverul origine, atunci serverul face parte din reteaua securizata dar clientul nu, deci trebuie sa se autentifice la gateway, care apoi va pasa cerea serverului.
2. Server nonHTTP: (ex: FTP sau Gopher), pretind ca browserele Web sa inglobeze functiile de adaptare cu HTTP sau gateway-ul server, care contacteza serverul FTP/Gopher pentru a obtine rezultatul dorit, pe care apoi il va converti HTTP si-l va transmite clientului.
Tunelul nu face ( spre deosebire de proxy si gateway) nici o operatie la cereri / raspunsuri HTTP. El este un releu intre 2 conexiuni TCP si mesajele HTTP trec neschimbate daca exista o singura conexiune HTTP intre utilizator si serverul origine. Apare cand e necesar un sistem intermediar , dar care sa nu inteleaga continutul mesajelor. Ex: un firewall prin care un client / server extern retelei protejate stabileste o conexiune autentificata, pe care o mentine apoi pentru tranzactii HTTP.
Sisteme HTTP intermediare
c) exemplu de cache (facilitatea de memorare a cererilor / raspunsurilor anterioare, pentru manevrarea noilor cereri). Daca noua cerere e identica cu una veche, cache-ul poate oferi raspunsul direct, in loc sa acceseze din nou resursa indicata de URL. Cache-ul poateopera la client, la server sau in sistemele intermediare. In fig. sistemul intermediar B memoreaza in cache tranzactia cerere / raspuns, astfel ca cererea noua e manevrata de b si nu mai trebuie sa traverseze reteaua pana la serverul origine.
Nu toate tranzactiile pot fi memorate in cache si clientul sau serverul pot dicta memorarea unor tranzactii pe o durata limitata.
B
C
Agent utilizator
Sistemul numerelor de domenii DNS-Domain Name System
DNS e un serviciu de asociere intre numele de host si adresa IP numerica . Contine 4 elemente:
- spatiul numerelor de domenii: foloseste spatiul numerelor de domenii o structura de arbore, pentru identificarea resurselor din Internet.
- baza de date DNS: fiecare nod si frunza al arborelui specifica o serie de inforamatii (ex. adresa IP, tipul resursei), care sunt continute in inregistrare resursei, RR (resource record). Toate inregistrarile RR sunt organizate intr-o baza de date distribuita.
- serverele de nume: sunt programe server ce mentin informatiile despre o portiune a arborelui numerelor de domenii si RR-urile asociate.
- rezoverele: sunt programe care extrag informatia de la serverele de nume la cerea clientilor. O cerere tipica este pentru adresa IP corespunzatoare unui nume de domeniu.
Numele de domeniu : adresa IP de 32 biti, ce identifica unic dispozitivul atasat la Internet, e interpretata ca : numar de retea + numar de host. Dar, in practica, folosirea adreselor de IP prezinta doua probleme:
1. - ruterele creaza o cale prin Interne pe baza numarului retelei. Daca fiecare ruter ar mentine o tabela completa cu toate retelele si caile preferate spre acestea, manevrarea acestei tabele ar fi dificila si foarte lenta. Astfel ca, pentru simplificarea dirijarii se grupeaza retelele.
2. - adresa de 32 de biti, scrisa ca 4 grupe de numere zecimale corespunzatoare celor 4 octeti de adresa, e utila procesarii pe calculator, dar foarte greu de manevrat de utilizatorii umani, care retin mai degraba nume decat numere.
Acestor probleme le raspunde conceptul de domeniu, care se refera la un grup de hosturi, controlate de o singura entitate administrativa (o companie sau o agentie guvernamentala). Domeniile sunt organizate ierarhic , astfel ca fiecare domeniu consta din cateva domenii subordonate ( vezi figura urmatoare cu o portiune a spatiului numerelor de domenii).
Ficare domeniu e denumit de calculator in arbore, pana la radacina:
ex: eng.sun.com, componentele fiind separate cu punct, sau
ex: /com/sun/.com, in UNIX separarea se face cu slash.
O portiune a spatiului numerelor de domenii din Internet e preuenatata in figura urmatoare:
icee
org
com - comercial, edu - educatie, gov - guvernul federal al SUA, int - organizatii internationale, mil - forte armate SUA, org - oragnizatii nonprofit, network - centru pentru servicii de retea, biz - afaceri private , info - utilizare nerestrictionata, pro -profesii medicale, legale, economice, aero - comunitate aviatica, coop - organizatii cooperatiste ca uniunile de credit, name - individuale, pentru adrese de email sau domenii personalizate, museum - pentru muzee si organizatii/persoane lucrand in domeniul muzeelor.
O organizatie pentru tot Internetul aloca numele domeniilor. Fiecare domeniu controleaza alocarea domeniilor/subdomeniilor inferioare lui. Pentru inregistrare unui nou domeniu se cere permisiunea domeniului in care va fi inclus. Coborand in jos prin arbore se ajunge la hosturi , care au alocate adrese Internet. Alocarea adreselor se face mai jos in ierarhie.
Baza de date DNS - inregistrarea resurselor
DNS e construir pe o baza de date ierarhica ce contine inregistrarile resurselor RR ( resource records) ce includ numele, adresa IP si alte informatii despre hosturi. Formatul RR este:
|
Numele domeniului |
|
Tip |
Clasa |
|
|
|
Timp de viata |
|
||
|
Lungimea campului Rdata |
|
||
|
Rdata |
|||
Pentru un host , inregistrarea normala e chiar adresa sa IP.
Nume domeniu, reprezinta cheia de cautare primara, fiind format dintr-o serie de caractere alfanumerice si cratime ( pe care operatorul uman le poate citi ) separate de puncte.
Tipul, identifica tipul de resurse din RR
A - adress, adresa de host. Se asociaza numele u adresa IP. Ruterele cu adrese multiple au RR separate pentru fiecare adresa.
CNAME - canonial name, specifica numele alais pentru host si-l asociaza cu numele canonic ( adevarat).
HINO - host information, specifica procesorul si sistemul de operare al hostului.
MINFO - mailbox or mail-list information, asociaza aceste informatii la numele hostului.
|
Politica de confidentialitate | Termeni si conditii de utilizare |
Vizualizari: 1448
Importanta: 
Termeni si conditii de utilizare | Contact
© SCRIGROUP 2024 . All rights reserved
